Apple's new OS geared for multicore future
Apple began shipping Snow Leopard on Friday, but the true importance of the Mac OS X update likely will emerge well afterward.
That's because Mac OS X 10.6 begins a longer-term Apple attempt to get ahead by cracking a problem facing the entire computer industry: squeezing useful work out of modern processors. Instead of stuffing Snow Leopard with immediately obvious new features, Apple is trying to adjust to the new reality in which processors can do many jobs simultaneously rather than one job fast.
"We're trying to set a foundation for the future," said Wiley Hodges, director of Mac OS X marketing.
Apple shed some light on its project, called Grand Central Dispatch, at its Worldwide Developer Conference in June, but most real detail was shared only in with programmers sworn to secrecy. Now the company has begun talking more publicly about it and other deeper projects to take advantage of graphics chips and Intel's 64-bit processors.
The moves align Apple better with changes in computing. For years, chipmakers such as Intel and Advanced Micro Devices had steadily increased the clock rate of their processors, and programmers got accustomed to a performance boost with each new generation. But earlier this decade, problems derailed the gigahertz train.
First, chips often ended up merely twiddling their thumbs more because slower memory couldn't keep the chip fed with data. Worse, the chips required extraordinary amounts of power and produced corresponding amounts of hard-to-handle waste heat.
And so began the mainstream multicore era, in which processors got multiple computing engines called cores that work in parallel. That's great for some tasks that can be easily broken down into independent pieces, but programmers were accustomed to a more linear way of thinking where tasks execute in a series of sequential steps.
Enter Grand Central Dispatch, or GCD. This Snow Leopard component is designed to minimize many of the difficulties of parallel programming. It's easy to modify existing software to use GCD, Apple said, and the operating system handles complicated administrative chores so programmers don't have to.
Overall, Illuminata analyst Gordon Haff believes, the computing industry really is only beginning now to tackle parallel programming in earnest. If building mature parallel programming tools is a 10-chapter book, the industry is only at chapter two right now, he said. But with no other alternative, the book will be written.
"It has to happen," Haff said. "If you look at history of information technology, things that have to happen really do happen."
Burdensome threads
One way programmers have dealt with the arrival of multicore processors--and with the multiprocessor machines that preceded them--is through a concept called threads. There are various types, but generally speaking, a thread is an independent computing operation. For programmers to take advantage of multicore processor, they assign one thread to each core, and away they go, right?
Not so fast. Threads come with baggage. Each requires memory and time to start. Programs should be broken up into different numbers of threads depending on how many cores a processor offers. Programmers have to worry about "locking" issues, providing a mechanism to ensure one thread doesn't change data another thread is already using. And one threaded program might step on the toes of another running at the same time.
Some tools to ease the difficulties, such as Intel Threading Building Blocks, are available, but threads remain complicated.
"We looked at this and said it needs a fundamental rethink. We want to making developing applications for multicore easier," Hodges said. "We're moving responsibility for the management code into the operating system so application developers don't have to write and maintain it."
Blocking and tackling
The core mechanisms within GCD are blocks and queues. Programmers mark code chunks to convert them into blocks, then tells the application how to create the queue that governs how those blocks are actually run. Block execution can be tied to specific events--the arrival of network information, a change to a file, a mouse click.
Apple hopes programmers will like blocks' advantages: Older code can easily be retrofitted with blocks so programmers can try it without major re-engineering; they're lightweight and don't take up resources when they're not running; and they're flexible enough to encapsulate large or small parts of code.
"There's a lot of overhead around threading that means you want to break your program into as few pieces as possible. With Grand Central Dispatch, we say break your program into as many tiny pieces as you can conceive of," Hodges said.
Another difference with the Grand Central Dispatch approach is its centralization. The operating system worries about managing all applications' blocks rather than each application providing its own oversight. That central view means the operating system decides which tasks get which resources, Apple said, and that the system overall can become more responsive even when it's busy.
Other foundations
There's a second mechanism in Snow Leopard that gives a new way for programmers tap into hardware power: OpenCL, or Open Computing Language. It lets computers use graphics chips not just to accelerate graphics but also some ordinary computations.
To use OpenCL, programmers write modules of code in a variation of the C programming language called OpenCL C. Snow Leopard translates that code on the fly into instructions the graphics chip can understand and transfers necessary data into the graphics system memory. Many tasks won't benefit, but OpenCL is good for videogame physics simulation or artificial intelligence algorithms, technical computing chores, and multimedia operations.
The three major makers of graphics chips--Intel, Nvidia, and AMD's ATI--have endorsed OpenCL, and the Khronos Group has made it a standard. That means programmers are likely to be able to reuse their OpenCL code with Windows applications, too.
Graphics processors employ parallel engines that suit them for running the same processing chore on many data elements. For computers without a graphics chip, though, OpenCL also can employ that parallel execution strategy on ordinary multicore processors.
The 64-bit transition
Apple began its 64-bit transition years ago with the PowerPC processors it used before switching to Intel chips. With Snow Leopard, nearly the full suite of its software--Mail,
Safari, Finder, iChat, QuickTime--become 64-bit programs.
Intel chips these days are 64-bit, but what does that get you over 32-bit chips? Briefly, it can let heavy-duty programs use more than 4GB of memory, improve performance by offering more chip memory slots called registers, and speed up some mathematical operations.
Moving to a 64-bit design doesn't guarantee instant speedup, though. In one developer document, Apple states: "Myth: My application will run much faster if it is a 'native' 64-bit application. Fact: Some 64-bit executables may run more slowly on 64-bit Intel and PowerPC architectures." One issue: the doubled length of references to memory addresses.
Apple encourages programmers to test their software to see if the 64-bit incarnation is faster. All Apple's own applications that moved to 64-bit versions are faster, the company said.
The 32-bit kernel
However, the core component of Mac OS X, the kernel, is still 32-bit software by default on consumer machines such as MacBooks and iMacs. Apple has written it so that applications can handle more than 4GB of memory, though, and the kernel can manage it all.
In its developer document on 64-bit performance, Apple states: "Myth: The kernel needs to be 64-bit in order to be fully optimized for 64-bit processors. Fact: The kernel does not generally need to directly address more than 4 GB of RAM at once."
Apple's 32-bit kernel hits limits with very large amounts of memory, though. "Thus, beginning in Snow Leopard, the kernel is moving to a 64-bit executable on hardware that supports such large memory configurations," its Xserve server line and Mac Pro workstations, the company said.
The tricky aspect of moving from a 32-bit kernel to 64-bit kernel is that drivers--software that let the operating system communicate with devices such as printers, video cards, and hard drives--must also be 64-bit. That's not so bad when it's a hardware device under Apple's control, but it's harder to move the full collection of third-party devices with their own drivers.
Apple argues it's not hard to make the jump, though. "As a driver developer, you must update your drivers with 64-bit binaries. Fortunately...many drivers 'just work' after changing the compile settings," the company said in a reference document.
This all may sound very low-level, but for programmers, Apple actually is working at a higher level than most. That could be an asset since many attempts to embrace parallel programming imposed more demands than most programmers were willing or able to handle.
And attracting programmers is key. Ultimately, Apple's deeper technology moves such as Grand Central Dispatch and OpenCL will be a success only if the company can get other developers to use them.
Stephen Shankland writes about a wide range of technology and products, but has a particular focus on browsers and digital photography. He joined CNET News in 1998 and since then also has covered Google, Yahoo, servers, supercomputing, Linux and open-source software, and science. E-mail Stephen, or follow him on Twitter at http://www.twitter.com/stshank. 
Reread it. Multi-threading is not the same thing...
The trouble is, to write your application to make use of the multicore processors is a herculean task. Apple simplifies the process, it is now so easy, there is no reason a developers won't take advantage of it. That is the big deal.
Also, Microsoft has dragged its feet in the process of moving to 64-bit. Windows 7 will 'only' support 192GB of RAM. That is 15,808 less GB than Snow Leopard.
Windows server x64 since 2003 R2 supported 2TB of RAM.
Vista x64 supports 128GB, which is kind of artificial limitation, given that it's the same kernel as Win server 2008.
Unless you count 32-bit Windows....
Actually, multithreading is the same thing. What GCD offers has been around for ages. On Windows we have had the NT thread pool since Windows 2000, and Critical Sections for ages. Apple is playing catch-up here, not doing anything original.
If you want to look at what's cool and modern in multi-threaded development, look at Windows 7's user-mode scheduler and the Concurrency Runtime (with really cool functionality like the parallel_for_each() and lambda expressions in C++) or the TPL in .NET.
@theveggiedude
Windows led the way in 64-bit on the desktop. Windows had a fully (top to bottom) 64-bit release of XP in early 2005. The vast majority of Windows Vista machines sold today come with a 64-bit OS (including a 64-bit kernel).
The 192GB of memory "limit" is what's been tested. The kernel supports 2TB of physical memory, but that can be extended.
I know exactly what mult-threading is and what it's for since I was working with applications back then that did use it on multiprocessor machines. Have you ever seen the inside of a compaq proliant 3000 server with 4 pentium mmx processors? I used to rebuild them.
It seems to me that GCD and OpenCL are potentially very exciting so long as the developers play ball.
OpenCL ---- give it a couple years. Even with an application that can benefit from it, you're looking at having to tune for each video card on which it runs. May be OK for Apple at one instant in time, but as soon as a new card or faster CPU come out, code may run but the optimization decisions change. That's OK for games, which only have a year or two lifecycle, but not major apps.
I would also like some support to your claim the GCD can be outdone with careful coding. I would tend to agree with you, but how many programmers out there are that careful or that skilled? I doubt I could do it and all of my bosses have expressed that I am nearer the top of the developer field. If you can do it, good for you, but having a process built in that will add speed and simplicity for the majority of developers seems like a pretty good thing.
In comparison to Microsoft's open programming environment (.NET, DirectX) yep those are not proprietary. Lets see, Apple provides its full development suite for free and also includes other open source programing languages in the OS
Also please list any programs that the code is not already different for windows and os x. So how can offering GCD lock in a developer. GCD is for optimizing os x code and is optional. If you have not used how do you know it will not improve app performance.
That's true in the sense that there's nothing written in Objective-C or Java or .Net that couldn't be written in assembly language. It's not that it _couldn't_ be done before, it's that it's _easy_ to do now.
That's the whole point with "modern" development environments like .Net and Cocoa. To provide more and more pre-packaged functionality. The idea behind GCD is raise the multi-processing bar up higher then threads. It's not something that couldn't be done before, it's something that's now much more accessible.
GCD is a language-based infrastructure for parallel programming. It offers simplicity by reducing flexibility (something in which Apple specializes). It is implemented using the same underlying OSX primitives already available to programmers. So by definition a programmer can do anything GCD can, plus more, and with more specialized code can make it more efficient than GCD (particularly by minimizing unnecessary locking). Will GCD help some folks? Sure. Is it a ground-breaker that can improve best-in-class apps? Nope.
@buststyles ---- sure, the UI code is different between Win and OSX. But on substantial programs that can benefit substantially from multithreading, that UI code sits out on the periphery, often in cross-platform libraries of one kind or another (eg TrollTech). The GCD stuff goes into the middle, the core algorithms. Having different major versions isn't appealing.
MS and Apple are having a war for developers, being used as a pawn isn't fun, and I don't think it benefits end customers or society at large much of the time. But I do like the way this guy thinks: http://www.youtube.com/watch?v=KMU0tzLwhbE
Now if the app only runs on OSX then GCD sounds like a great thing to jump on right away.
So all this talk about bits is nice and all but but it doesn't mean diddly if nobody's buying them.
There is NO need to buy a new Mac if you want to upgrade.
Although I have to agree that right now, Apple laptops (the new ones) are more expensive than ever. =/
There is no 32/64 split on Apple platforms. The 32-bit machines and 64-bit machines co-exist, and have for many, many years, since before the Intel transition. That is under the surface. You do not even need to know it's happening unless you are a technology enthusiast. You can see in this article that these are developer technologies. Developers have to make adjustments to their apps. I have Mac apps on my computer right now that have 4 binaries in them: 32-bit PowerPC, 32-bit Intel, 64-bit PowerPC, and 64-bit Intel. When I launch an app like that, the system chooses the right binary automatically. I not only don't have to know my OS is 32 or 64, I don't even need to know that my apps are 32 or 64. This is called Fat Binaries and has been going on since forever. The 68k to PowerPC transition was done this way. NeXT systems ran on 68k and 486 using Fat Binaries.
The user does not need to know or care about 32-bit or 64-bit at any time on the Mac platform. The mess that is on Windows is not on the Mac. We started going 64-bit in 2003 and we have gradually transitioned and Snow Leopard is the END of that transition, not the beginning. Most of Leopard was 64-bit, and parts of Tiger and Panther also.
> if they want to stay current on their OSs (Sleopard or Wista), they need to replace their laptops and PCs.
No, you are 100% wrong. All Intel Macs run Snow Leopard. All of them. There is no such thing as a MacBook that can't run Snow Leopard. It will make your Mac run faster than it did with either Leopard or Tiger for Intel. It will cost $29. There is nothing to complain about as far as I can tell. The only machines that can't run Snow Leopard are 5 years old by now, and Leopard will be supported for them for another 2 years concurrently with Snow Leopard. By the time Mac OS 10.7 comes along, the machines that won't run it will be 7 years old. That is the typical time between when you buy a Mac and when you can no longer upgrade the OS further. It's twice the lifetime of the machine.
> both Apple and Microsoft
I have a great tip for you. Any time you put "Apple" and "Microsoft" in the same sentence or thought, you are almost surely wrong. There is just no similarity at all. Apple is in consumer electronics and sells direct to consumers, while Microsoft is in the PC industry and is an OEM, they sell to HP, Dell, Lenovo, Acer, etc. not to consumers. Very few Microsoft products are sold at retail, even when you include their house brands Zune and XBox, neither of which make any money, while Apple is one of the top retailers in the world, their 5th Avenue store may have the highest gross sales of any 5th Avenue retailer. Apple is a hardware company from Silicon Valley, while Microsoft is a software company that is deliberately not in Silicon Valley and which always talks negatively about Silicon Valley. Apple is famous for having very, very high product quality standards and Microsoft is famous for exactly the opposite. Apple has had a remarkably successful 21st century, while Microsoft sold a lot of XP and that's about it. Apple creates integrated devices and Microsoft has always done kits, even before the IBM PC and DOS they always did kits. Apple is very, very focused, making a remarkably small array of products, all very closely related, all consumer electronics, while Microsoft loves to go into new markets, they make a search engine, they make an online service, they make Web server software. Microsoft is all about office computing and I-T departments, while Apple is in publishing and audio video and multimedia. And more to your point, they have radically different policies surrounding software and hardware upgrades. Windows 7 is a refinement of unsuccessful Vista but costs full price, while Snow Leopard is a refinement of successful Leopard and it is 20% of full price. There's just no point in comparing.
If you have something to say about Microsoft, just say it. Same with Apple. Come up with something true about them and just say it. Don't try and make a statement that covers both. That lead you to declaring that you need a new MacBook for Snow Leopard (wrong) or you need a new Mac for 64-bit (wrong) or that you get less price performance on a Mac (wrong, you get ten times as much for only double the price).
> So all this talk about bits is nice and all but but it doesn't mean diddly if nobody's buying them.
Mac sales are the best ever. Snow Leopard is highly-anticipated. The Mac and OS X user bases have just continued to grow and grow this century. Every Mac since 2005 can run Snow Leopard, and for hardware older than that, Leopard is just as good and also includes 64-bit components. So I don't see at all how your statement applies to Apple or Mac OS X or Snow Leopard.
begone u expensive, under performing, media hyped macs.
PS. If I am not mistaken, Apple was far ahead of Microsoft in the 64 bit race. The early G3 computers were 64 bit (Around 1995).
Nothing you wrote is true.
Linux was originally a single user, single threaded OS. This heritage made the introduction of multi-threading difficult. Windows NT was multi-threaded (and multi-user) from the very start. Linux got multi-processor support in the 2.0 kernel, but there was a global spinlock that made it nearly useless. 2.2 kernel improved that a bit, but it wasn't until 2.4 that multi-threading really worked at all, and wasn't until 2.6 that it became reasonably good.
OS X had a similar history with multi-threading. While its underlying Mach micro-kernel had good multi-threading support, the FreeBSD monolithic kernel that sat on top did not. Much worse, there were several architectural flaws that severely hindered threading scalability, such as the "split funnel" hack. They got rid of that in Tiger and made significant improvements in Leopard. That brought it much closer to being on-par with Windows NT of the 90s.
Snow Leopard brings OS X into this decade and finally probably matches Windows 2000 (and later) in this regard, although the software ecosystem built on OS X likely can't leverage a lot of this without apps being updated.
Don't get me wrong, GCD does some cool and even innovative things, particularly at the higher level with intuitive language features and some useful tricks for things like queuing up callbacks that need to run on the UI thread. And they deserve praise for all the good work they've done there.
But don't distort history and pretend that OS X has been some kind of pioneer in the space of multi-threading support, or that Windows has ever been "behind" in this regard. Not only is it laughably inaccurate, but it's an unfair comparison to older architectures (like OS X's Mach/FreeBSD underpinnings) versus the far newer and modern NT codebase, which had the benefit of hindsight and learning from those earlier Unix and VMS models and the ability to improve upon them from the start.
Apple didn't have a fully 64-bit OS until last week. Their first "64-bit computer" was the G5 which couldn't even leverage any meaningful 64-bit capabilities until Leopard came out (and couldn't even run a single line of 64-bit code until Tiger).
Windows first had 64-bit support in the mid 90s on the Alpha versions of Windows NT. The first top-to-bottom fully 64-bit version of Windows was released in 1999.
I look forward to having many a civil and intelligent discussion with you.
That is not a Myth. When 32 bit instructions have to process 64 bit instructions you have to use more cpu cycles.
Most applications are 32-bit, and you don't run 64-bit instructions on 32-bit kernel.
"64-bit processors can run 2 32-bit instructions at the same time."
This may be possible with some emulation software, but it is my understanding, please correct me if I am wrong, that a 64 bit processor run either in 64 bit mode or 32 bit mode, but not both. So if a processor is processing 2 32-bit instructions it would be through software emulation which would probably negate the speed increases from running 2 Instruction sets on one CPU cycle. In addition wouldn't there be a race condition problem?
"and you don't run 64-bit instructions on 32-bit kernel." No you do not run 64 bit code on a 32 bit OS, but the Myth is implying that a 32 bit kernel would run fully optimized for a 64-bit processors.
@Seaspray0
I understand that a 64 bit processor does not run the i386 instruction set any faster. The CPU cycles I was referring to was the extra CPU cycles a 32 bit OS kernel has to do to emulate a 64 bit processor much like the way PAE works. PAE allows 32 bit OSs to access memory using 36 bit addresses rather than the standard 32 bit barrier but it sacrifices CPU cycles in order to do so.
Maybe it's just me.. but Quicktime, Safari, Mail, Finder, and iCal literally FLY now.. the SL upgrade made an enormous difference in the performance of these applications. It maybe due to something other going 64-bit.. but there is a very noticeable difference.
Correct, the code has been optimized and I have no doubt there is a noticable difference due to that.
It's so overdue it's ridiculous.
But the core i5 quad will be an inexpensive, lower power, lower heat quad chip, and the iMac should get this chip. We'll see if Apple again asks Intel for a special higher clock version of it, as some of the proposed core i5s seem to have pretty low clock speeds.
You make my mouth water. One day, I will have a Core i7 desktop. For now, I'm anticipating the arrival of my $1,000 BestBuy gift card (MyCokeRewards sweepstakes), with which I intend to purchase a Studio XPS laptop. I can't wait!
Fastest in terms of CPU clock speed, maybe, but not overall performance. Macs really are decent mainstream machines, but their graphics are midway at best, nothing to scream about. The graphics in a $2,500 MBP don't match those of a Dell XPS or Studio XPS.
Sure, other high-end laptops may have better graphics but who needs them? Serious gamers aren't interested in playing games off a laptop. More powerful GPUs eat your battery faster, which is why the MBP has two GPUs, and you use the slower one if you want better battery life. I doubt there's a big enough demand for high end graphics on MBPs; if there were Apple would offer them.
>>>>I do, for one. I dabble around with video and photo editing a bit, and will sometimes go to people's houses to work on PowerPoint slideshows for memorial services. Some of these slideshows are actually synchronized to the rhythm of the accompanying music, which calls for manual transitions and real-time recording of screen and soundcard for subsequent conversion to DVD for presentation. PowerPoint alone can get pretty heavy, especially when you get into complex animations with words and paragraphs. And if you intend to do all this, AND simultaneously record sound and screen activity at more than 30 FPS with fluidity, you need a powerful system. And I can't exactly lug my desktop unit around; I need a laptop with the power to do these things.
'Serious gamers aren't interested in playing games off a laptop.'
>>>>I wouldn't venture to say that. Of course, you'll want a desktop unit with a quad-core processor, RAID, and dual GPUs to get the most out of gaming, but there are gamers who want something with both portability and the power to play Crysis.
'More powerful GPUs eat your battery faster, which is why the MBP has two GPUs, and you use the slower one if you want better battery life.'
>>>>Correct, and I know that the MB and MBP will outlast almost any competing PC. But along with general power saving options for portable use, you have other options, including SSDs and better batteries. Personally, I am planning on adding a 9-cell battery, 128 GB Intel X25-E SLC SSD, and an additional 4 GB of RAM in the future to this laptop I'm looking at. And this is the beauty of the PC; I can upgrade.
'I doubt there's a big enough demand for high end graphics on MBPs; if there were Apple would offer them.'
>>>>If the demand was not there, then you wouldn't see XPS (not to be confused with Studio XPS) and Alienware laptops in BestBuy's inventory. I can assure you there is a demand, and that is not the issue; the issue is that most titles run on Windows and nothing else. Sure, you could install Windows in Boot Camp, but there's another problem; you can't upgrade a Mac's hardware. If a new need arises that effective renders your existing hardware obsolete, you have to buy a whole new machine. PCs are upgradeable.
Macs have their niche, and perform quite well in that niche. But gaming is not one of its aspects. The GeForce 9600M GT is sufficient for what is expected of the MBP. You mentioned "other high-end" laptops. Apple computers are not "high-end" machines; true high-end machines cost as much as $10,000. The Studio XPS I'm looking at has a C2D 2.4 GHz processor with 1066 bus, 4 GB of DDR3 1066 MHz, 512 MB Radeon M86XT graphics, and more. This is a high-end "mainstream" unit, but not a true high-end unit.
"In both client and server versions, you can boot supported computers into 64-bit mode by holding down the 6 and 4 keys at startup time or by adding arch=x86_64 to your boot-args string using the nvram command. In Mac OS X Server, you can force 32-bit booting by holding down the 3 and 2 keys or by adding arch=i386 to your boot-args string."
That's from this developer page:
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/KernelExtensionsandDrivers/KernelExtensionsandDrivers.html
The XBOX division of Microsoft has been profitable since 2008.
Thanks again!
It seems that very few day-to-day apps (word processing, financial) really benefit from the speed increases. It seems the beneficiaries are games, graphics, and high end, really large scale database or scientific modeling programs.
Is there a real benefit for ordinary computer users beyond games and graphics?
Sure there is. Do you ever make zip archives, use a torrent client or edit home videos, use a program written in java, run another OS in a virtual machine? Lots of things will benefit from the speed increase.
There is some benefit but it is not that great in most applications. The overhead of shared L1 cache negate much, as well as message passing. It is not unheard of for programs to gain nothing, and even slow down when trying to rewrite it to take advantage of multicores.
For the average user, the biggest gains are in an application running in 1 processor, and another in a second, no cache syncing issues. The vast majority of desktop applications take so little CPU time, and are restricted by massive bottlenecks such as the network and user that even with subsystems like spell checkers running in a thread there is little gain in running in on multi cores.
Actually, multithreading is the same thing. What GCD offers has been around for ages. On Windows we have had the NT thread pool since Windows 2000, and Critical Sections for ages. Apple is playing catch-up here, not doing anything original.
If you want to look at what's cool and modern in multi-threaded development, look at Windows 7's user-mode scheduler and the Concurrency Runtime (with really cool functionality like the parallel_for_each() and lambda expressions in C++) or the TPL in .NET.
@theveggiedude
Windows led the way in 64-bit on the desktop. Windows had a fully (top to bottom) 64-bit release of XP in early 2005. The vast majority of Windows Vista machines sold today come with a 64-bit OS (including a 64-bit kernel).
The 192GB of memory "limit" is what's been tested. The kernel supports 2TB of physical memory, but that can be extended.
As for the rest of your opinion, I don't feel the need to lock myself into the M$ way of doing things just to check their threading models. I know how great M$ security actually is because I have a memory that goes beyond yesterday and wouldn't trust their garbage .NET with my worst enemies computer.
umm on my c drive theres a folder called program files,right under it theres a folder called program files (x86) and i have a photoshop and photoshop (64bit),,,
Correction: You can run both 32 and 64 bit applications simultaneously in any 64 bit Windows OS. Also the user does not have to decide, either. The same is true for all 32 bit versions of Windows in relation to 16 bit, the OS would determine which to use.
For proof, on a Windows 64 bit OS box bring up task manager. Processes marked with *32 are processes running as 32 bit. The user does not have to make a decision as it is automatic.
The only choice the user has to make is which version of the OS to install, 32 bit vs 64 bit. The user needs to determine this, of course, before purchasing or installing. The main factor would be availability of 64 bit hardware drivers.
So, you know better than the experts? Why don't you set them straight, then? As it were, you live in yesterday, comparing the security of your current OS with that of an eight-year-old competitor. And furthermore, you're blaming MS for not addressing drive-by downloads when they didn't even exist yet!
Vista's security has been proven not only superior to that of OS X, but vastly so. Security researchers who are new to OS X (Charlie Miller) start digging in and pulling up bugs right away, later to tell the media that he stuck with Apple because he could render 10 or more Mac exploits in the amount of time it takes to render ONE for Vista. Nils, who hacked into both platforms, not only says that Windows 7 is getting harder to break into (and this was BEFORE Safe Unlinking, XPM, and behavior monitoring were added), but that the Mac could become a target if bot herders start running out of exploitable XP machines. And you never know when this could become the case; not only is Windows 7 believed to be an XP killer, but more and more AV vendors are adding browser protection to their products. When drive-by downloads stop working on Windows, criminals have two choices: 1) Revert back to Trojan horses and suffer huge losses. 2) Focus on the most vulnerable platform still on the market, OS X.
Sorry to bust your bubble, but science trumps religion.
Are you trying to spread disinformation or just incredibly ignorant?
64-bit versions of Windows have been running 32-bit programs side-by-side for ages. The LLP64 model used by Windows actually makes it *easier* to port 32-bit applications to 64-bit (since ints and longs stay 32-bit, and longlong is used for 64-bit values just like before). Neither model affects the ability to run actual 32-bit programs though, so it's weird of you to bring it up.
64-bit versions of Windows run 32-bit programs with zero performance penalty. In fact because the kernel and Win32 subsystem are completely 64-bit, they often run faster (mainly due to GDI and USER taking good advantage of those extra registers). This is quite different from Snow Leopard on current hardware where 64-bit programs are actually prevented from attaining ideal performance due to the use of a 32-bit kernel (syscall results in switching modes, VA limits and the kernel juggling them around, etc).
Windows users don't decide between 32-bit and 64-bit. They go to Best Buy and they buy a computer running Windows Vista (soon Windows 7) and they get a fully 64-bit OS that runs all their 32-bit programs. They don't have to restart the Control Panel to load 32-bit ones, they just work. The integration is completely seamless.
.NET is an ECMA standard (just like JavaScript, for example).
Apple's "blocks" stuff is just like "tasks" (which are usually represented as lambda expressions / anonymous functions) in the Windows model, which as I said are supported not just in .NET but also in plain old native C++ on Windows (and C++0x is adopting them into the standard). So you can write in C++ using tasks and STL for_each or the new parallel_for_each sort of thing, and not worrying about threads at all, all while pretty easily targeting any OS that supports the latest C++ standards. Or you can use .NET and target Windows and Mono with the industry's best tools, a rich and modern type-safe language with garbage collection and JIT compilation for various CPUs. Did I mention both get to use the awesome new user-mode scheduling support in Windows 7 so that you can switch tasks without incurring a context switch like you would with threads? Right, that's because Windows is doing something *new* and not playing catch-up like Apple always is.
Of course if you want to write for the Mac you have to use Apple's proprietary and obscure Objective C junk and their Cocoa APIs. It's not as well known, established, or portable as C++ - and it doesn't have any of the modern managed programming features and capabilities of .NET. But it's different! Yay! It's the worst of both worlds! No wonder developers are lining up... Oh wait.
ikamerica was spot on, multithreading is just a very small part of what GC - or for that matter any other concurrency architecture - is about. The idea of separating task submission and execution isn't new, but GC offers a whole layer of abstraction on top of this as do other technologies that you mention such as Concurrency Runtime. However what set it apart is that it is an OS-wide service and is therefore able to make dynamic decisions across all running programs on how best to split up the task queue.
Compare that to the Concurrency Runtime which is a library layer on top of the OS. Because of this you are responsible for creating the logic yourself such as worrying about the number of CPUs available to you: the bar of expertise for accessing the concurrent features of the OS are that much higher.
I'm not saying there aren't a bunch of cool technologies available for Windows (7?) or that GC won't be leapfrogged in the future, but you are wrong if you are trying to suggest it offers nothing substantially new.
"Windows led the way in 64-bit on the desktop. Windows had a fully (top to bottom) 64-bit release of XP in early 2005. The vast majority of Windows Vista machines sold today come with a 64-bit OS (including a 64-bit kernel)."
If you want to be technical about it, there were quite a few fully 64-bit Unix-based workstations (real computers, that did engineering, CAD and design work, that would fit on or under a desk) available way before 2005, we're talking early 90's. So no, Windows did not lead the way to the 64-bit desktop by far. Just to name a few: In 1994 SGI IRIX/MIPS was 64-bit, OSF/1 AXP (aka Tru64 Unix) running on Alpha, UltraSparc running Solaris...
I said desktop PCs, not workstations or servers. Clearly there have been fully 64-bit options in those other markets for much longer (including fully 64-bit Windows NT releases in the mid 90s).
Yeah, but you have to limit yourself so much to use it that hardly anyone installed it. The Mac approach is just to make it all work together, and I think that is worth a lot. Of course, if you wanted to make your mac a no-32 bit zone (say you were Wintarded, for example) you could do it.
64bit OS.. yeah right...
Most advanced OS... uh huh
no viruses... oh yeah thats a great one.. why did they incorporate anti-virus onto an OS that couldnt get virii?!
Apple users are shelling out 29.00 for 6gb of hdd they should have had to begin with, access to HW they paid for to begin with and minor tweaks that should have been free.
Snow Leopard doesn't include anti-virus. It is a malware scanner when downloading files within Safari. Nobody can protect against a trojan masquerading as innocent software but requests your password so that it can do nefarious damage. Understand, malware requires you to (a) download it and (b) authorize it to run by you entering your password. It's like a burglar knocking on your door to rob your house, and not only do you open the door, but you give him the key.
A virus is a completely different beast, and you should know that. A virus can self-propagate, can be transferred to your computer without your knowledge, and can execute on its own, doing its damage without needing any permission from you. The 90,000 viruses are specifically a Windows problem. OS X was built with security in mind.
>>Apple users are shelling out 29.00 for 6gb of hdd they should have had to begin with, access to HW they paid for to begin with and minor tweaks that should have been free.
Your comments are unbelievable. Every version of OS X gets faster, and here with Snow Leopard, dramatically faster and optimized code that regains even more hard drive space than you claim by many reports. Meanwhile, Windows gets more bloated every release and requires more resources, often necessitating purchasing a newer computer to run it smoothly (a la Vista). Microsoft and Intel always used Moore's law as a marketing method to force the re-purchase of computers.
Reports of users installing Snow Leopard consistently state that it's like "they have a new computer" -- more space, more speed. I'd rather spend $29 to make my computer run faster with more available drive space then have to buy a new computer just to run the newest version of Windows.
Apple was 64 bit when they built their G3 computers. Apple was Multi core when they built their G3 computers (Around 1995 if I remember).
The only difference now is:
It is much simpler to write code that takes advantage of more than one core.
The code runs faster than if it was divided up by threads.
Code that runs faster in 64 bits is 64 bit. Code that runs better in 32 bit runs in 32 bit.
64 bit code is great when you are dealing with large numbers or big blocks of memory. It is slower when you are only dealing with 32 bit data. Use the right tool for the job. (That is why Apple asks developers to profile their code in both 32 and 64 bits, then ship the one that runs faster).
Virtually every Vista machine you find at stores today (or order from a PC maker) is 64-bit. How can you say "hardly anyone installed it?" This just demonstrates your ignorance of the Windows world. There are WAY more 64-bit Vista machines out there than there are any kind of Mac...
@ralfthedog
Apple has announced "64-bit" as a feature at least 4 times now. Leopard was the first time they kind of sort of started to deliver on it, and now with Snow Leopard they're almost there, or at least will be on new hardware when the 64-bit kernel starts to get enabled.
The G3 was not 64-bit nor multi-core. Even the G5, which Apple trotted out as "the first 64-bit PC" or whatever was not 64-bit in any meaningful way... which was especially ironic since there were already *real* 64-bit PCs that weren't from Apple. Sure the CPU supported 64-bit memory addressing, but the OS didn't. And that move didn't even involve a new instruction set since PowerPC always supported 64-bit. It was just marketing, there was nothing to it at all.
Then they switched to Intel CPUs which at the time had no 64-bit support at all (i.e. the original Core CPU). Then they launched 64-bit again when they got 64-bit Intel CPUs... even though their OS still didn't make any real use of them and the only apps that could use it couldn't have UI! Then they launched it again with Leopard, even though none of the OS was 64-bit. Now they're launching it again even though the kernel isn't 64-bit on current hardware. But they're pretty much there, finally...
Oh, and 64-bit code isn't slower with 32-bit values. A 32-bit value is still a 32-bit value. The only thing that's bigger are pointers (on Windows at least... pointers and "long" values are bigger on OS X because they went with LP64 model for whatever reason, so you have to change your code to make it work the same). And the extra memory used by having 64-bit pointers is negligible compared to the performance benefits of the AMD64 instruction set and larger address space.
The only reason Apple might tell you that 64-bit code would be slower would be due to OS issues, most likely a result of still having a 32-bit kernel.
You are mistaken about most aspects you mention for the G3.
The first G3 models were in late 1997. The G3 is a 32-bit PowerPC processor, as are the earlier 601, 603 and 604 series which Apple used. You might be thinking of the PowerPC 620, which was the original 64-bit design and it was announced around the time of the first PowerMacs (1994), but Apple never used it.
The G5 was the first true 64-bit processor which Apple used, initially in 2003. It can address more than 4 GB, and do 64-bit arithmetic.
The first multi-processor Mac was a dual 180 MHz PowerMac 9500 in 1995. After the 9600 was replaced by the G3 (1997), the next dual-processor model was a PowerMac G4 in 2000. The G3 wasn't able to do multi-core or multi-processor.
After 2000, most mid-range and high-end PowerMac G4s and PowerMac G5s had dual processors.
The first multi-core processors used by Apple were in PowerMac G5s from late 2005. The high end model was dual-CPU and dual-core (4 cores in total).
There is only one Intel Mac which doesn't have at least a dual core processor: the original entry level Intel Mac Mini (1.5 GHz Core Solo).
The 64-bit features of the G5 have been supported to an increasing degree since Apple introduced it in mid 2003.
Mac OS X 10.3 (late 2003) supported more than 4 GB of RAM installed in a G5, but only supported 32-bit processes.
Mac OS X 10.4 (early 2005) added support for 64-bit processes but not with a graphical user interface, e.g. servers or command line tools. A single 64-bit process on a G5 running on 10.4 or later can use more than 4 GB of RAM.
Mac OS X 10.5 (late 2007) added support for 64-bit processes which use the Cocoa framework, thus 64-bit GUI applications are possible on a G5 running 10.5.
For the average user, the biggest gains are in an application running in 1 processor, and another in a second, no cache syncing issues. The vast majority of desktop applications take so little CPU time, and are restricted by massive bottlenecks such as the network and user that even with subsystems like spell checkers running in a thread there is little gain in running in on multi cores.
Intel is pushing multicores because it is an easier way to keep people on the upgrade treadmill, not for any real benefit for the average desktop user.
- by artistjoh August 31, 2009 9:29 PM PDT
- Not only do I love that this article is in-depth and an intelligent examination of some software rather than the usual rehash of press releases and blogosphere opinion that passes for reviews these days - I love the fact that the commenting posts are also intelligent discussion.
- Like this Reply to this comment
-
Showing 1 of 2 pages (84 Comments)Thanks guys