I bought something through Google Checkout from a vendor I've been buying from for years, never had any trouble with them.
Despite my clear indication of the "don't spam me" preference, I started getting regular, frequent, promotional mailings.
The "stop getting mail from this merchant" thing didn't work.
Google's support desk didn't respond to queries.
The merchant couldn't do anything about it, since they have no control; they can forward mail to Google for "our customers", but that's it.
Google's only "unsubscribe" option is "prevent any messages, whether they're order-related or not, sent by this merchant, from reaching me."
Pretty much never gonna use that again, believe me. They don't allow you to opt out of purely promotional bulk mailings without completely severing all contact. If you later use their system to buy from a merchant, then you are immediately back on ALL the promotional stuff for that merchant, because you were never actually removed from the list; they were just blocking mail to you from that merchant. You can't have a way to communicate, without being spammed.
Will they fix it? I don't know. After multiple spams and heroic efforts to get anyone in the checkout group to do anything, I did eventually stop receiving mail, but so far as I know, they have no plans to fix the underlying system.
I can beat that. The language Greet has the specification that an empty input file (or indeed, any other) is a program directing the language to print "Hello, world!"
In fact, K&R presents a complete Greet interpreter very early on.
I used TaxAct last year. Haven't touched TurboTax in years --Intuit are fairly nasty and willful spammers, with a long history of abuses, spyware, and other charming traits. TaxCut was okay, but they ditched the Mac, so I had to go with something else anyway, and H&R Block is not one of my favorite companies; I'm sure they get taxes okay, but they don't understand computers or web pages very well.
Have you done anything on the gamecube? So far as I can tell, the Wii's got about a 50% overclock and some extra memory, but is otherwise very similar to the same hardware.
I am not sure what it has for rendering; obviously, comparing GC to PS2 games, it had SOME kind of rendering features.
Because the PS3 does HDCP on DVI, too, so it won't display to a non-HDCP monitor that way either. (Or through a non-HDCP console switch, etcetera; you get the idea.)
I was at GameStop today putting down my $5's to get Burning Crusade and Wario Ware tomorrow.
I was there about an hour before they opened. There were two guys standing outside. I came back. Turns out that they get a line, 4-5 people, EVERY DAY. Waiting for Wiis. (The sign saying they have PS3s has been on the door for at least a week.) They get about two shipments a week, which sell out instantly.
So, that particular store, 8-10 a week. That's not all that many, but everyone else has the same thing.
No, OS X is still running on Mach. FreeBSD userland, lots of NetBSD and FreeBSD kernel code ON TOP OF MACH... (BTW, that is the "4.4" code base in many cases)... But still Mach under the hood.
You can easily verify this by writing pretty much any code at all on OS X, and noticing the use of mach ports.
I can think of many things that would tend to cause both crime and income inequality. I can also think of things that would cause only one, or the other. I am not sure how we'd isolate these or determine what the relationship is.
It's been shown long since. The flexibility and smoothness of control are unequaled, and now the question is just how well developers will use it.
The Wii control scheme is not just a gimmick; if it were, there wouldn't still be new players trying one and then going out and waiting in line in the cold in the hopes of getting one.
I posted it because I have come closer to peeing myself laughing reading the "rebuttals" to Carmack's position than I ever expected to do before I turned 70.
I figured that Slashdot users would get a kick out of reading something that reminds us of just far we've come. I mean, compared to that thread, jokes about Natalie Portman and Hot Grits are practically computer science!
I am well aware of the software cache, and auto-SIMDization. I was involved in getting the tutorials on those topics prepped last fall, and I've done a bunch of other writing on this. I am a big fan of Cell, and I spend more time than is probably healthy immersed in reading or writing about it.
The software cache imposes a fair number of cycles of latency per access even when the datum in question is in the cache; it's even slower when the datum isn't in the cache. Is it useable? Certainly. However, it's going to give you a serious performance hit, especially when used heavily. You can't just use it and get full performance from the SPE without worrying about local store; you have to use it sparingly only for access to large chunks of data, while keeping the bulk of the data you're working on in local store all the time. It does not solve the problem; it mitigates it.
The auto-SIMDization stuff does not make scalar code efficient. What that does is, in some cases, automatically convert scalar operations on arrays into vector operations on the same arrays. It doesn't solve the more general problem of operations that aren't being performed on whole arrays; those stay slow. what's impressive is that they handle the alignment problems involved in vectorizing, e.g., a[i] = b[i + 1] * c[i + 3];, not that they have magically cured the problem.
So we're back to where we started. The cell development support and compiler can give you comparative ease of use, but you lose a lot of the performance potential of the processor. All those theoretical numbers you see are based on the assumption that you are doing 90% of your calculations with no latency; not waiting for DMA, not accessing a cache, and so on.
So, really, you do have to do a lot of extra work to get the theoretical performance, or even very close to it. The software cache and other techniques mitigate this, so you can get enough performance from the SPEs to benefit from them somewhat without having to do anything exceptionally elaborate, but they don't give you the theoretical performance. If you want that performance, you have to do a lot of fiddly little management of, for instance, the tiny local store available on the SPEs. If you want to have that handled automatically, you take a very noticeable performance hit.
If you don't predict a branch, the SPE grinds to a halt for some ludicrous number of cycles while it fetches new instructions. The SPE has a huge decode buffer, and you need to warn it well in advance of where new instructions will be coming from if it's going to decode them in time. I don't know why you're saying they ren't pipelined, either; they are.
That it may be a wonderful opportunity, if you can overcome it, doesn't change the fact that the cost of developing a game for PS3 will be higher than the cost of developing a similar game on the 360. It may look a lot better, but so what? You have to sell enough copies to cover your costs.
So, it sounds to me like you haven't DONE any Cell development.
There's a huge difference between Cell and "PPC with vectors". It's called local store. Each SPE has 256KB of local storage. You have to have your code in there, and then stream data through. That means you have to do a fair amount of setup and partitioning specifically around that 256KB limit, which wouldn't apply on a multi-core PPC. That's a real issue, and you can't just paper it over for real projects.
And yes, in theory, the tools should be able to hide some of that from you. That's why Carmack's comments about the tools are so damning. If there has ever been an architecture which desperately needs polished and mature tools, this is it.
Also, I don't know where you get the idea that SPEs can do scalar code. They are 100% vector-only. The closest they can get is to emulate scalar code by ignoring the rest of a vector while manipulating only its first slot. That can be done, but it leaves you with a very slow processor spending a lot of its time masking things out and merging vectors together. (or, if you just omit those slots, and use only one slot out of each potential vector, your data takes much more space; 4x as much for 32-bit objects, 16x as much for bytes.)
I don't think you quite follow the essence of the complaint.
With the absolute best tools conceivable, even with tools that we don't even have the technology to build, Cell will still be harder to develop for than a more conventional processor.
Yes, it's more powerful; probably a LOT more powerful. It's still mork work to get anything done.
Your claim tht it will be "easier" as it allows "better division of code and work" is just plain nonsense. Any division of code and work I can do on a multi-core system, I can do on a single-core system, too. That division is already available to me. The extra work Cell imposes is that I have to divide it asymmetrically; I can't just partition the task in whatever chunks the task makes sense in, I have to partition a lot of it in terms of the very specific requirements of the SPEs.
That work won't go away, even with perfect tools. It's harder, and it will always be harder.
I think it's probably worth it for supercomputing. I'm less sure that it's worth it for consoles, because game development costs are a plague upon the industry, and making them worse won't help.
Will it get easier than it is now? Yes, but the underlying fact that it is "harder to program and takes a little more time" won't. What might change is that, right now, it takes a lot more time; that might be plausibly reduced. But, in the end, making Cell just as easy as a multicore SMP system is in the same bin as lossless compression that is guaranteed to compress ALL possible inputs.
The trend towards and away from specialized processors comes and goes.
I think Carmack's view of the PS3 is a lot more realistic than yours. He's talking from the perspective of someone who has to ship a product or his friends don't eat. You're talking about what would be nice if programmer time were free.
FWIW, I have a PS3, which I am using to do Cell development. It really is very impressive... And it also really is a lot more work than a more traditional multicore system. The decision to specialize an extra time here reflects Sony's PS2 design (crappy CPU with two very impressive and non-interchangeable vector processors to make up for it), and I think it also reflects Sony's arrogance; they simply assume that, of course, people will be willing to spend twice as long developing software on their system to get a noticeable but not earth-shattering improvement in performance.
This thread has been one of the funniest things I've ever seen. All the PS3 fanboys are bashing Carmack for his comments about Cell, despite the fact that it's quite clear none of them program at all, let alone program on asymmetric CPUs.
Hilarity ensues as people who would have been lauding Carmack to the skies if they'd seen only his gripes about the 360 CPU attempt to prove that he's totally irrelevant and afraid of learning about technology.
Slashdot Mirror
I bought something through Google Checkout from a vendor I've been buying from for years, never had any trouble with them.
Despite my clear indication of the "don't spam me" preference, I started getting regular, frequent, promotional mailings.
The "stop getting mail from this merchant" thing didn't work.
Google's support desk didn't respond to queries.
The merchant couldn't do anything about it, since they have no control; they can forward mail to Google for "our customers", but that's it.
Google's only "unsubscribe" option is "prevent any messages, whether they're order-related or not, sent by this merchant, from reaching me."
Pretty much never gonna use that again, believe me. They don't allow you to opt out of purely promotional bulk mailings without completely severing all contact. If you later use their system to buy from a merchant, then you are immediately back on ALL the promotional stuff for that merchant, because you were never actually removed from the list; they were just blocking mail to you from that merchant. You can't have a way to communicate, without being spammed.
Will they fix it? I don't know. After multiple spams and heroic efforts to get anyone in the checkout group to do anything, I did eventually stop receiving mail, but so far as I know, they have no plans to fix the underlying system.
I can beat that. The language Greet has the specification that an empty input file (or indeed, any other) is a program directing the language to print "Hello, world!"
In fact, K&R presents a complete Greet interpreter very early on.
Maybe they brought it back? It wasn't an option last year.
I used TaxAct last year. Haven't touched TurboTax in years --Intuit are fairly nasty and willful spammers, with a long history of abuses, spyware, and other charming traits. TaxCut was okay, but they ditched the Mac, so I had to go with something else anyway, and H&R Block is not one of my favorite companies; I'm sure they get taxes okay, but they don't understand computers or web pages very well.
Have you done anything on the gamecube? So far as I can tell, the Wii's got about a 50% overclock and some extra memory, but is otherwise very similar to the same hardware.
I am not sure what it has for rendering; obviously, comparing GC to PS2 games, it had SOME kind of rendering features.
Because the PS3 does HDCP on DVI, too, so it won't display to a non-HDCP monitor that way either. (Or through a non-HDCP console switch, etcetera; you get the idea.)
I was at GameStop today putting down my $5's to get Burning Crusade and Wario Ware tomorrow.
I was there about an hour before they opened. There were two guys standing outside. I came back. Turns out that they get a line, 4-5 people, EVERY DAY. Waiting for Wiis. (The sign saying they have PS3s has been on the door for at least a week.) They get about two shipments a week, which sell out instantly.
So, that particular store, 8-10 a week. That's not all that many, but everyone else has the same thing.
NPD's numbers include estimations of the non-participants, and are generally believed to do a pretty good job.
No, OS X is still running on Mach. FreeBSD userland, lots of NetBSD and FreeBSD kernel code ON TOP OF MACH... (BTW, that is the "4.4" code base in many cases)... But still Mach under the hood.
You can easily verify this by writing pretty much any code at all on OS X, and noticing the use of mach ports.
Counterexamples.
I can think of many things that would tend to cause both crime and income inequality. I can also think of things that would cause only one, or the other. I am not sure how we'd isolate these or determine what the relationship is.
Making a DRM format that only ever impedes illigitimate use, but always allows legitimate use, is omniscience-complete.
It's been shown long since. The flexibility and smoothness of control are unequaled, and now the question is just how well developers will use it.
The Wii control scheme is not just a gimmick; if it were, there wouldn't still be new players trying one and then going out and waiting in line in the cold in the hopes of getting one.
I hoped you were, I just figured I'd clarify it on the off chance that there are readers here to whom the humor was too subtle. :)
Just to be picky: Only 7. One SPE is disabled to improve yield, one is permanently reserved for Sony's hypervisor.
I posted it because I have come closer to peeing myself laughing reading the "rebuttals" to Carmack's position than I ever expected to do before I turned 70.
I figured that Slashdot users would get a kick out of reading something that reminds us of just far we've come. I mean, compared to that thread, jokes about Natalie Portman and Hot Grits are practically computer science!
I am well aware of the software cache, and auto-SIMDization. I was involved in getting the tutorials on those topics prepped last fall, and I've done a bunch of other writing on this. I am a big fan of Cell, and I spend more time than is probably healthy immersed in reading or writing about it.
The software cache imposes a fair number of cycles of latency per access even when the datum in question is in the cache; it's even slower when the datum isn't in the cache. Is it useable? Certainly. However, it's going to give you a serious performance hit, especially when used heavily. You can't just use it and get full performance from the SPE without worrying about local store; you have to use it sparingly only for access to large chunks of data, while keeping the bulk of the data you're working on in local store all the time. It does not solve the problem; it mitigates it.
The auto-SIMDization stuff does not make scalar code efficient. What that does is, in some cases, automatically convert scalar operations on arrays into vector operations on the same arrays. It doesn't solve the more general problem of operations that aren't being performed on whole arrays; those stay slow. what's impressive is that they handle the alignment problems involved in vectorizing, e.g., a[i] = b[i + 1] * c[i + 3];, not that they have magically cured the problem.
So we're back to where we started. The cell development support and compiler can give you comparative ease of use, but you lose a lot of the performance potential of the processor. All those theoretical numbers you see are based on the assumption that you are doing 90% of your calculations with no latency; not waiting for DMA, not accessing a cache, and so on.
So, really, you do have to do a lot of extra work to get the theoretical performance, or even very close to it. The software cache and other techniques mitigate this, so you can get enough performance from the SPEs to benefit from them somewhat without having to do anything exceptionally elaborate, but they don't give you the theoretical performance. If you want that performance, you have to do a lot of fiddly little management of, for instance, the tiny local store available on the SPEs. If you want to have that handled automatically, you take a very noticeable performance hit.
If you don't predict a branch, the SPE grinds to a halt for some ludicrous number of cycles while it fetches new instructions. The SPE has a huge decode buffer, and you need to warn it well in advance of where new instructions will be coming from if it's going to decode them in time. I don't know why you're saying they ren't pipelined, either; they are.
r y/pa-cellspu/
See also:
http://www-128.ibm.com/developerworks/power/libra
Er, it is a hurdle.
That it may be a wonderful opportunity, if you can overcome it, doesn't change the fact that the cost of developing a game for PS3 will be higher than the cost of developing a similar game on the 360. It may look a lot better, but so what? You have to sell enough copies to cover your costs.
So, it sounds to me like you haven't DONE any Cell development.
There's a huge difference between Cell and "PPC with vectors". It's called local store. Each SPE has 256KB of local storage. You have to have your code in there, and then stream data through. That means you have to do a fair amount of setup and partitioning specifically around that 256KB limit, which wouldn't apply on a multi-core PPC. That's a real issue, and you can't just paper it over for real projects.
And yes, in theory, the tools should be able to hide some of that from you. That's why Carmack's comments about the tools are so damning. If there has ever been an architecture which desperately needs polished and mature tools, this is it.
Also, I don't know where you get the idea that SPEs can do scalar code. They are 100% vector-only. The closest they can get is to emulate scalar code by ignoring the rest of a vector while manipulating only its first slot. That can be done, but it leaves you with a very slow processor spending a lot of its time masking things out and merging vectors together. (or, if you just omit those slots, and use only one slot out of each potential vector, your data takes much more space; 4x as much for 32-bit objects, 16x as much for bytes.)
Thanks! But what's it DO?
For those of us who haven't eaten alphabits in a few years, what's a CRM, and why do we care?
I don't think you quite follow the essence of the complaint.
With the absolute best tools conceivable, even with tools that we don't even have the technology to build, Cell will still be harder to develop for than a more conventional processor.
Yes, it's more powerful; probably a LOT more powerful. It's still mork work to get anything done.
Your claim tht it will be "easier" as it allows "better division of code and work" is just plain nonsense. Any division of code and work I can do on a multi-core system, I can do on a single-core system, too. That division is already available to me. The extra work Cell imposes is that I have to divide it asymmetrically; I can't just partition the task in whatever chunks the task makes sense in, I have to partition a lot of it in terms of the very specific requirements of the SPEs.
That work won't go away, even with perfect tools. It's harder, and it will always be harder.
I think it's probably worth it for supercomputing. I'm less sure that it's worth it for consoles, because game development costs are a plague upon the industry, and making them worse won't help.
Will it get easier than it is now? Yes, but the underlying fact that it is "harder to program and takes a little more time" won't. What might change is that, right now, it takes a lot more time; that might be plausibly reduced. But, in the end, making Cell just as easy as a multicore SMP system is in the same bin as lossless compression that is guaranteed to compress ALL possible inputs.
The trend towards and away from specialized processors comes and goes.
I think Carmack's view of the PS3 is a lot more realistic than yours. He's talking from the perspective of someone who has to ship a product or his friends don't eat. You're talking about what would be nice if programmer time were free.
FWIW, I have a PS3, which I am using to do Cell development. It really is very impressive... And it also really is a lot more work than a more traditional multicore system. The decision to specialize an extra time here reflects Sony's PS2 design (crappy CPU with two very impressive and non-interchangeable vector processors to make up for it), and I think it also reflects Sony's arrogance; they simply assume that, of course, people will be willing to spend twice as long developing software on their system to get a noticeable but not earth-shattering improvement in performance.
http://www.ps3forums.com/showthread.php?t=52467
This thread has been one of the funniest things I've ever seen. All the PS3 fanboys are bashing Carmack for his comments about Cell, despite the fact that it's quite clear none of them program at all, let alone program on asymmetric CPUs.
Hilarity ensues as people who would have been lauding Carmack to the skies if they'd seen only his gripes about the 360 CPU attempt to prove that he's totally irrelevant and afraid of learning about technology.