Apple's sleek upgrade(nytimes.com)
nytimes.com
Apple's sleek upgrade
http://www.nytimes.com/2009/08/27/technology/personaltech/27pogue.html?_r=1&ref=technology
48 comments
x86_64 == more registers available than on i386
more registers == fewer spills
For the average compiled program, fewer spills == faster.
=> Average programs run faster under x86_64.
more registers == fewer spills
For the average compiled program, fewer spills == faster.
=> Average programs run faster under x86_64.
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.
I am not a hardware engineer though, so YMMV.
I am not a hardware engineer though, so YMMV.
And use about twice as much Ram. Personally I think 8 bytes for every single pointer seems wasteful for most programs.
4 extra bytes for a pointer is wasteful, but having an entire separate vector CPU just to make the windows transparent isn't?
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.
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.
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.
That's like saying extending a road from 4 miles to 4 million miles makes your car go faster.
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.
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?
What 64-bit means?
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".
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".
For non-subscribers:
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...
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...
Thank you!
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.
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
bit.ly/U1DzS > http://www.apple.com/macosx/refinements/enhancements-refinem...
That's a NYTimes fail, in my book.
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.
I'm sorry, am I not seeing it? Where's the fail
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)?
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.
wow you know I didn't even realize that when I was reading the article I had to copy and paste the link. It's been a long day.
A fail indeed.
A fail indeed.
I'm glad I'm not the only one who caught this. Who puts a shortened, unclickable link in a news article?
When the online version is a copy of the print version.
that's not even a reason, did they write it on a type writer?!
I complained to a friend of mine who works at the Times - they're fixing it.
bit.ly/U1DzS
"Buggy plug-ins (Flash and so on) no longer crash the Safari Web browser; you just get an empty rectangle where they would have appeared."
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.
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 will be thrilled if Flash stopped causing Safari to crash.
I'd be even more thrilled if Flash didn't make the CPU fans roar like a jet engine.
I'd be even more thrilled if Flash didn't make the CPU fans roar like a jet engine.
I'd be thrilled if Flash played back video without jumping and jittering.
id be thrilled if flash died as the defacto video player and made way for html 5's feature.
Which appears to be browser dependent and potentially horrible?
I'd be thrilled if browsers didn't play Flash with worse performance than standalone Projectors do.... ;-)
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).
(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).
MacPorts Snow Leopard compatibility list: http://trac.macports.org/wiki/snc/snowleopard
I'm pleasantly surprised that, of all the things I care about, only ghc is broken.
I'm pleasantly surprised that, of all the things I care about, only ghc is broken.
I've read about snow leopard but this is a fairly clear representation of just how much faster and smaller OS X should be with snow leopard
Looks nice, but I have CS3, and i am not going to pay for CS4. So looks like I am going to skip this one.
According to this
http://www.pcworld.com/article/170843/adobe_responds_to_snow...
CS3 works fine on Snow Leopard.
http://www.pcworld.com/article/170843/adobe_responds_to_snow...
CS3 works fine on Snow Leopard.
Same here, there is no stable version of 1Password yet for 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.
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.
1Password works fine in Snow Leopard with some small tweaks: http://www.switchersblog.com/2009/06/getting-1password-to-wo...
"The menu bar can now show the date, not just the day of the week."
Oh joy, oh joy!!!! Maybe I am going to upgrade after all (this really bothered me).
Oh joy, oh joy!!!! Maybe I am going to upgrade after all (this really bothered me).
[deleted](1)
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!"