By: Richard Cownie (tich.delete@this.pobox.com), February 4, 2013 5:52 pm
Room: Moderated Discussions
rwessel (robertwessel.delete@this.yahoo.com) on February 4, 2013 12:08 am wrote:
> migrations are disasters. Contrast the x86-64 transition. Intel and AMD could build the CPUs, the system
> vendors could start plugging them into existing motherboards, the OS developers could go and do their
> thing at their pace, the application developers could easily see a future for the x86-64 systems, the
> customers could buy and use the systems before the new OS's and applications were ready, once the OS was
> ready the customer's could install the OS and use all their existing 32-bit applications (with continued
> excellent performance), and then upgrade those as the whim or need struck them.
Very true. I ported some C++ stuff from SPARC32 to SPARC64, then to x86_32 and x86_64.
There were about 80 executables, but only 2 or 3 *needed* 64bit memory space.
Many of the others were not ported for several years (some never). The move from SPARC32
to SPARC64 made the code run slower, because the code used lots of data structures which
got bigger and thus had more cache misses. In contrast, the move from x86_32 to x86_64
made the code go faster, because the larger register file gave a substantial win.
It was a very easy transition, with incremental benefits from each increment of effort.
Conversely, porting to Itanium (which was narrowly avoided ...) would have meant
spending money on a relatively expensive workstation, not useful for anything else,
and then having to port all the performance-sensitive executables, even those which
didn't need >4GB, to have anything shippable.
> migrations are disasters. Contrast the x86-64 transition. Intel and AMD could build the CPUs, the system
> vendors could start plugging them into existing motherboards, the OS developers could go and do their
> thing at their pace, the application developers could easily see a future for the x86-64 systems, the
> customers could buy and use the systems before the new OS's and applications were ready, once the OS was
> ready the customer's could install the OS and use all their existing 32-bit applications (with continued
> excellent performance), and then upgrade those as the whim or need struck them.
Very true. I ported some C++ stuff from SPARC32 to SPARC64, then to x86_32 and x86_64.
There were about 80 executables, but only 2 or 3 *needed* 64bit memory space.
Many of the others were not ported for several years (some never). The move from SPARC32
to SPARC64 made the code run slower, because the code used lots of data structures which
got bigger and thus had more cache misses. In contrast, the move from x86_32 to x86_64
made the code go faster, because the larger register file gave a substantial win.
It was a very easy transition, with incremental benefits from each increment of effort.
Conversely, porting to Itanium (which was narrowly avoided ...) would have meant
spending money on a relatively expensive workstation, not useful for anything else,
and then having to port all the performance-sensitive executables, even those which
didn't need >4GB, to have anything shippable.