[Cryptography] Speculation considered harmful?

Theodore Ts'o tytso at mit.edu
Wed Jan 10 15:24:49 EST 2018


On Wed, Jan 10, 2018 at 10:02:50AM -0600, Nico Williams wrote:
> On Tue, Jan 09, 2018 at 05:46:07PM -0500, Theodore Ts'o wrote:
> > Yet another problem with VLIW is that the optimizations tend to be
> > horribly architecture specific.  If you change the number of various
> > functional units, but you want to keep the instruction set backwards
> > compatibility, that's possible --- but if the compiler has to know how
> > the instructions will be scheduled, not only is it slow to compile,
> > but what is optimized for a particular version of Itanic might have be
> > terribe performance on a different version of the Itanic.
> 
> VLIW == no stable ABI.  We'd have to ship bitcode and re-optimize,
> assemble, and link for every VLIW CPU model.
> 
> It wouldn't be the end of the world.  But first we'd need the compilers
> that could handle it.

That alone would probably doom an architecture with VLIW from a
commercial perspective.  Think about what this means from a software
vendor's perspective.  Or from a Linux Distribution's perspective.

The CPU vendor will be pushing out --- at minimum --- 4 CPU models per
release cycle, which is every 12 months, plus or minus.  One for
"super low-power mobile devices or netbooks", one for laptops, yet
another for servers, and yet another for super-high-end servers (aka
"Xeon Processors").  Over 5 years, that's twenty different CPU models
the binary provider would have to reoptimize and support --- for every
softare release.  And in practice, if the binary is different, it will
have to go through its own QA cycle.  So we've just increased the
overhead of supporting this architecture by an order of magnitude over
a traditional non-VILW architecture.

(Yes, I know that the Itanic would be laughable in the low power
domains; so even if you think an architecture that neglected the
laptop market would be successful, it's still a factor of 10 more
binaries that you have to produce and QA.)

And this is ignoring the fact that these compilers tend to take a
factor of three to five longer to actually compile, which is really
annoying from a developer's edit, compile, debug cycle.

						- Ted



More information about the cryptography mailing list