Re:Apple's sleek upgrade
by wheels on Thursday August 27, 2009 @12:00AM
(#788603)
> 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!"
Re:Apple's sleek upgrade
by mhansen on Thursday August 27, 2009 @07:39AM
(#789024)
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.
Re:Apple's sleek upgrade
by litewulf on Thursday August 27, 2009 @05:08AM
(#788913)
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.
Re:Apple's sleek upgrade
by axod on Thursday August 27, 2009 @06:55AM
(#788979)
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)
Re:Apple's sleek upgrade
by chancho on Thursday August 27, 2009 @09:10AM
(#789125)
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.
Re:Apple's sleek upgrade
by gjm11 on Thursday August 27, 2009 @05:03AM
(#788909)
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.
Re:Apple's sleek upgrade
by roc on Thursday August 27, 2009 @12:15PM
(#789451)
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.
Re:Apple's sleek upgrade
by brandnewlow on Thursday August 27, 2009 @12:51AM
(#788649)
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".
Re:Apple's sleek upgrade
by jsz0 on Thursday August 27, 2009 @02:26AM
(#788774)
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.
Re:Apple's sleek upgrade
by dkokelley on Thursday August 27, 2009 @12:49AM
(#788645)
Off topic, but:
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
Re:Apple's sleek upgrade
by dkokelley on Thursday August 27, 2009 @01:17AM
(#788692)
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)?
Re:Apple's sleek upgrade
by m_eiman on Thursday August 27, 2009 @03:32AM
(#788836)
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.
Re:Apple's sleek upgrade
by jrockway on Thursday August 27, 2009 @04:59AM
(#788906)
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)
Re:Apple's sleek upgrade
by randallsquared on Thursday August 27, 2009 @09:37AM
(#789151)
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).
Re:Apple's sleek upgrade
by MikeCapone on Wednesday August 26, 2009 @11:55PM
(#788599)
You haven't read the article, eh?
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."
Re:Apple's sleek upgrade
by Timothee on Thursday August 27, 2009 @12:25AM
(#788626)
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!"
more registers == fewer spills
For the average compiled program, fewer spills == faster.
=> Average programs run faster under x86_64.
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 am not a hardware engineer though, so YMMV.
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.
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.
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.
This is a good start:
http://en.wikipedia.org/wiki/64-bit#Architectural_implicatio...
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".
Page 1 - http://www.google.com/url?q=http://www.nytimes.com/2009/08/2...
Page 2 - http://www.google.com/url?q=http://www.nytimes.com/2009/08/2...
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
bit.ly/U1DzS > http://www.apple.com/macosx/refinements/enhancements-refinem...
That's a NYTimes fail, in my book.
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)?
A fail indeed.
Yeah they nailed this one...
It's a good article, Leopard seems pretty impressive (half the size, twice the speed etc) but the author is very easily impressed.
I'd be even more thrilled if Flash didn't make the CPU fans roar like a jet engine.
(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).
I'm pleasantly surprised that, of all the things I care about, only ghc is broken.
http://www.pcworld.com/article/170843/adobe_responds_to_snow...
CS3 works fine on Snow Leopard.
It's the first time I don't feel in a hurry to upgrade, I mean snapiness is great but if it's in the same range as the 10.5.x upgrades, it can wait.
I havn't heard anyone saying he was really really impressed by how faster Snow Leopard is.
Oh joy, oh joy!!!! Maybe I am going to upgrade after all (this really bothered me).
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."