x86_64 is also faster ? Not so fast... [LWN.net]

Easy? I think not.

Posted Oct 18, 2008 17:49 UTC (Sat) by khim (subscriber, #9252) [Link]

But when it became apparent that nobody except Intel was interested in cheap low-to-mid range hardware, and that Intel had no clue how to build a 64-bit CPU.

Intel built one. The problem was: nobody wanted to spend time rewriting existing programs. Situation is more-or-less the same today: transtion to 64bit is underway, but there are no rush.

If my application runs 40% slower in 64-bit mode I'm going to go find the problem (I declared that huge array as 'long' integer? Whoops, that was stupid) and fix it.

What do you do if your program basically works with bunch of pointers (like Flash does)?

The effect trickles down, and with new _laptops_ having 4GB of RAM these days it's crazy to be writing libraries (which is what the Flash player mostly is) that are explicitly written to be trapped in that 4GB address space.

Flash was not written today and hardest part to port is not library of geometry objects but JIT. And JITs are hard to port (Chrome's JIT does not have support for 64bit too - despite being brand-new unlike Flash).

My day job is developing and maintaining a 64-bit program, admittedly ours is a lot bigger than most, but we've been doing this for years, and its been reinforced over time that refusing to compromise for 32-bit was the right decision.

May be it was right direction for you but why you are so sure it's right direction for everyone else? Most desktop programs don't need a lot of RAM and don't need a lot of address space - and will be Ok for years to come. Will the clock applet need terabytes of address space? Why? What for? Even browser: if you render just one page in a single process (like Chrome does) then there are basically no way you'll need even 100MiB of address space in the near future, let alone 4GiB...

Transition to "full 32-bit system" took 15 years (from 1986 when i386 was created to 2001 when last 16-bit based OS was declared obsoleted), I think transition to "full 64-bit systems" will be slower, not faster - because pressure is not so great. And Athlon64 was only introduced five years ago...

Easy? I think not.

Posted Oct 18, 2008 23:39 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

"Itanic" indeed, that's exactly my point about "no clue". You correctly identify that there's a transition process, and the Itanium made no allowance for such a process, it seemed as though Intel hadn't even considered that the software then running on their x86 line would be expected to somehow transition onto this weird new architecture.

The transition process doesn't have to take decades, I think you've got that part wrong. The degree of abstraction from hardware is much greater this time, meaning you don't have all or nothing transitions. On OS X apparently even drivers can opt out of knowing about 64-bit for a while. With RAM being so cheap, most general purpose computing devices will quickly be 64-bit capable for practical reasons, and once the CPU is 64-bit you will have some applications that make use of that. You no longer have "32-bit only" as an option, so if you want the minimum number of platforms to support, "64-bit only" becomes the sensible choice. I think this creates a situation in which a "siphon effect" occurs, taking people from "Well, there is one 64-bit program I want to run" to a 64-bit only system in one upgrade cycle. I think the limiting factor will be ISVs, particularly on Windows, who loathe having to change /anything/ they were still shipping 16-bit installer programs that hadn't been maintained in almost a decade, right up until Microsoft banned such nonsense from their co-branding programme.

But then maybe I'm just counting very differently to you. I would not have said that transition to 32-bit ended in 2001. I'd say that happened in the mid 1990s, there was a lot of mess inside Windows 95, but new development of 16-bit software had ceased, PC video games (which you might think of as 16-bit because they ran under DOS for a few years still after Win 95) were actually using DOS extenders to escape 16-bit DOS and run 32-bit code. When the Pentium Pro flopped it was just barely mis-timed, its 16-bit performance was poor and the last few major applications with performance critical 16-bit code were just dying off. The Pentium II, also with fairly bad 16-bit performance, went into the market just fine.

Now, how about I show you how to burn lots of RAM on a web page without trying. Let's write a blog entry about a TV show we saw last night. Firstly, we inline the show itself, compressed of course, but still could easily be 2GB of data. Now, we add our commentary track, synchronised to the original, and then a series of images illustrating particular points which people can click on to zoom to their full HD resolution. Today it would be considered anti-social to embed a 2GB video on my hypothetical blog, but then ten years ago it would have been anti-social to put a 2MB image on there. In 2013 a 2GB video may just be the obvious way to illustrate what I'm talking about.

Of course very little of this strictly has to be in RAM at one moment, it's just that the difference between the user experience with the program desperately trying to keep all this fitted into 100MiB versus not worrying about it and letting the OS set cache policy is very noticeable. When you seek back a few seconds and a little beach ball appears and the disk goes crazy for 15 seconds, that makes you desperately want to avoid ever seeking again. Whereas if it happens instantly, you now have a useful feature. If scrolling to a different image causes the whole machine to have a heart attack while it goes off to load the image back into RAM, again you find yourself not wanting to scroll any more. This is the same as Linus' observation about git - faster isn't just a quantitative thing.

Now, as to the more general case, with the clock. You're right - in principle there are programs running on this laptop in front of me that could be 16-bit, or even 8-bit programs, They don't do very much, they don't manipulate huge files, or anything. But in practice it's much easier to just have one platform, a platform that's big enough for all the programs you run, and I argue that today and certainly tomorrow that platform is 64-bit.

Finally the pointers question. This is a design issue. There's a common Unix design where pointers are used as opaque handles, so an "image handle" or a "message handle" or whatever is just a pointer. Fast, but not necessarily space efficient. If your program typically has a few individual handles being passed around, that's a good pragmatic decision, but if you keep huge structures filled with handles then you may need to re-evaluate when porting to 64-bit, could the handles be indexes on an array or vector instead? The "indexing" style handles are more common in Windows, but each kind is found on both systems. With a 32-bit index instead of an address sized pointer you can have the same data throughput (and thus more or less performance) regardless of 64-bit vs 32-bit code. That's just one illustration, but hopefully it's helpful. Programs that absolutely /must have/ large numbers of real pointers or other address-sized things are fairly rare.

Easy? I think not.

Posted Oct 18, 2008 23:47 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Hmm, Wikipedia says the PII significantly improved the PPro's 16-bit performance. I guess I didn't notice because I personally wasn't running any 16-bit code. So, in that case I withdraw that part of my argument, perhaps Intel found 16-bit code performance made a difference to their customers as late as 1998.

Yup: pretty big difference

Posted Oct 19, 2008 9:09 UTC (Sun) by khim (subscriber, #9252) [Link]

16-bit code performance made a difference between win and loss in 1998...

Itanium lost for the same reason Pentium Pro lost

Posted Oct 19, 2008 9:08 UTC (Sun) by khim (subscriber, #9252) [Link]

"Itanic" indeed, that's exactly my point about "no clue". You correctly identify that there's a transition process, and the Itanium made no allowance for such a process, it seemed as though Intel hadn't even considered that the software then running on their x86 line would be expected to somehow transition onto this weird new architecture.

Itanium had support for such a process. But it's 32-bit performance was abysmal. Intel's engineers said that this time the transition process doesn't have to take decades and concentrated solely on 64-bit side - and of course they were wrong.

The degree of abstraction from hardware is much greater this time, meaning you don't have all or nothing transitions.

Yahoo! Yes, the abstraction is much greater, "transition pressure" is lower and that means transition will be slower, not faster.

With RAM being so cheap, most general purpose computing devices will quickly be 64-bit capable for practical reasons, and once the CPU is 64-bit you will have some applications that make use of that.

Yes, some applications. The kind of applications which need huge memory. Like Photoshop - which has 64-bit version now. For the whopping three days (CS4 was released October 15, 2008) - and only under Windows Vista (Windows XP and MacOS X are 32-bit only).

You no longer have "32-bit only" as an option, so if you want the minimum number of platforms to support, "64-bit only" becomes the sensible choice.

Why not? As I recall Photoshop is very resource-hungry application and MacOS is "platform of choice" for designers, yet Photoshop remains 32-bit application. It'll win from huge disk caches on 8GB-16GB systems, but it does not need to be 64-bit to get advantage from this memory... The pressure to make applications 64-bit, not an OS will only begin to mount 5-10 years down the road.

I think this creates a situation in which a "siphon effect" occurs, taking people from "Well, there is one 64-bit program I want to run" to a 64-bit only system in one upgrade cycle.

Sorry, but I can not see how it creates such illusions. We've switched from "32bit system with some 64bit programs" (this is what we used for last three years) to "64bit system with a lot of 32bit programs" on my work just few months ago (and there were voices to wait year or two) - and a lot of stuff is still 32bit-only with no plans to switch to 64bit any time soon. Sparc servers worked with such a model (64bit kernel, 32bit userspace) for years, why x86-64 must be different.

I would not have said that transition to 32-bit ended in 2001. I'd say that happened in the mid 1990s, there was a lot of mess inside Windows 95, but new development of 16-bit software had ceased, PC video games (which you might think of as 16-bit because they ran under DOS for a few years still after Win 95) were actually using DOS extenders to escape 16-bit DOS and run 32-bit code.

Windows95/98/ME had a lot of 16-bit code and programs for that OS often included 16bit helpers (not just installers). And games actually switched to pure 32bit only when 3D became widespread - that's few years after Quake. Till Windows 9X was alive it was to early to say "16bit era is history". Even if you count mid 1990s as the end of "16bit era" it's still 10 years after introduction of i386 architecture...

When the Pentium Pro flopped it was just barely mis-timed, its 16-bit performance was poor and the last few major applications with performance critical 16-bit code were just dying off. The Pentium II, also with fairly bad 16-bit performance, went into the market just fine.

Actually they fixed this performance loss and that saved Pentium II. Because a lot of programs depended on 16-bit - most of all Windows9X itself.

Of course very little of this strictly has to be in RAM at one moment.

This is not a problem: when you are talking about such a huge data sizes often it does not matter if it's addressable at once or not. You can always use mmap over /dev/zero to work with huge data regions like EMS back in a day. EMS worked just fine when random access is not needed (random access to video file is really random access to few thousand positions in that file).

You're right - in principle there are programs running on this laptop in front of me that could be 16-bit, or even 8-bit programs, They don't do very much, they don't manipulate huge files, or anything.

They are using GLibC - that's enough. Statically linked "Hello world" is over 128KiB today. More then 16-bit can handle without a lot of tricks. And when we are talking about code - that's different cattle of fish. EMS worked fine with a lot of data, but when program included 1-2MB of code... it was different game altogether. It was still possible but speed loss was 10-15%, sometimes more.

But in practice it's much easier to just have one platform, a platform that's big enough for all the programs you run, and I argue that today and certainly tomorrow that platform is 64-bit.

It's certainly easier if you start from scratch. But if you have 32bit legacy it's different.

Finally the pointers question. This is a design issue. There's a common Unix design where pointers are used as opaque handles, so an "image handle" or a "message handle" or whatever is just a pointer. Fast, but not necessarily space efficient. If your program typically has a few individual handles being passed around, that's a good pragmatic decision, but if you keep huge structures filled with handles then you may need to re-evaluate when porting to 64-bit, could the handles be indexes on an array or vector instead?

Ah. That's the answer I've waited for: so you suggest to switch from 32bit to 64bit, throw away EMS-style tricks used for video and add new, equally troublesome, tricks to work with data structures. Essentially zero gain for a lot of work (you still can not use a lot of data objects because your 32bit indexes will overflow). Is this wise decision? Not IMO.

That's what I've wanted to say: for a lot of programs switch to 64bit is just a replacement of one set of tricks with another. Today. When they'll start to work with billions of these handles (and that means many gibibytes of RAM, not 4GiB or 8GiB) it'll make sense to use 64bit despite speed loss (otherwise it'll just not work) and probably switch should happen somewhat earlier. But to do it today... it's too early.

Programs that absolutely /must have/ large numbers of real pointers or other address-sized things are fairly rare.

Rare but important. That's web-browsers (DOM and JavaScript are exactly such structures), Flash (the same: a lot of small objects and ActionScript) and OpenOffice.org (a lot of small objects for each spreadsheet or word document). Firefox is significantly slower in 64bit mode (OpenOffice.org is slow as hell in any more so don't count) and Adobe just decided that they don't want to spend money to produce inferior product...

The only place where 64-bit switch happened fast is FOSS because a lot of people just took it as a challenge: let's make everything pure 64-bit. Where people are counting money - process is much, much slower. Unless you are talking about few guys which needed and used gibibytes of RAM for many years (like EDA).

Back to Adobe's excuse making

Posted Oct 19, 2008 14:00 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

I knew you'd use Photoshop as an example, does that tell you anything? If you Google around for people arguing that 32-bit userspace is fine, and no-one needs to worry about running out of address space and so on, the first things you run into are Adobe Photoshop developer blogs.

They've been making this argument ever since 64-bit Windows became available to ordinary mortals. You can find plenty of made up numbers about how it would actually be slower for most purposes, and certainly wouldn't get any faster until you were loading absolutely huge images with vast numbers of layers...

... and then Adobe announced the 64-bit Photoshop and suddenly the story changed overnight. 64-bit was going to be faster for even moderately sized images, a lot of existing features would see a speed-up, and so on.

This is called /spin/ - Adobe used to tell Photoshop users they didn't want unlimited Undo History, it was a crutch for people who didn't use their image editing software the right way, and then one day Photoshop implemented it and suddenly Adobe couldn't say enough about how great it was. They're trying to avoid the Obsourne effect, I get that, but the net result is that they spent a lot of time misleading customers. Why believe anything they say?

Adobe ended up in the mess with Photoshop, partly, because of a lack of abstraction. Many Photoshop users have 3rd party plug-ins. The plug-ins run "in memory" so if you upgrade to 64-bit you need some tremendous kludge or else you can't run any old plug-ins. A bit of design foresight would have been good right there.

You're mistaken about PC video games, it's nothing to do with 3D or Windows. It's all about DOS extenders. The DOS extender was supplied with your tool chain, effectively part of the run time. Despite DOS being 16-bit the "extender" would push the CPU into 32-bit flat mode, so all your actual development would be in 32-bit. DOS extenders were fairly rare when Doom had one, but by the time Quake arrived in 1996 everything in the PC section of your games store would be 32-bit code run by a DOS extender. Even simple point-and-click adventure games, which could have been coded for 16-bit DOS with overlays or similar tricks weren't bothering, 32-bit development meant less headaches for developers, which meant shorter time to market.

I'm not really sure what to make of your claims about DOM and so on. If web browsers actually need billions of DOM objects, URIs, images etc. then isn't it a surprise that they've ever worked on 32-bit machines? Or on the other hand, if as seems more likely they have a few million DOM objects, a few million URIs, and a few thousand images, then 32-bit handles are fine, and will be long after 32-bit memory isn't nearly enough. When I said most programs don't need lots of pointers, I meant that explicitly, and you don't seem to have understood that. /Choosing/ to use pointers everywhere you can is a design decision, and not automatically a good one.

Finally, I must say that although Firefox feels sluggish everywhere, it doesn't seem especially more so on my 64-bit machines. "Significance" is a tricky term, medical researchers speak of both "statistical significance" and "clinical significance" e.g. maybe you can show that your new drug has a statistically significant effect on lower back pain, but then when doctors look at the size of the effect it's equivalent to one person saying they feel a little better for every million people treated - well, that's not clinically significant, your drug is useless. Negative effects from increased native word size need to be characterised in terms of what users would actually notice. If the user won't notice, we shouldn't care.

Spin is spin, but...

Posted Oct 19, 2008 15:04 UTC (Sun) by khim (subscriber, #9252) [Link]

Adobe used to tell Photoshop users they didn't want unlimited Undo History, it was a crutch for people who didn't use their image editing software the right way, and then one day Photoshop implemented it and suddenly Adobe couldn't say enough about how great it was.

If that's really the most they can offer to 64bit users then previous position was correct: 64bit version offer only tiny improvements, not something truly spectacular.

You're mistaken about PC video games, it's nothing to do with 3D or Windows. It's all about DOS extenders. The DOS extender was supplied with your tool chain, effectively part of the run time. Despite DOS being 16-bit the "extender" would push the CPU into 32-bit flat mode, so all your actual development would be in 32-bit. DOS extenders were fairly rare when Doom had one, but by the time Quake arrived in 1996 everything in the PC section of your games store would be 32-bit code run by a DOS extender. Even simple point-and-click adventure games, which could have been coded for 16-bit DOS with overlays or similar tricks weren't bothering, 32-bit development meant less headaches for developers, which meant shorter time to market.

A lot of games were 16bit back then. I still remember that Larry7 (1996) and Enemy Nations (1997) worked fine with Windows 3.1 (I had no hardware for Windows95 back then) and thus were quite happy with 16-bit system. Only by the 1997 games started dropping 16bit mode support (and Quake was released June 22, 1996, don't forget).

I'm not really sure what to make of your claims about DOM and so on. If web browsers actually need billions of DOM objects, URIs, images etc. then isn't it a surprise that they've ever worked on 32-bit machines?

I wanted to say that browsers work with a lot of small objects and so it makes perfect sense to use 32bit mode. Only if/when web pages will start to include billions of said objects 64bit mode will make sense. Basically either they work with small pages of today (and then 32bit mode is the best choice) or they handle ubercomplex pages of tomorrow (and then all these schemes with indexes are useless). Transition phase is short - and it's some years in the future...

Or on the other hand, if as seems more likely they have a few million DOM objects, a few million URIs, and a few thousand images, then 32-bit handles are fine, and will be long after 32-bit memory isn't nearly enough.

Actually this time is short. Memory requirements double every year and half on average. That means if you have one pointer per ten words or useful data (not uncommon for many different types of applications) then time where your "32bit indexes but 64bit pointers" scheme works is five or six years! And it's just stupid to write program which can only be useful for five years - much better to just refuse to switch to 64bit till your data and indexes work in 32bit mode (that's fastest mode) - and then switch to 64mode. With some tricks (move images and video handling to separate process, etc) you can manage to work with 16GiB of RAM (may be even 32GiB or RAM) while in 32bit mode and then this "window of opportunity" shrinks even further (this tricks will slow down your program, of course, so at some point 64bit mode will be just faster with no strings attached - and THAT is the time when you need to switch).

/Choosing/ to use pointers everywhere you can is a design decision, and not automatically a good one.

Sorry, but I don't buy it. Indexes are kludges: at some point you'll have so many objects in your program that 32bit indexes will just not work (Windows 98/ME was hit by this problem pretty hard: GDI objects used indexes is 16bit tables and so it was not uncommon so see system with many mibirytes of RAM crash or behave erratically because it had no room to create yet another window or yet another brush). Wrappers around pread() and pwrite() are kludges too. But there are a difference: wrappers around pread() and pwrite() allow you to use old libraries and programs for a while in the "brave new word or multigibibyte RAM" while indexes make life easier for a while but then require redesign of the whole system (something like Windows 9X => Windows XP transition). Thus IMNSHO indexes are more evil then wrappers.

Negative effects from increased native word size need to be characterised in terms of what users would actually notice. If the user won't notice, we shouldn't care.

Sorry, but it's the other way around: positive effects must be measured and if the user won't notice there are no need to switch to 64bit yet. Why? Easy: we already have working 32bit stuff and 64bit stuff must prove itself before it'll be accepted. XP 64bit was total flop and Vista 64bit is not so hot either - and that's prerequisites! While there are no 64bit OS there are no 64bit programs... You need at least ONE program which shows that 64bit OS is worthwhile and even after that switch from 32bit to 64bit will be on case-by-case basis...

That actually the policy around here: if application can work in 32bit mode - it must be used in 32bit mode in production (most our programs are memory-bound, not CPU-bound), but all tests must pass in 64bit mode too because switch is unavoidable. At some point.

Spin is spin, but...

Posted Oct 19, 2008 17:15 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

If that's really the most they can offer to 64bit users

Ah, I guess that again you have the wrong end of the stick. This was not an example of something enabled by the 64-bit version, it's just an example of how Adobe changes its story between releases. Illustrating that you can't believe what Adobe's developers tell you about the value of features their product doesn't have (well, this ought to be obvious I'd have thought). GIMP developers have been known to say that various missing features aren't important in the past and I didn't believe them either.

I still remember that Larry7 (1996) and Enemy Nations (1997) worked fine with Windows 3.1

Yes...

and thus were quite happy with 16-bit system

... No.

I don't have Larry7 code to look at, but Enemy Nations is a Free Download these days. It's easy to verify that Enemy Nations isn't a Win16 game at all, it's a Win32 game carefully tailored to use the subset of Win32 that was available through Win32s, a 32-bit flat memory runtime for Windows 3.x that Microsoft made available to encourage transition. Microsoft's demo for that technology is actually rather famous -- Freecell. It's rather a shame they couldn't come up with anything similarly compelling for Win64... On the upside this means you can still play Enemy Nations on 64-bit Vista (in theory at least) unlike 16-bit games.

And well, OK, you don't buy my design advice about handles. I'm certainly not going to write a whole web browser to try to prove you wrong. I will say that I think if you look at how memory usage grows you'll see that there's a difference between the trend for small things to get bigger, versus for there to be more small things. This hard disk is more than a thousand times bigger than the first one I owned, yet the number of /files/ on my current disk is only 400 000. Did I really only keep 400 files on my first hard disk? No, I don't think so. I expect the web browsers in five years time to have only 2-3 times more 'objects' but the total RAM used will increase more like ten fold as the objects get richer.

Spin is spin, but...

Posted Oct 19, 2008 20:59 UTC (Sun) by khim (subscriber, #9252) [Link]

It's easy to verify that Enemy Nations isn't a Win16 game at all, it's a Win32 game carefully tailored to use the subset of Win32 that was available through Win32s, a 32-bit flat memory runtime for Windows 3.x that Microsoft made available to encourage transition.

Ok, you are right. By the 1997 games dropped support for 16bit systems. I've tried to recall what I've played back then and found that most games were already 32bit or in few cases used Win32s... 1995 was the time when I've switched from 286 to 486 so I can not be too sure if games in 1996 and 1997 used Win32s or not. Before than they were 16bit as rule - only few notable exceptions (like Doom in 1993). To effectively cope with 2-4MiB of RAM was too much for 16bit mode. It means we can be pretty sure transition to 64bit systems will happen when typical RAM in desktop will pass 64GiB or 128GiB. That's few years yet... We don't have many server systems with 128GiB RAM today let alone desktops/laptops...

This hard disk is more than a thousand times bigger than the first one I owned, yet the number of /files/ on my current disk is only 400 000. Did I really only keep 400 files on my first hard disk?

I'm pretty sure you have many times more than 400'000 files on your disk if you'll count files stored in archives (like .ods or .tbz2) separately. It makes sense for a filesystem (disk is very slow and CPU is fast) but not for memory (CPU is not that fast... yet). And even that changes nothing: even if we'll assume that objects are growing in size two times per five-six years (average size of file 20 years ago was 50-60KiB, today it's more like 1MiB) it buys your technique one doubling time - 1.5-2 years. The facts is: it's the trick of the same style as pread/pwrite wrappers. Why exchange one trick for another if it buys you pretty limited time? When you can safely drop BOTH tricks it'll make sanse - but this time didn't come yet.

Stories like this one will not promore 64bit software at all. You need more then 4GB of RAM for the 64bit more to shine, perhaps as much as 32GiB or may be even 128GiB. Till then... a lot of software writers will not care, most users will not care either.

Spin is spin, but...

Posted Oct 26, 2008 23:16 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

Sorry, but it's the other way around: positive effects must be measured and if the user won't notice there are no need to switch to 64bit yet. Why? Easy: we already have working 32bit stuff and 64bit stuff must prove itself before it'll be accepted. XP 64bit was total flop and Vista 64bit is not so hot either - and that's prerequisites! While there are no 64bit OS there are no 64bit programs... You need at least ONE program which shows that 64bit OS is worthwhile and even after that switch from 32bit to 64bit will be on case-by-case basis...

That MSFT still isn't able to ship a 64-bit OS while others had stuff running before the chips shipped is not exactly the architecture's fault...

Multi-gigabyte memories are commonplace today (heck, this laptop has 4GiB RAM), and anything with more than 4GiB can't be handled sanely with 32 bit architectures anyway.

SPARC64?

Posted Oct 26, 2008 22:52 UTC (Sun) by vonbrand (subscriber, #4458) [Link]

Sparc servers worked with such a model (64bit kernel, 32bit userspace) for years, why x86-64 must be different.

The situation is completely different between SPARC and SPARC64 than x86 and x86_64: There everything is twice as big, and only the need for more than 4GiB of memory space can force 64 bits. AMD learned from this mistake (and Itanium, and also from Pentium Pro's abysmal performance on then-current 16 bit code) and x86_64 programs are almost as dense as x86.

[Yes, I'm still sunning a SPARCstation Ultra 1]