Turns out for general purpose software you do need an OOO engine.
An OOO engine lets you extract concurrency from non-concurrent code.
Multiple register sets and multithreading let you take advantage of concurrency in concurrent code.
Concurrent code is much harder than linear code, so you get a win on more code from OOO than from CMT.
One reason that Sun is so big on multiple register sets is that they got really good at it early on because the Sparc design pretty much needs it, because they have so many registers to flush on a context switch otherwise, thanks to the register stack.
[what didn't work] Oh, a bunch of stuff. I couldn't compile code without hours of additional installation (some of which had to be retrieved from the Internet, but that's probably been fixed on the currently shipping model). Um, OpenLDAP required expert work, too. [...] I was purposely testing it beyond the vendor's paradigm and the mac afficionados really don't need to get upset that I didn't have a religous epiphany as soon as I touched the case.
That's kind of what I expected. If you're doing rocket scientist stuff (and LDAP still seems pretty rocket-scientist to me, where's the "lightweight" bit anyway?) the fact that Apple's made non-rocket-scientist stuff work doesn't help. Also, Mac OS X really isn't a server OS by today's standards, even though Darwin is based on one. HFS+ isn't UFS, and it's missing some pretty important things like tape drive support.
The cost of an Xserver, or any of the other apps people have mentioned, are $0.00 on the PC platforms I use
Can you tell me what you use? I haven't found one on Windows that just works for our application other then the two I mentioned... the main problem seems to be conflicts between the Windows and X11 color models.
I find that GUIs are slow, limiting, and crash-prone because I am comfortable with a CLI
Me too: my Mac OS X desktop ALWAYS has at least 4 terminal/xterm windows open at any time... that's why I didn't switch until a couple of years ago. I had to be convinced that Apple really had got it right. And they pretty much have convinced me.
For me, Mac OS X is a lot more of a real UNIX than Linux is, even. Yes, Fink has some weird packaging decisions, and Darwinports could be more complete, but I just went through three weeks of sheer agony trying to put together the right set of packages to get Red Hat Enterprise to build a particular set of applications to upgrade a customer system. This isn't all RH's fault, since I was having to do screwy things like run a particular version of Java because one app had a nasty memory leak on more recent ones. But still, on FreeBSD I got 90% of the way there with "cd/usr/ports/... ; make install". For me, FreeBSD "just works" in that kind of environment better than Linux, Mac OS X, Windows, or anything else. But on my desktop? Mac OS X wins, and there's no second place.
All operating systems suck, in different ways. The thing about Mac OS X is that it mostly sucks in ways that don't keep it from being really good for people who just want an appliance that works. And those are the people for whom "it just works" is hardest to do, and for whom "it just works" is most important.
Basically that breakthrough is already here -- functional programming.
Well, sorta. I know intellectually that FP is good, but none of the FP languages I've played with have really grabbed me the way UNIX pipes did. Syntax matters, otherwise people would be just as happy with SQL as with UNIX pipes and filters. After all what's the difference between
SELECT files FROM filesystem WHERE directory IN (SELECT home FROM passwd WHERE user IN (SELECT user FROM diskhogs));
Freescale is not making the e600 in quantity yet, and I doubt Post-6/6 Apple will design a new MB for a chip they're only going to be shipping for a year or two anyway.
It would still have made sense for pre-6/6 Apple, even without the dual core, because the core isn't the bottleneck on the G4... the 166 MHz bus is.
That has not been my experience [that it really does just "plug in and work", like an appliance].
What didn't "just plug in and work"? You didn't say that.
I got my employers to buy me a mac mini for evaluation purposes. The idea was to put the code developers on native Xwindows instead installing Xservers on Windows XP systems.
You're using a Mac mini for software development? Um, dude, OK, you can do that... but that's not exactly a $300 PC job.
You can't do anything meaningful with a mac mini until you quadruple the memory, was what I found.
Double is more than enough unless you're building a compile engine or something, if you're just using it as an X console, well, I'm using an old Powermac with 256M at work... and it works at least as well for that as the company-provided PC with half a gig. And that X server software isn't cheap: a licensed copy of Unixlink pays for a gig of RAM for a mini, a licensed copy of Exceed costs as much as a mini all by itself. Or are you leaving those costs out of your comparison?
But 512M is a price/capability sweet spot... that's what I ended up getting in mine, and the extra cost of the RAM was comparable to the cost of the same extra RAM I needed when I last upgraded my son's PC: that $300 PC doesn't come with enough RAM either. In my opinion both Apple and HPDELL are shortchanging buyers there, but Apple no more than anyone else.
The mouse and keyboard? $20 total if you shop around, and if you pay more than $50 you're not even trying to be frugal.
Display? Same displays as the PCs.
And don't forget the value of "it just works". My daughter switched from a PC to an old iMac. She ended up really abusing the Mac... going in and randomly deleting files from/Applications to make space... and it kept on "just working". Her PC, I'd been having to reinstall every 3-6 months. That's why it's worth a bit more... the PC may be priced like an appliance, but the Mac is an appliance.
I know this sounds ridiculous, but at this rate, computers will sell for so cheap that if you're an electronic hobbyist in need of a capacitor to build your latest project, it will be cheaper to buy a brand new computer and unsolder one from the motherboard than to buy a capacitor at Radio Shack.
Except that they won't have discrete capacitors on the motherboard. Because, well, they don't. back in the '70s Robert Anton Wilson predicted that computers would get so cheap you'd throw them away because they were cluttering up the place, you'd get them in your breakfast cereal.
You know, we probably hit that point ten years ago. We were certainly there by 2000 when I tossed out a Windows CE handheld that was more powerful than the university minicomputer I was sharing with 35 other users back when Wilson wrote that line... because it had a battery problem, it wasn't worth my time fixing it, and nobody else wanted it either.
Technically, if PCs are going for $300 and a Mac goes for $500, that's about 1.666 times more expensive, which rounds up to 2 times more expensive
Or it rounds down to 1.5 times as expensive, or it rounds sideways to buggywhip-sidecar as expensive in the Bizzarro universe. When the Mac mini came out, it was about $100-$150 more than a typical entry level PC. Now it's $200 more, c'est la vie.
It's still a better deal both absolutely and relatively than the traditional factor of 2-3 that you had previously been stuck with if you wanted to get into Mac desktops. And I do mean "a factor greater than 2.00 but usually less than 3.00", not "It's currently missing 1.5 by one-sixth so I'm going to round up by twice that much and call it 2".
And it really does just "plug in and work", like an appliance.
The main problem with paralelism for the general application is the current model. The "Event Model" that is used nowadays as the basic processing model for applications specifies that the program will stay idle until the user press a key or moves the mouse (or push buttons).
But that's good. If the program has no useful work to do... if it's waiting for the user to do something... then it should be idle so it doesn't use CPU time that other programs may need.
The world is full of programs that busy-wait already, whether they do it with a thread or by setting timers to put extra actions in the event loop. Most of them are not actually doing anything useful with that little bit of business, they're just badly written.
If a program DOES have work it needs to do, that can actually make a difference to the user, then it should kick off a background process or thread to do it. But right now there's way too many programs that sit there using a few percent of my CPU obsessively checking on the state of something they should be handling in the main event loop.
Another way to use multithreading could be from the Operating System, so the programs [that do not require] multithreading wont have to deal with it BUT the operating system would use the multithreading capacities to schedule the processes execution.
Um, that's what every modern operating system DOES. The last desktop OS that didn't do native concurrent multitasking was Mac OS 9, and Steve Jobs has not only staked it in the hear, he's cut its head off, stuffed its mouth with garlic, and poured holy water and weedkiller on the corpse. And if that's the only good thing to come from the Mac X86 transition, well, it might even be worth it.
The best example is GNU sort, which does I/O... sort... I/O... sort... I/O... sort, alternating quite inefficiently until a final merge. If GNU sort could take advantage of multiple CPUs it would run quite a bit faster, and sorting by divide-and-conquer is one of the most easily-parallelized processes.
Sorting is one of those areas where heroic measures are worthwhile, because improvements are such a huge win, and the operation is conceptually simple and widely usable.
Sorting is also a big problem for the UNIX pipeline because the input has to complete before any output can start. It's kind of an exception to my general rule: concurrency for performance reasons is a nightmare, but some nightmares you just have to deal with.
Every time someone exposes concurrency at some layer as a way of improving performance, rather than because you're implementing a process that's inherently concurrent, it's a huge clusterfuck. Doesn't matter whether it's asynchronous I/O, out-of-order execution, multithreaded code, or whatever. Even when you're dealing with a concurrent environment like a graphical user interface the most successful approaches involve breaking the problem down into chunks small enough you can ignore concurrency.
One of UNIX's most important features is the pipe-and-filter model, and one of the really great things about it is that it lets you build scripts that can automatically take advantage of coarse-grained concurrency. Even on a single-CPU system, a pipeline lets you stream computation and I/O where otherwise you'd be running in lockstep alternating I/O and code.
That's where the big breakthroughs are needed: mechanisms to let you hide concurrency in a lower layer. Pipelines are great for coarse-grained parallelism, for example, but the kind of fine grain you need for Niagara demands a better design, or the parallelism needs to be shoved down to a deeper level. Intel's IA64 is kind of a lower level approach to the same thing where the compiler and CPU are supposed to find parallelism that the programmer doesn't explicitly specify, but it suffers from the typical Intel kitchen-sink approach to instruction set design.
Last line of the summary: "But while they are priced like consumer electronics, the machines still aren't even remotely as easy to use, and the trend lines there aren't particularly encouraging."
That's what you're buying with the $200 difference. A Mac's still expensive for an entry-level PC, but it's not 2-3 times as expensive any more.
For a large vendor there's QA, marketing, and support costs.
Those aren't costs for building the app.:)
OK. They do exist, but unless Apple does something truly horrible they'll be lower for this than for just about every transition I've ever been through. Including 8.1 to 8.5, 8.6 to 9.0, 10.1 to 10.2, 10.2 to 10.3, and 10.3 to 10.4. So long as Apple provides OS upgrades for PPC (and they've previously provided OS upgrades for old hardware for 4-5 years after the new hardware came in... which in this case means past 2010 even for the Mac mini, and 2012 for whatever they supplant near the end of 2007) there's not going to be a major problem.
They did briefly open a similar hole with Widgets auto-installing in Safari, but they closed it real quick like.
They didn't open it then, it's been open since the first time Safari was shipped. It's a hole called "open safe files after downloading". It's not really similar to the problems in Internet Explorer: it doesn't normally lead to malicious code execution without further action from the user, and you can turn it off.
It's like checking into a hotel and realise the tap in the next room is dripping and calling the concierge who comes and turns it off, compared to checking into a hotel and waking up to discover your bed's afloat in sewage... and there's nobody at the reception desk.
Dashboard itself is an example of how Microsoft should have implemented the HTML control. Webkit has no mechanism to run local code: Dashboard extends its instance of Webkit to allow it. Webkit run from any other application (Safari, say) doesn't even have those hooks installed, so there's no potential way to trick it into letting you run as a widget no matter how you try.
Except that for some bizarre reason Apple decided that widgets were "safe files".
Sheesh.
There are no safe files, but if there were safe files, widgets aren't among their number.
It's as if you can't open a menu without a "BUY ITUNES MUSIC" or "BUY GARAGEBAND ACCESSORIES" options being thrust in your face. You can't move for invitations to pay stump up more cash for.Mac. Your USB webcam doesn't work? Why not buy an iSight?
THe.Mac on install thing is irritating, but I don't see where you're getting the rest of that. You can turn it off, even in iTunes. I go days without running into Macvertising.
Boy, you must have a heck of a time with the ad banners on every page on slashdot.
Problem is most modules look like they came from the eighties.
Which means they don't chew up a lot of CPU time and make my computer's fan turn on full blast. WIth most of the Mac OS screen savers these days I feel like I need a CPU saver to go along with them.
Slashdot Mirror
Seriously, what's next?
Pink floyd getting back together.
I bet we'll see something more cost effective in an Intel architecture soon.
:)
I doubt changing the CPU is going to make that much of a difference to the cost.
I'll eventually get around to putting BSD or linux on the mac mini
You already have BSD on it.
Turns out for general purpose software you do need an OOO engine.
An OOO engine lets you extract concurrency from non-concurrent code.
Multiple register sets and multithreading let you take advantage of concurrency in concurrent code.
Concurrent code is much harder than linear code, so you get a win on more code from OOO than from CMT.
One reason that Sun is so big on multiple register sets is that they got really good at it early on because the Sparc design pretty much needs it, because they have so many registers to flush on a context switch otherwise, thanks to the register stack.
So why do these films do so poorly in America?
They don't get the advertising and the news coverage, and don't open in as many theatres?
And how do you install the trustworthy keyboard and OS on a computer in an internet cafe?
Linus is not a zealot. He is an advocate.
Linus is pretty cool, just as long as you don't get into the "M" word.
Being BSD is actually more than enough for me on my servers, but it's not so good on the desktop.
:)
Depends on whether your idea of a good desktop is Gnome or KDE, or Mac OS X.
[what didn't work] Oh, a bunch of stuff. I couldn't compile code without hours of additional installation (some of which had to be retrieved from the Internet, but that's probably been fixed on the currently shipping model). Um, OpenLDAP required expert work, too. [...] I was purposely testing it beyond the vendor's paradigm and the mac afficionados really don't need to get upset that I didn't have a religous epiphany as soon as I touched the case.
/usr/ports/... ; make install". For me, FreeBSD "just works" in that kind of environment better than Linux, Mac OS X, Windows, or anything else. But on my desktop? Mac OS X wins, and there's no second place.
That's kind of what I expected. If you're doing rocket scientist stuff (and LDAP still seems pretty rocket-scientist to me, where's the "lightweight" bit anyway?) the fact that Apple's made non-rocket-scientist stuff work doesn't help. Also, Mac OS X really isn't a server OS by today's standards, even though Darwin is based on one. HFS+ isn't UFS, and it's missing some pretty important things like tape drive support.
The cost of an Xserver, or any of the other apps people have mentioned, are $0.00 on the PC platforms I use
Can you tell me what you use? I haven't found one on Windows that just works for our application other then the two I mentioned... the main problem seems to be conflicts between the Windows and X11 color models.
I find that GUIs are slow, limiting, and crash-prone because I am comfortable with a CLI
Me too: my Mac OS X desktop ALWAYS has at least 4 terminal/xterm windows open at any time... that's why I didn't switch until a couple of years ago. I had to be convinced that Apple really had got it right. And they pretty much have convinced me.
For me, Mac OS X is a lot more of a real UNIX than Linux is, even. Yes, Fink has some weird packaging decisions, and Darwinports could be more complete, but I just went through three weeks of sheer agony trying to put together the right set of packages to get Red Hat Enterprise to build a particular set of applications to upgrade a customer system. This isn't all RH's fault, since I was having to do screwy things like run a particular version of Java because one app had a nasty memory leak on more recent ones. But still, on FreeBSD I got 90% of the way there with "cd
All operating systems suck, in different ways. The thing about Mac OS X is that it mostly sucks in ways that don't keep it from being really good for people who just want an appliance that works. And those are the people for whom "it just works" is hardest to do, and for whom "it just works" is most important.
Basically that breakthrough is already here -- functional programming.
/etc/passwd | awk -F: '{print $6}' | xargs ls -l
Well, sorta. I know intellectually that FP is good, but none of the FP languages I've played with have really grabbed me the way UNIX pipes did. Syntax matters, otherwise people would be just as happy with SQL as with UNIX pipes and filters. After all what's the difference between
SELECT files FROM filesystem WHERE directory IN (SELECT home FROM passwd WHERE user IN (SELECT user FROM diskhogs));
and
fgrep -f diskhogs
Freescale is not making the e600 in quantity yet, and I doubt Post-6/6 Apple will design a new MB for a chip they're only going to be shipping for a year or two anyway.
It would still have made sense for pre-6/6 Apple, even without the dual core, because the core isn't the bottleneck on the G4... the 166 MHz bus is.
That has not been my experience [that it really does just "plug in and work", like an appliance].
/Applications to make space... and it kept on "just working". Her PC, I'd been having to reinstall every 3-6 months. That's why it's worth a bit more... the PC may be priced like an appliance, but the Mac is an appliance.
What didn't "just plug in and work"? You didn't say that.
I got my employers to buy me a mac mini for evaluation purposes. The idea was to put the code developers on native Xwindows instead installing Xservers on Windows XP systems.
You're using a Mac mini for software development? Um, dude, OK, you can do that... but that's not exactly a $300 PC job.
You can't do anything meaningful with a mac mini until you quadruple the memory, was what I found.
Double is more than enough unless you're building a compile engine or something, if you're just using it as an X console, well, I'm using an old Powermac with 256M at work... and it works at least as well for that as the company-provided PC with half a gig. And that X server software isn't cheap: a licensed copy of Unixlink pays for a gig of RAM for a mini, a licensed copy of Exceed costs as much as a mini all by itself. Or are you leaving those costs out of your comparison?
But 512M is a price/capability sweet spot... that's what I ended up getting in mine, and the extra cost of the RAM was comparable to the cost of the same extra RAM I needed when I last upgraded my son's PC: that $300 PC doesn't come with enough RAM either. In my opinion both Apple and HPDELL are shortchanging buyers there, but Apple no more than anyone else.
The mouse and keyboard? $20 total if you shop around, and if you pay more than $50 you're not even trying to be frugal.
Display? Same displays as the PCs.
And don't forget the value of "it just works". My daughter switched from a PC to an old iMac. She ended up really abusing the Mac... going in and randomly deleting files from
I know this sounds ridiculous, but at this rate, computers will sell for so cheap that if you're an electronic hobbyist in need of a capacitor to build your latest project, it will be cheaper to buy a brand new computer and unsolder one from the motherboard than to buy a capacitor at Radio Shack.
Except that they won't have discrete capacitors on the motherboard. Because, well, they don't. back in the '70s Robert Anton Wilson predicted that computers would get so cheap you'd throw them away because they were cluttering up the place, you'd get them in your breakfast cereal.
You know, we probably hit that point ten years ago. We were certainly there by 2000 when I tossed out a Windows CE handheld that was more powerful than the university minicomputer I was sharing with 35 other users back when Wilson wrote that line... because it had a battery problem, it wasn't worth my time fixing it, and nobody else wanted it either.
Technically, if PCs are going for $300 and a Mac goes for $500, that's about 1.666 times more expensive, which rounds up to 2 times more expensive
Or it rounds down to 1.5 times as expensive, or it rounds sideways to buggywhip-sidecar as expensive in the Bizzarro universe. When the Mac mini came out, it was about $100-$150 more than a typical entry level PC. Now it's $200 more, c'est la vie.
It's still a better deal both absolutely and relatively than the traditional factor of 2-3 that you had previously been stuck with if you wanted to get into Mac desktops. And I do mean "a factor greater than 2.00 but usually less than 3.00", not "It's currently missing 1.5 by one-sixth so I'm going to round up by twice that much and call it 2".
And it really does just "plug in and work", like an appliance.
The main problem with paralelism for the general application is the current model. The "Event Model" that is used nowadays as the basic processing model for applications specifies that the program will stay idle until the user press a key or moves the mouse (or push buttons).
But that's good. If the program has no useful work to do... if it's waiting for the user to do something... then it should be idle so it doesn't use CPU time that other programs may need.
The world is full of programs that busy-wait already, whether they do it with a thread or by setting timers to put extra actions in the event loop. Most of them are not actually doing anything useful with that little bit of business, they're just badly written.
If a program DOES have work it needs to do, that can actually make a difference to the user, then it should kick off a background process or thread to do it. But right now there's way too many programs that sit there using a few percent of my CPU obsessively checking on the state of something they should be handling in the main event loop.
Another way to use multithreading could be from the Operating System, so the programs [that do not require] multithreading wont have to deal with it BUT the operating system would use the multithreading capacities to schedule the processes execution.
Um, that's what every modern operating system DOES. The last desktop OS that didn't do native concurrent multitasking was Mac OS 9, and Steve Jobs has not only staked it in the hear, he's cut its head off, stuffed its mouth with garlic, and poured holy water and weedkiller on the corpse. And if that's the only good thing to come from the Mac X86 transition, well, it might even be worth it.
The best example is GNU sort, which does I/O ... sort ... I/O ... sort ... I/O ... sort, alternating quite inefficiently until a final merge. If GNU sort could take advantage of multiple CPUs it would run quite a bit faster, and sorting by divide-and-conquer is one of the most easily-parallelized processes.
Sorting is one of those areas where heroic measures are worthwhile, because improvements are such a huge win, and the operation is conceptually simple and widely usable.
Sorting is also a big problem for the UNIX pipeline because the input has to complete before any output can start. It's kind of an exception to my general rule: concurrency for performance reasons is a nightmare, but some nightmares you just have to deal with.
Every time someone exposes concurrency at some layer as a way of improving performance, rather than because you're implementing a process that's inherently concurrent, it's a huge clusterfuck. Doesn't matter whether it's asynchronous I/O, out-of-order execution, multithreaded code, or whatever. Even when you're dealing with a concurrent environment like a graphical user interface the most successful approaches involve breaking the problem down into chunks small enough you can ignore concurrency.
One of UNIX's most important features is the pipe-and-filter model, and one of the really great things about it is that it lets you build scripts that can automatically take advantage of coarse-grained concurrency. Even on a single-CPU system, a pipeline lets you stream computation and I/O where otherwise you'd be running in lockstep alternating I/O and code.
That's where the big breakthroughs are needed: mechanisms to let you hide concurrency in a lower layer. Pipelines are great for coarse-grained parallelism, for example, but the kind of fine grain you need for Niagara demands a better design, or the parallelism needs to be shoved down to a deeper level. Intel's IA64 is kind of a lower level approach to the same thing where the compiler and CPU are supposed to find parallelism that the programmer doesn't explicitly specify, but it suffers from the typical Intel kitchen-sink approach to instruction set design.
Last line of the summary: "But while they are priced like consumer electronics, the machines still aren't even remotely as easy to use, and the trend lines there aren't particularly encouraging."
That's what you're buying with the $200 difference. A Mac's still expensive for an entry-level PC, but it's not 2-3 times as expensive any more.
i know someone who knows the person that runs this site
Oh right, like we should believe these "friend of a friend" anecdotes?
Yeh, I know, DEC put an x86 emulator on the BIOS of the Alpha so it could run intel card firmware during boot, so it's almost beleivable...
But it would be a lot easier to replace the whole cube motherboard, not just the ZIF.
I have a better idea.
/foo/../../../ type attacks in the first place!
Use a webserver that's not subject to
Seriously, my trace-cut Cuecat still works perfectly.
For a large vendor there's QA, marketing, and support costs.
:)
Those aren't costs for building the app.
OK. They do exist, but unless Apple does something truly horrible they'll be lower for this than for just about every transition I've ever been through. Including 8.1 to 8.5, 8.6 to 9.0, 10.1 to 10.2, 10.2 to 10.3, and 10.3 to 10.4. So long as Apple provides OS upgrades for PPC (and they've previously provided OS upgrades for old hardware for 4-5 years after the new hardware came in... which in this case means past 2010 even for the Mac mini, and 2012 for whatever they supplant near the end of 2007) there's not going to be a major problem.
They did briefly open a similar hole with Widgets auto-installing in Safari, but they closed it real quick like.
They didn't open it then, it's been open since the first time Safari was shipped. It's a hole called "open safe files after downloading". It's not really similar to the problems in Internet Explorer: it doesn't normally lead to malicious code execution without further action from the user, and you can turn it off.
It's like checking into a hotel and realise the tap in the next room is dripping and calling the concierge who comes and turns it off, compared to checking into a hotel and waking up to discover your bed's afloat in sewage... and there's nobody at the reception desk.
Dashboard itself is an example of how Microsoft should have implemented the HTML control. Webkit has no mechanism to run local code: Dashboard extends its instance of Webkit to allow it. Webkit run from any other application (Safari, say) doesn't even have those hooks installed, so there's no potential way to trick it into letting you run as a widget no matter how you try.
Except that for some bizarre reason Apple decided that widgets were "safe files".
Sheesh.
There are no safe files, but if there were safe files, widgets aren't among their number.
It's as if you can't open a menu without a "BUY ITUNES MUSIC" or "BUY GARAGEBAND ACCESSORIES" options being thrust in your face. You can't move for invitations to pay stump up more cash for .Mac. Your USB webcam doesn't work? Why not buy an iSight?
.Mac on install thing is irritating, but I don't see where you're getting the rest of that. You can turn it off, even in iTunes. I go days without running into Macvertising.
THe
Boy, you must have a heck of a time with the ad banners on every page on slashdot.
Problem is most modules look like they came from the eighties.
Which means they don't chew up a lot of CPU time and make my computer's fan turn on full blast. WIth most of the Mac OS screen savers these days I feel like I need a CPU saver to go along with them.