> 64-bit software, a geeky term that, for now, pretty much means “faster.”
Ouch.
In general there's way too much fanboyishness in this article. I mean, seriously, it closes on a note of, "You can't see any improvements so JUST IMAGINE how much they've done under the hood!"
Your program is much larger due to 64-bit pointers.
The big speed drops will occur with cache misses. Your L1 and L2 cache are only so big, and every cache miss will set you speed back about an order of magnitude.
I believe in practice register renaming (http://en.wikipedia.org/wiki/Register_renaming) largely negates the difference in performance. Notice the mention of some CPUs having MORE registers than are nameable in the instruction set.
Depends on what your bottleneck is. For me, it's usually been memory rather than CPU. I was using 64bit, then switched to 32bit and saw a gigantic improvement in mem usage. (See slicehost vs linode comparisons etc)
Your argument refutes itself handedly because 32bit processes are limited to 4GB of address space. You've maxed out 1Gb now, how long before you max out 4Gb? Memory concerns are clearly the reason to go 64bit, the stuff about registers is icing on the cake.
Look at the big picture, whether it be pointers or integers into an array: the size of the index grows with the log of the number of things being indexed. You can't avoid this growth, but it matters less and less as you grow.
Evidence that it's really "about twice as much"? Much of what any given program stores will be things other than pointers.
According to http://www.springerlink.com/content/h6803610u1124354/ (actual article is behind a paywall; but the information I'm referring to is on the first page, which is shown) the typical increase in size for Java objects is 40%. I strongly suspect that most programs that use a lot of memory (which are the ones that matter) do so because they have big wodges of non-pointer data (long strings, images, matrices, ...) and therefore get a smaller-than-average size increase, but I have no actual evidence for this.
Anyway, you'd only get a 2x increase if every single byte of memory used by your program were either a pointer or an integer that changed from 32 to 64 bits on switching to 64-bit code (e.g., a long in C or C++, for gcc at least). That's gotta be far from the truth.
I think it's more like saying: replacing your car with a bus allows you to get more people to the destination more efficiently.
It's true -- if you have more people than the car could hold.
If you don't, the added overhead of using a bus will cause a comparative loss of overall performance.
Can someone explain what it does mean? Every time I download a Windows update and it asks me to pick from one of 10 options to download, I get angry. How am I supposed to know what bit of Windows I'm using?
The most obvious improvement is that 64-bit programs can address more memory -- more than 4 gigabytes of virtual memory in the same process. The less obvious bit that sometimes makes things faster is that when an x86_64 CPU is running in 64-bit mode it has access to more registers (basically the ultra-mega-low-latency memory for numbers and memory addresses and stuff that everything computed must pass through).
However, since pointers to blocks of memory are twice as large on 64-bit programs and many programs use lots of them, 64-bit programs usually use more memory, which means that there are more cache (the slightly less, but still ultra-low-latency memory that's between the registers and usual memory) "misses" -- i.e. things have to be grabbed more often from main memory, which relative to registers and cache is slow ... meaning that it eats some of the performance benefits of the extra registers.
In a nutshell, 64-bit programs are different. They're not "faster". The difference in bit-width really isn't something that makes a lot of sense if you don't know how CPUs work and can't be reduced to "faster".
One of the neatest features of SL I've found so far is the changes to the Services menu. It's now context sensitive so it will only show the services that are applicable to the data you have selected. Select text and you get text services. One of these text services is the ability to select any text and export it to iTunes as a spoken word track using the OSX speech synthesizer. I've been using it to select long articles, export them to iTunes, and sync them with my iPhone to listen to in my car. The OSX speech synth is good enough that it's a fairly pleasant experience.
There are hundreds more little tweaks. In all, Apple says that more than 90 percent of Leopard’s 1,000 software chunks were revised or polished. Many are listed at bit.ly/U1DzS
The fail is the fact that they used a link-obscurer/shortener for no benefit to me. Even the text around it doesn't give me any hint that I will be going to apple.com. The ___location isn't extraordinarily long, so it wouldn't have necessarily damaged the page layout, and they could have easily coded the link inside the text 'Apple's website', which would have given me a lot more information, and helped me in my decision to explore that link.
Finally, the link isn't even clickable to me. I had to copy it into the address bar.
I don't believe link-shorteners are inherently evil or destroying the internet, but seriously, why use them in an article like this? How does it help anyone (me, specifically)?
I guess that the article is the same as it was in the paper edition, which makes the shortifying more useful. They could have just written "check on Apple's website", of course. Or maybe even go through the trouble of editing the web edition.
xulrunner 1.9.1 displays <video> video much nicer than any Flash solution, in my experience. The controls are better looking and more fluid, and the video itself plays back more smoothly. (It also works with ALSA properly :P)
I have an iMac that first came out 2 years ago, and I do not notice either fan roaring or jumping and jittering. Is your experience with this on the laptops?
(I do, unfortunately, notice that the fan sometimes goes to medium in the middle of the night for no apparent reason. It's not quite annoying enough to shut down when I go to sleep, though).
Pogue says: "Techie note: Popular conception has it that the space savings comes from removing all the code required by those earlier chips. But that’s not true, according to Apple. Yes, that code is gone, but new 64-bit code, described below, easily replaces it. No, Apple says that the savings comes from “tightening up the screws,” compressing chunks of the system software and eliminating a huge stash of printer drivers. Now the system downloads printer drivers as needed, on demand."
One thing I have always done when reinstalling a Mac (rare) is not install those printer drivers. There's something like 1.3GB of them. Make the printers plug-and-play is great but that was just insane. I'm glad they're removing this.
Ouch.
In general there's way too much fanboyishness in this article. I mean, seriously, it closes on a note of, "You can't see any improvements so JUST IMAGINE how much they've done under the hood!"