Hacker News Reader

Comment by podperson | Hacker News Reader

I don't think the problem was the zune itself but the zune ecosystem. Apple more than any competitor understood this. If all you want is a player for your existing music library, an iPod offers little advantage over any other decent music player, and the zune UI was very polished.

That said, the first thing that struck me about Windows 8 is that there's still a hard line between the 32- and 64-bit versions, which points to a fairly major underlying technical legacy in the current stack. So they need to go through another major revision (as in DOS -> NT) or hope 32-bit disappears (at least on the Intel side; it looks like they're planning on making the ARM side embedded/pre-installed only, so it won't matter so much).

View on HN

There are still plenty of people with hardware that has less than 4 GB of RAM. For those people, there's not generally an advantage in running a 64-bit OS if all their applications are available in 32-bit versions.

Aren't 64-bit processors a little more efficient at running a 64-bit operating system?

No. And for most programs, 64-bit code is probably less efficient than 32-bit code. Pointers are twice as big and instructions are generally longer, so less stuff fits into cache.

This is one disadvantage, yes. However all registers are now 64 bit, and in general, there are more of them.

Furthermore, the 4GB limit does not just concern physical RAM, it also applies elsewhere, like memory mapped files.

In general, it is unlikely that you will see poorer performance from 64-bit code compared to its 32-bit counterpart.

Most of the memory used by programs are pointers, and if you double your pointer size, it has a negative impact on the efficientcy of the L1 and L2 cache.

Yes, this is exactly what CurtHagenlocher said.

>> Most of the memory used by programs are pointers

This is a huge generalization, may I add.

Yes, I will not argue that cache usage is less efficient, but I am sure you know that register access is faster than cache access, and we double the amount of registers in x64.

To quote Donald Knuth, a 64 bit program would "waste half the memory [and] effectively throw away half of the cache".

You may double the number of registers, but you are still shuffling tons of data between your caches and memory, and that is going to be your constraint for most programs. Losing half of the 4mb or 12mb of your L2 or L3 cache because you use 64 bit pointers has a much bigger impact than doubling the number of registers.

For almost every architecture out there the transition to 64-bits made existing code run more slowly for the reasons you describe, but on x86 the 64 bit transition also doubled the number of registers, guaranteed that SSE2 was available, and did some other stuff that actually made most code run faster.

However, I believe Google is working on some program to let people use all the goodies in x86-64 while also using 32-bit pointers.

>or hope 32-bit disappears

sadly, this might take another 10 years or so...

For the legacy problems, I found a VMWare + old OS in virtual machine solution really usable. Especially when some magic is applied to window management to have it seamlessly integrated in the host OS.

It would free MS from so much pain if they'd bless this setup and get rid of the administrative hurdles (licenses, registration, genuine check etc.).

They do have a solution: http://www.microsoft.com/windows/virtual-pc/default.aspx

I've never used it though, as I already have old XP media and like using Virtualbox.

Reply on news.ycombinator.com