Perhaps "almost certain not to purchase it" was too strong a choice of words.
Still, the fact remains that most people only read most books once, while they listen to music many times. As I see it, there are three possibilities here. You check out a book/download a song from the library/Napster and...
1) you love it--it changes your life. You want to compensate the author/musician; you want to have the best quality copy of it around to cherish forever. Then you buy the book/CD, in either case.
2) you don't like it so much. You don't buy it, but then you wouldn't have wanted to buy it anyways; thus the library/Napster has done you a great service, by allowing you to avoid a sale you wouldn't have been happy with.
3) you like it quite a bit, but it's not life-changing. With respect to the book...well, you wouldn't have felt unhappy or ripped-off if you'd bought it, but since you've already read it and wouldn't again even if you had bought it, no sense in buying it now. With respect to the song, on the other hand, liking it quite a bit is more than enough for you to want to listen to it again and again. And as long as you're going to want to keep listening to it, it's very likely enough for you to want to hear it in the quality it was originally meant to be heard in. Assuming you have a decent stereo, it will sound much better on CD than on MP3, and you know it. Thus you're pretty likely to go buy it.
Since the majority of check-outs/downloads fall into category 3, Napster has the effect of being better for CD sales than libraries are for book sales. Or maybe it's, libraries are good for book sales by making young people who don't have the money to buy their own books into life-long readers, and then they buy lots of books later. But Napster has this effect as well as a much more direct positive effect on album sales.
Thus I'm almost positive that any study would find that Napster users buy more music than they will if Napster is shut down, while library-goers buy fewer books than they would if all the libraries were suddenly shut down.
You make some good points, but I still think they are mostly subsumed under the idea that what one "does" with a book is different from what one "does" with a song. Put it this way--the RIAA *wants* you to listen to a song once, because that will make you more likely to buy it. That's why they pay big bucks to get their songs on the radio, MTV, etc. A book publisher doesn't want you to read a book once for free--once you do that, the chance that you'll want to buy the book is almost nil.
Thus, while the "copyright" vs. "usageright" debate is relevant legally, it's not relevant functionally--it's not relevant to the function that libraries/Napster provides to the public. That function is the same--they provide a way to "use" copyrighted content in the way you would if you bought it...except with a slightly degraded look-and-feel experience, without the benefit of knowing you compensated the artist (or probably didn't, in the case of a CD), and arguably with a greater chance that the particular content you're looking for won't be currently available.
Basically, the objections you note aren't "functional" objections in the way I meant to use the term. (Perhaps a better term would be "utilitarian"--Napster and the library perform the same utility with respect to the way their various media are typically used.) When you say "functional", you mean the underlying functions which are actually making the whole thing possible; when I say "function" I mean the function to the user. In any case, this is made up for by the fact that while there is only one Napster, there are thousands of public libraries. (The number of people using Napster (20 million) may or may not be higher than the number of people using libraries; but the government spends money to try to get more people to use libraries, for chrissakes--it's viewed as a social positive, not a negative.) Thus, while you and I can't read the same copy of the same book, the fact remains that if we both wanted to check it out of our respective libraries at the same time, we wouldn't interfere with each other (because we'd use different libraries). It's a difference in the way the system works, but not in the function it provides to the user.
For example, the fact that you can listen to a particular MP3 at the same time as I can doesn't really matter to me, the user--what matters is, when I log on to Napster looking for a particular song, what's the chance it's going to be there? About the same chance as the chance a particular book is available at the library. There's a "functional" distinction to the system, but not to the user.
If anything, the copy of a book you check out of the library is more perfect than the "perfect" copy off Napster, because with Napster you're making a perfect copy of a copy that was degraded to begin with.
Eh, this response was sort of babbling and unfocused, but I hope you catch my drift. The differences between the way books and music are used makes matches up almost exactly to the differences between the way libraries and Napster work. Thus while the actual processes they go through are indeed different--and maybe different enough to make Napster run afoul of current law while libraries do not--they serve the same function to society, which is the important thing. Copyright protections were made to serve society, not to serve corporations which happen to have traditionally made money a certain way. If the function of a library is beneficial to society (I doubt many people would argue with this) than so is Napster. As such, it should be made legal (if it isn't already), not the other way around.
This would be a valid comparison if:
1) You actually had to drive or walk to a building somewhere to "check out" a song
So a library is wonderful, but a library that delivers would be immoral, illegal, and a threat to all we hold dear in society? What's your opinion of the Bookmobile???
and while it was checked out nobody else in the area could "check out" the same song (or only a limited number of people anyhoo)
Napster's "collection" is only as large as the number of people who happen to be connected at that particular time. The chance of finding the song you're looking for on Napster is about equal to the chance of finding the book you're looking for at the library. In either case, if it's not there the first time you check you can always go back later and try to get it again.
The difference is, with a library, you can be certain that eventually you will get to read--and thus not have to purchase--any book you want. Even if they don't have it in their collection, they will get it for you on inter-library loan. Put it another way--would you think Napster any more "ok" if, when the song you wanted wasn't available, you could put in a request and be guaranteed that the system would email you the MP3 within a couple weeks??
The library let you check out as many of their several million publications as you wanted at one time
First, I have never ever heard of a library which limits the number of titles you can check out at one time. People routinely come out of a library with as many as a dozen books in hand--equivalent to hundreds of hours of content. MP3's which provided the same amount of unique content (in terms of length of time) would fill an average hard drive.
Second, there are almost certainly more unique titles at a decent library than there are unique songs available on Napster. In any case, I'm sure you wouldn't think a public library was somehow a scourge on society because it happened to have an incredibly wide selection--you'd think it was a really good library.
and let you keep the publications.
See my original post for why the fact that you don't get to keep your library book as long as you want is irrelevant to the analogy. Basically, it's because what one typically does with a book one purchases--i.e. read it once--is different from what one does with music one purchases--i.e. listen to it many times. The restrictions a library book puts on your enjoyment of it are look-and-feel issues, not functional ones--just like the restrictions MP3 puts on your enjoyment of music.
Heh.. I could go on and on listing reasons why this is a terrible comparison, but I won't... in a hurry - no time to type 'em up:P...
The difference can be summed up quite simply: Napster makes copies. Libraries don't. And that's really all this trouble comes from.
This is the legal difference. As I stated at the beginning, I'm aware of why Napster more easily falls prey to the accusation of copyright infringement.
This is not, however, a functional difference. Yes, when you go to the library the book you are looking for may be checked out. On the other hand, finding a particular song on Napster is a hit-and-miss affair as well. As a rough estimate, I'd say that the chance a particular song you're looking for is available on Napster when you happen to log in is, well, about as good as the chance the book you're looking for is available at the library when you happen to show up.
The function Napster fulfills in society is still identical to that of a public library, and its moral standing ought to be the same as well.
No, not legally--I understand why copyright law is usually read such that Napster users might be infringing but library card holders are not. (On the other hand I'm pretty sure I remember hearing that the book publishers tried long and hard to sue public libraries out of existence when they first appeared.) But in terms of its effect on the marketplace for music, its moral ramifications, and its societal implications, I challenge anyone to show me a relevant difference between Napster (in its current form) and your local public library.
Both are places where you can obtain a copy of a copyrighted work, and use and enjoy it in its intended manner, for free. In both, the original copy of a work is donated out of the generosity of their own heart by someone who has (presumably) legally bought and paid for the original copyrighted work. (Of course, in the case of a public library, such a person has done a "good deed", while with Napster they have engaged in "rampant piracy" or some such thing.) Sure, a library book doesn't have the same look-and-feel as one you'd buy yourself--yellowed pages, that krinkly plastic book jacket--but MP3's are even worse: no physical CD, no liner notes, no cover art; the risk of getting a bad recording, a recording that chirps or hiccups or cuts off just before the end of the song; and the certainty that no matter what you get it won't play on your stereo, and if it could it would sound like crap compared to the original CD.
Yes, you have to return or renew library books after two weeks, but the point is that's good enough for how most people enjoy most books--they read them once and never look at them again. Similarly, Napster allows you an experience that is "good enough for how most people enjoy most songs"--that is, if you've got some tune stuck in your head, or just want some background music while you surf the web, you fire up Napster and get it. No, a public library isn't good enough to replace ownership in the case of those really important books that really impact you and you just want to have around...but neither is Napster. For a truly moving musical experience, you need a real CD (or good vinyl) on a real stereo, not some 128 kpbs muddle, decrypted in an electrically noisy environment, coming out your cheap underpowered magnetically-shielded plastic speakers. That is, the fact that you don't get to keep library books is a look-and-feel issue, not a utility issue--and the public library is still ahead of MP3 in terms of look-and-feel.
If anything, libraries pose a much greater danger to the publishing industry than Napster does to the RIAA, because once you have checked a book out of the library and read it, you are almost certain never to purchase it. With Napster, on the other hand, downloading an MP3 arguably makes you more likely to purchase the CD than before; certainly there is conclusive evidence that Napster increases CD purchases overall.
And yet, public libraries are held up as the paragon of the public good, the ideal of a fostered community, the sort of thing politicians throw into speeches to demonstrate what's right about America (or, more likely, what used to be right about America but no longer exists). Meanwhile, Napster--which, if anything, encourages more community (libraries, after all, are known for explicitly discouraging chatting), illustrates the possibility for knowledge shared throughout humanity which is inherent in the Internet, leads to more legal music purchasing, and facilitates an alternative to an industry which affords the artists much fewer rights and a much lower share of the monetary fruits of their labor than does the publishing industry--is sued, demonized, held up as an example of everything that's wrong and immoral about today's culture.
Huh? What gives?? Before the entertainment industry bought new copyright laws in 1997 and 1998, there was no legal concept of copyright infringement without corresponding non-commercial gains. And yet suddenly everyone believes that sharing music with others is not only illegal (it's still arguable whether that's true) but somehow immoral as well?? Somehow everyone has this ridiculous idea that copyright entitles a copyright holder to oversee every use his/her content is put to, fair use be damned?? (For those who don't understand why this is so absurd: copyright is automatically extended to every single piece of content ever created, no matter by whom or for what purpose. The above idea would mean you would need to get the permission of a gas station before you could submit the receipt they gave you as part of an expense account.)
Napster should be held up as an example of what's right with the world, of a way the promise of technology is enabling people to share the art they love, to expand their musical horizons, or just to get a copy of the new NSync song to play as a joke. It's an example of how the Internet will revolutionize an industry by opening up alternatives to a greedy oligopoly which stifles artists' rights to their own creations.
And yet even on/. we see people dismissing Napster as nothing but a bunch of immoral law-breaking pirating hooligans. Guess what, people: you've been trolled.
Well I knew it was a mistake to break my rule about the futility of political discussions on/. (well, anything more political than RDRAM vs. DDR), but I'll bite. Yes, Krugman is a "liberal", if by that you mean someone to the left of you and the GOP party line. As far as economists and Americans go, he's probably just a tad left of center; as far as academics go, he's solidly conservative. Yes, Krugman probably just uses his New York Times column to publicly bash his conservative-but-also-well-respected colleague down Mass. Av., Harvard economist and G.W. Bush advisor Martin Feldstein. Yes, I may just subconsciously enjoy Krugman's column because I think Marty Feldstein is an asshole.
Nonetheless, the fact remains that here is one of the most respected economists in the world saying quite pointedly that the economic policy Bush is promising would have killed the economic boom were he already president, and will probably kill it if he is elected president. It may not be positive credit given to Clinton for creating the new economy, but I think if you listen carefully to all the Democrats' speeches, most of them aren't claiming positive credit anyways. (If they are, well, of course they're wrong; on the other hand, it's a political convention for crying out loud, of course they're going to exaggerate.)
You may argue that this is only because we had a Republican Congress forcing Clinton into fiscal discipline. Ok, fine. Disregarding the fact that the Republican Congress was the one so sure that Clinton's budget would send the country straight to hell in a handbasket that they shut down the government for a month before giving up and signing it, this is a reasonable argument. I'm all for divided government too.
The problem here is that the Congress will definitely be Republican for the next 2 and almost certainly 4 years. That means that if Gore is elected, we'll get a sensible compromise budget which will probably be what's needed to continue our current prosperity, and that if Bush is elected he'll be free of any meaningful checks-and-balances to push through whatever old economic plan he sees fit. Just to refresh your memory, he is currently promising to push through a plan which some very well respected economists (Krugman) think will derail the economy.
Ever wonder why Women's studies majors are liberals? Not because they know what they're talking about!...You do know that virtually the entire academic establishment is liberal, right?
Women's Studies majors tend to be liberal because it is generally only liberal-minded people who believe women's studies is a field worthy of their time and study. Economics majors tend to be conservative partially because conservative-minded people often believe economics is most worthy of their time and study, but more often because it's a decent way to get into Business School. I'm not sure what you're point is here.
You do know that virtually the entire academic establishment is liberal, right?
I would wager that I know a good deal more about the academic establishment than you. (Note email address.) While parts of it are indeed prone to being absurdly liberal (e.g. your aforementioned Women's Studies), Economics is not one of those parts. Despite the popular notion that all of academia is overrun by Marxists and Feminists, it turns out that most fields and departments are remarkably well insulated from each other. While there are plenty of wacko Marxist and Feminist professors around on leading university campuses, I assure you none of them are in the Economics department, and that, besides, they almost all know quite a lot about what they're talking about.
You bring up the fact that successful business owners tend to be more conservative than respected economists. This, of course, is exactly the point: a "liberal" philosophy turns out to be quite well-suited for an economist, whose job is to ensure the fiscal well being of an entire society. Meanwhile, a conservative philosophy is quite appropriate for a business-owner, whose your job is to ensure the continued fiscal well-being of himself.
Guess which philosophy is better suited for the government?
Sure, the economy is doing well. However, that has between little and nothing to do with Clinton. The president has little control over the economy, beyond his control over taxes, going to war, and a few other significant acts, none of which Clinton has really executed. You'll be hard pressed to find any respected economist, even though they're mostly liberals, that will back Clinton's assertions. In all reality, the state of the economy has more to do with the Greenspan, technology, and arguably Reagan's tough stance against taxes and union abuse.
How about Paul Krugman, Nobel-prize winning economist at MIT? Would you consider him "respected", or is that know-nothing idiot too much of a liberal? (Side note: ever wonder why most respected economists are liberal?? Not because they know what they're talking about! Obviously not that!!)
According to Krugman, while Clinton isn't wholly responible for the economic boom, or anywhere near it, he *is* largely responsible for balancing the budget, which in turn *is* largely responsible for keeping interest rates low and perpetuating our roaring economy. Conversely, Krugman argues, if Dole had been elected in 1996, and had enacted his promised tax cut, the boom would almost certainly have been shorter lived. Amazingly enough, Bush is proposing a tax cut and which looks remarkably like Dole's, and some pretty impressive spending increases on top of that.
I think I'll let the Nobel-prize winner take it from here: "Not long ago America faced a choice between sober, sensible fiscal discipline and huge, irresponsible tax cuts. We chose discipline, and were rewarded with growth beyond our wildest dreams. So why would anyone today propose exactly the kind of irresponsibility we were lucky to avoid four years ago?"
Thank you for a very interesting and informative post!
Thanks for actually reading the whole damn thing!
I don't think traditional expandable RAM has to go away completely, though. I think the solution would be further extending the NUMA (Non-Uniform Memory Access) concept of cache memory. We've already got very-high-speed L1 and L2 cache. Say this CPU+high-speed-memory card you propose has N ultra-high-speed on-die L1 cache, N*16 super-high-speed off-die L2 cache, and N*(2^10) of very-high-speed, CPU-local RAM. Then have an expandable main memory system of merely high-speed RAM, slower, but expandable and much larger, say, N*(2^12). To fill in some example numbers:
128 KB L1 cache
2 MB L2 cache
128 MB local RAM
512 MB main RAM
That way, you get the best of both worlds.
Interesting. I'd first point out that, to me at least, what you're proposing sounds a bit more like a gigantic (128 MB) L3 DRAM-cache than traditional NUMA. Of course, I don't know too much about NUMA, except that it's supposed to have a way to actually manage which data goes in which memory efficiently--which would be a very difficult problem in such a system.
For one thing, it's worth noting that under almost any concievable implementation, all 128 MB of data in the local DRAM/L3 cache would have to be mirrored in the 512 MB main DRAM--thus essentially "wasting" 1/4 of your main RAM capacity. There are ways around this (e.g. Thunderbird/Duron with their "exclusive" cache hierarchies) but from what I understand they would introduce tremendous latencies into such a system.
And indeed, that would be the biggest problem with this scheme--the latencies. If a program was looking for a piece of data, it would have to first check the L1 cache; then (if it didn't find it there) the L2 cache; then (if it didn't find it there) the very large local DRAM/L3 cache; and only then would it look for it in main memory (and god forbid not find it there either and have to pull it out of virtual memory!).
The upshot of this is that you'd get a pretty large miss-penalty every time you had to search all the way down to your main DRAM to find some data. On the other hand, it wouldn't be as large as the penalty currently associated with virtual memory, and we use that all the time. But still, I think you'd find on such a system that upgrading the main DRAM--like enlarging your virtual memory swap file--wouldn't have the same effect on system performance as upgrading main memory does today.
Could be wrong, though. Certainly an interesting idea.
Just to nitpick, the Pentium 4 bus is not "double wide double data rate". It is 128 bits wide, and quad-pumped. It does transmit data at 400 MHz. When Intel claims it is a 400 MHz bus, they're just as correct as claiming that AMD claiming a 200 MHz bus, and Rambus claiming an 800 MHz bus.
I'm pretty sure I'm right here. For one thing, the maximum bandwidth of the P4 FSB is 3.2 GB/s, which is 2 "pumps" x 100 MHz x 128-bits. For independent proof of this, note that Intel's top-of-the-line P4 chipset, Tehama, uses dual PC800 RDRAM channels, yielding...3.2 GB/s. If it were quad-pumped, 100 MHz and 128 bits wide as you claim, the FSB bandwidth would be 6.4 GB/s.
For another, there's no way I've ever heard of to actually "quad pump" a clock signal. "Double pumping" works because a clock signal is actually made up of two signals--the so-called "rising edge" when the signal turns on, and the so-called "falling edge" when the signal turns off. In contrast, there's just no natural way to divide a signal into four without using a PLL and a seperate clock generator. How do we know Intel isn't doing that? Well...the question becomes: "seperate" from what? The FSB clock *is* the only clock in a chipset; if they wanted to make it go twice as fast, they would just clock it at 200 MHz.
And no, Kingston's "quad-pumped" SDRAM isn't really quad-pumped either; it's just DDR which is cleverly interleaved to essentially make it twice as wide.
Apologies for the uber-post, but man this discussion needed an injection of information.
Myth #1: It's Rambus vs. DDR vs. MRAM. It's been mentioned before, but bears repeating: MRAM will not be the next generation memory technology. It will at best be the next-next-next generation memory technology, as it's at least 5 years from commercial viability. However, I'd guess that even in MRAM's wildest dreams it will take longer than that before it ever makes it to PC main memory; first, it will be used as a replacement for what it is actually most like--not DRAM, but flash memory. While it has the potential to maybe one day be faster, smaller, and cheaper than DRAM, until then it will only be used in those places where its most important attribute--nonvolatility--is actually necessary.
Furthermore, there are any number of exotic competing technologies which are a) going to make it to market first and b) actually aimed at the PC main memory market. These include:
VC SDRAM: like SDRAM with a small SRAM cache--already available, but with disappointing performance, due to a bad implementation of a good idea; don't count it out in a future incarnation
FCSDRAM: which allows a more efficient ordering of access requests to cut down latency
DDR-II: the packet-based successor to DDR SDRAM, and the probable next standard
DDR-IIe: DDR-II with caching technology similar but superior to VC SDRAM's
and eDRAM: an exotic technique for putting DRAM directly on a microprocessor, which allows for extraordinary bandwidth and tiny latencies but requires an entirely new manufacturing process.
In any case, the above are not mutually exclusive (indeed, RDRAM is a DDR type of SDRAM), and I wouldn't be at all surprised to see some VC/e FCDDR-II be the PC main memory of choice in a couple years. (It'll have a better name, though:)
Myth #2: DRAM bandwidth is holding back the performance of today's PC's. Actually, the problem is not in the DRAM chips but rather in the bus that connects them to the CPU--that is, the Front Side Bus (FSB). The FSB on all current Intel chips is only 64-bits wide, single pumped. That means you only have 1.1 GB/s of bandwidth to the CPU with a new 133 MHz FSB P3, 800 MB/s with a 100 MHz FSB P3 or P2, and a measely 533 MB/s with a lowly Celeron. Not so coincidentally, the maximum bandwidth of the various standard types of SDRAM, PC133, PC100 and PC66 are...1.1 GB/s, 800 MB/s, and 533 MB/s respectively.
Ever wonder why 1.6 GB/s RDRAM wasn't any faster than 1.1 GB/s PC133 on all those P3 benchmarks earlier this year? At the time you probably either heard from someone else (or decided yourself) that it was just because "Rambus sucks," which, while true, isn't the whole story. Instead, the reason that the faster RDRAM didn't perform any faster is because its extra 533 MB/s of bandwidth is all dressed up with no place to go--it certainly can't go to the CPU, because the FSB is in the way, and it only lets through 1.1 GB/s. Now, there are couple edge conditions where that extra bandwidth can be utilized by sending some over the AGP bus and keeping some in buffers on the chipset to send later, but by and large the P3 is completely saturated by plain old PC133. This is the same reason why, when DDR chipsets finally come out for the P3 in a couple months, their performance is going to be a mite disappointing--all this extra bandwidth, no place for it to go. As for why the RDRAM system is actually slower most of the time...well, that's because Rambus sucks. (RDRAM has higher latencies than SDRAM, plus Intel's i820 RDRAM chipset is nowhere near as good as its BX or i815 SDRAM chipsets.)
Luckily, this is a bottleneck that is finally getting removed. AMD's Athlon and Duron CPU's both have double-pumped FSB's, meaning they'll be quite happy slurping up the extra bandwidth they get from their DDR chipsets, due out hopefully by October. Their FSB's can currently be set at either 2x100 MHz (1.6 GB/s) or 2x133 MHz (2.1 GB/s). And Intel's upcoming P4 goes a step further--it has a double-wide double-pumped FSB, allowing 3.2 GB/s @ 100 MHz core clock, and 4.3 GB/s @ 133 MHz.
These steps are, to put it mildly, vastly overdue, as the ratio of CPU-clock to FSB-clock has gone from 1:1 in the pre-486 days, to 2:1 with the 486DX2, to, for example, 3.5:1 on the two year-old P2-350 I'm typing on now, to a ridiculous 8.5:1 on the latest greatest (nonexistant) P3-1133 to a miraculously exorbitant 10.5:1 on a Celeron-700. What this means is that that CPU is spending a whole lot more of its time waiting every time it needs to access memory--10.5 clock cycles for every 1 cycle of memory access, to be exact. While the impact of this can and has been minimized through all sorts of tricks like bigger caches, out-of-order execution, and prefetching compilers, the overall performance impact is "damn."
So thankfully these ridiculous ratios will finally be brought down as the next generation of CPU's with decent FSB's ships.
Having read this, you're probably now lulled into believing our third myth. Unfortunately, you're wrong.
Myth #3: DRAM performance will hold back the performance of tomorrow's PC's. As it turns out, that's not true either. For proof, just take a look at the latest generation of PC graphics cards. The latest and greatest offerings from ATi and nvidia both include 64 MB of double-wide DDR SDRAM at speeds up to 2x183=366 MHz. That's 5.9 GB/s of bandwidth, way more than enough to saturate the FSB of top-of-the-line CPU's for at least the next 18 months. All this is available, plus a very complicated GPU, fast RAMDAC, and some other components, on a card selling for about $400--thus we can guess that that 64 MB of 5.9 GB/s RAM costs around $250--or, humorously enough, about the cost of 64 MB of 1.6 GB/s PC800 RDRAM! Furthermore, nvidia just announced the GeForce2 Ultra, with 64 MB of 2x250=500 MHz DDR. That's 8 GB/s!! The cost? Another $100.
But all of this is disregarding that little something called supply-and-demand. There are several legitimate reasons why such high-speed DDR costs more to make than normal-speed DDR (which costs a negligable amount more than plain-old SDRAM), but the main reason for its (not even so) high price is its scarcity and the incredible demand for it by graphics card makers. On the other hand, the main reason RDRAM has come down in price so much (6 months ago it cost around 3 times as much) is because there is a glut of it on the market. Everyone in the industry (except Dell) has realized that the i820 chipset is a dud, a bomb, already shuffled off to obsolescence. RDRAM on the PC is a no-go, at least until the P4 comes out. Thus, excess RDRAM is being sold-off at fire-sale prices. Once the P4 is out in enough volume to actually impact prices (i.e. January or February if Intel is lucky), expect another surge in RDRAM prices. Back on the other hand, in a year or so that 8 GB/s (!) 500 MHz DDR SDRAM in the new GeForce2 Ultra will be pretty mainstream stuff, going for but a modest premium over even bottom-of-the-line SDR SDRAM (which will still be around for some time).
"So great!" you might say. "Let's make chipsets with 8 GB/s FSB's, and all our problems will be solved!" Well...there's the rub.
See, the point of this story is, the problem in getting a high-speed memory subsystem in your PC is not the DRAM--they can get that damn fast already. (8 Gb/s!! Ok I'll stop now.) The problem is the stuff in between: the motherboard and the chipset. That is, the bus.
It turns out that it's easy to get a super-high-speed bus onto a graphics card, but an electrical engineer's nightmare to get one on a PC motherboard. Let's count the reasons why:
1) The traces (wires) on a motherboard are a whole lot longer than on a graphics card. The higher the capacity of a trace, the higher quality (read: more expensive) it has to be. The longer it is, the higher quality it has to be to have the same capacity. Eventually, it's just beyond the capabilities of our current manufacturing to make traces that are long enough and high enough capacity to work with high-speed DRAM on a big motherboard.
2) There's lots of other components on a motherboard. This means more interference ("crosstalk"). This means--you guessed it--the traces need to be even higher quality.
3) A motherboard has to be designed to work with almost any amount of DRAM--one DIMM, two DIMM's, three DIMM's, of varying amounts, made by anyone from Micron to Uncle Noname. Graphics cards are fixed configurations which can be validated once and forgotten about.
4) The DRAM in a graphics card is soldered to the board. The DRAM in a motherboard has to be removable and communicate through a socket, which adds to the electrical engineering complexity.
Plus there's probably a couple more I can't think of at the moment. The point is, the weak link in the memory subsystem is not the DRAM. Today it's the chip's FSB, next year it will be the motherboard and the chipset, but it's not the DRAM.
However, there are ways the DRAM might be changed to get around this limitation. (Disclaimer: I don't know as much about this part of the equation as I do about the rest.) Apparently the packet-based protocol used in RDRAM is one way to do this--for some reason, communicating in packets minimizes the danger of data loss due to crosstalk. Probably for the same reason it works for networks, the Internet, etc.
Great! The problem is, RDRAM isn't designed to maximize bandwidth, but rather to maximize bandwidth/pin. While this is real neat for itty-bitty embedded devices where you need to keep pin count to a minimum, the problem is that each pin is connected to its own trace...and thus RDRAM ends up requiring the motherboard to carry much more bandwidth/trace than DDR SDRAM. See above (#1) for why this is a bad idea.
So, the packet-based, but-otherwise-more-or-less-normal-DDR DDR-II, due out in 1.5-2 years, looks like a good candidate to solve this problem, at least for the time being.
In my opinion, though, even that is only a temporary solution. I'd say eventually the industry is going to have to give up the idea of expandable RAM, and change the entire architecture of the motherboard so that the CPU and main memory are moved off it, onto a daughter card, like the graphics card is now. That would mean you would have to buy your CPU and your RAM together--no more adding more RAM as a quick performance booster, which would be a considerable loss. However, it seems as if it would get rid of the tremendous memory bandwidth problem PC's are facing today in one fell swoop. In comparison to the performance gains realized, it would be an easy tradeoff for the vast majority of consumers, who never upgrade their RAM anyways.
The other possible solution is similar-but-different: a switch to eDRAM, which I discussed lo these long paragraphs ago (up near the top). This, however, would require an even bigger infrastructure change, although the benefits might be even greater.
Just a clarification: when referring to RDRAM, RAMBUS decided that PC800 means 800MB/sec, not 800MHz, so it isn't really running that fast.
Just a clarification: you are completely wrong. The various types of RDRAM do in fact refer to their clock speed, not their bandwidth. PC800 does indeed refer to 800MHz; as RDRAM is 16-bits wide per channel, this means PC800 has a theoretical maximum bandwidth of 1.6 GB/s. By way of comparison, PC133 SDRAM is 64-bits wide and 133 MHz, and so it has a max bandwidth of 1.1 GB/s.
So, to reiterate, you're wrong. Now, however, it begins to get confusing. First off, PC800 RDRAM isn't really running at 800 MHz; it's running double data rate--transmitting twice per clock--at 400 MHz. As far as the PC industry goes, it's an acceptable fudge, and not nearly so bad as Intel saying the double-wide double data rate 100 MHz FSB on the P4 is "400 MHz".
Then it gets even more confusing. See, it turns out that PC 700 RDRAM actually runs at 2x356=712 MHz most of the time (good!) whereas PC 600 RDRAM actually runs at 2x266=533 MHz most of the time (bad!). This has to do with the vagaries of timing these cobbled together brands of RDRAM (only marketed because the yields on PC 800 were so awful) to run with 133 MHz FSB chipsets. If run on a 100 MHz FSB chipset--which they never are--they will run at their advertised 600 and 700 MHz rates.
So...in order to get rid of all this confusion but keep the handy-dandy "PC___" designation (and to one-up Rambus in the "my number's higher than yours" game), JEDEC has decided that from now on all its DRAM standards will be numbered based on their maximum bandwidth rather than their clock speed, actual or DDR or otherwise. Thus, the DDR we will see in DDR motherboards in a couple months will either be branded PC1600 (2 x 100 MHz x 64-bits) or PC2100 (2 x 133 MHz x 64-bits).
All done? Not hardly. It turns out that the first generation of PC2100 will have higher latency timings for the various stages of a random access than will PC1600, thus making it slower in certain situations while faster in others. Of course, within a couple months, lower latency PC2100 will be around, which may or may not be designated PC2100A. See how this all helps the customer and makes things easier???
Of course, the DDR for graphics cards is categorized neither by its maximum bandwidth nor its clock rate but rather by its clock period: i.e. 2x166 MHz DDR is called "6ns DDR" when its on a video card (because 1 second / 6 nanoseconds = 166 million); 2x183 is 5.5ns, and the new GeForce2 Ultra's are shipping with incredible 2x250 MHz 4ns DDR SDRAM.
And, of course, any and all of the above DRAM is overclockable to any speeds and latency timings you want; it's just only guaranteed to work at the marketed speed. Oh, and how fast any of this all is depends just as much on your chipset and, in the case of RDRAM, your power consumption settings. (Even if you're plugged into the wall, don't be too profligate with those power settings or the whole thing will overheat!)
And I forgot to mention VC SDRAM, which is available now, and FCSDRAM, eDRAM, DDR-II and DDR-IIe, any of which might/will make the jump to PC main memory in the coming years (at least before MRAM). Isn't it all so simple now?? Good.
I think you're underestimating the X-Box by quite a bit.
Actually, it won't be 10x more powerful than the PS2. More like twice as powerful.
It's less a matter of "the X-Box is n times as powerful" and much more a matter of the programming paradigm the consoles are best suited for. The PS2 is impressive in terms of pure FP thouroughput, memory bandwidth, etc. Where it suffers is in its lack of high-level programming tools and serious dearth of onboard RAM, especially video RAM. Specifically, the PS2 has 32 MB of main memory, but only 4 MB of video memory. The only good thing is that the two are connected with a high-bandwidth (3.2 GB/s) bus. This compares to the typical setup on a current high-end PC game: whole bunch of main RAM, 32 MB of video RAM, but a low speed (AGP is a bad joke) bus connecting the two. This means that a whole generation of programmers who learned to program 3D games according to the current PC model--that is, "just load all the data you need for a level into video RAM at the start, and work out of video RAM as much as possible"--have to try to figure out a completely different way of doing things. No matter how good they are, they'll never get around the fact that 4 MB just ain't enough to hold detailed textures, not to mention your z-buffer, framebuffer, etc. The obvious solution--find some way to store some of that stuff in the main memory and access it only when needed--ends up requiring a totally different approach to the rendering process. Happily enough, each developer needs to roll the solutions to these problems on their own, in a foreign assembly language, because high-level libraries for the PS2 are, at this point, almost nonexistant.
The result? Developers, especially all those PC developers looking to make the jump to the much higher volume world console gaming, are none too enthusiastic. Meanwhile, despite the very impressive potential of the PS2, the first generation of games is so badly programmed they barely look any different from games for the Dreamcast. In many cases, they look worse (after all, at least DC has 8 MB of video RAM).
Contrast the X-Box. It has a 64 MB unified memory architecture. Not so coincidentally, by the time it comes out, most decent PC 3D cards will have...64 MB of memory. (The fact that the X-Box's 64 MB will also have to hold the game code, etc. is not as large a problem as you think--indeed, most in-game code can fit into a CPU's cache.) The X-Box can access this RAM across a 6.4 MB/s bus--twice as good as the PS2, and better than any current PC card (except the new GeForce2 Ultra).
Best of all, the X-Box will work with both 3D gaming API's around for the PC: DirectX and OpenGL. While one might have some complaints about the peculiarites of these API's, they are many many many many times better than any API's available for consoles, much less the PS2. Plus, their use makes porting any PC game to the X-Box a snap.
Developers, by the way, are much more enthused about X-Box than PS2 these days...
In the same situation, the original Playstation whooped Nintendo's ass even though the N64 was more than 3X faster, and featured stuff like texture filtering and full screen anti-aliasing (which PSX doesn't support.) Of course, Nintendo actually knew the console industry, and knew how to deliver a simple, stable, easy to use product
I disagree. The N64 failed because it used cartridges instead of CD's. For one thing, this meant that its superior processing power was wasted on games with very low detail textures, and thus that its graphics looked no better than those on the "underpowered" PS. For another, it meant that Nintendo could continue to pocket a $15 licensing fee/media cost for each game sold, as opposed to about $3 for each PS game. Guess which console's games cost less? Guess which had more developer support?? Nintendo's error was in treating the market as if they still had a monopoly.
Microsoft is bringing too much PC garbage into the XBox to be able to do that. XBox will not be simple, stable, nor easy to use. It will require updates, and upgrades, and patches.
How do you know? There is simply no basis for this in fact. None. Zero.
Meanwhile, the PS2 will need a cable modem peripheral for Internet capability, fast becoming one of the most important aspects of the modern video-game experience. (Built into X-Box.) As history shows us, that is indeed a killer. How many console peripherals have been widely successful, in the history of console games?? None.
Now, the X-Box does have a hard drive, but it will not be end-user accessible. It is mainly for saving games and caching purposes. If used as MS says it will be used, it is only an asset.
And the X-Box uses a stripped-down version of the Win2k kernel. So? Has anyone shown W2k to be any less stable than, say, Linux running a GUI? Didn't think so. Is there any reason to think Embedded W2k won't be as stable as, say, Embedded Linux? No.
Nothing against MS, it's just that it doesn't understand the industry.
Precisely what was said about Sony before the PS. Sony made great strides to study the industry and not presume to attack it the same way it had in other industries, and from all appearances so has MS.
None of this takes into account the fact that Playstation 2 is coming out more than a year earlier. As history shows us, that's a killer. PSX whopped Nintendo largely due to the fact that N64 came out more than a year later.
Uh...the Sega Saturn came out before the PS. It failed miserably. Why?? Funny you should ask. Seems it was too difficult to program for...
Lastly, Sony is a lot bigger than Microsoft, and they have more developer support and consumer mindshare.
As a matter of interest, whats your take on Crusoe's VLIW instractions ? To what extent can the problems with VLIW be circumvented by running the compiler at run-time ?
My initial guess would be that you can do it to some extent, provided your compiler is sophisticated enough, and you're prepared to compile several versions of the same source for different input data.
My guess would be similar--that, by looking for dependencies at run-time instead of compile-time, Crusoe has a much better shot at generating fast code and keeping the CPU small, cool, and simple. After all, with their approach, they are successfully able to do what IA-64 can only promise: move all the complexities of instruction scheduling from hardware to software.
Or are they? Because Crusoe (the hardware) is a straight-up in-order VLIW chip, its runtime compiler is actually doing two things: recompiling compiled x86 (or whatever) instructions, and scheduling them. Most of the criticism levied at Crusoe's approach focuses on the first half of this equation, and proceeds along the lines that "JIT is a bad idea, because it's why Java is so slow." As it turns out, I couldn't disagree more. For one thing, much of the reason Java is slower than C/C++ is because it is safer and more OO--it runs its own garbage collector and forces everything to be an object, amongst other things. For another, it's not actually slower! The newest Java JIT's manage to generate faster code than static compilers in many cases--and well they should, because they know more about the machine they are compiling to and the most common critical paths through the software than a static compiler ever could. Indeed, HP is working on a runtime interpreter which will speed up almost any precompiled code.
The reason JIT's can work so well is because they only need to compile the code once, then sit back and profile it, recompiling only when necessary. In other words, they incur a lot of overhead at first, but pretty much stay out of the way afterwards unless they'll really help out.
Now on to the second half of Crusoe's compiler--the scheduler. As I mentioned before, this sounds like a good idea--taking some functionality off of hardware and moving it into software. But when you think about it, you realize there's no such thing as "taking functionality off of hardware and moving it into software"--after all, the "software" still needs to execute on the same hardware!
What you're actually doing, then, is moving a function from having dedicated on-chip hardware performing it to having to be run with normal general-purpose hardware. This still has the very real benefit of making the chip a lot simpler, but now you've added a scheduler that needs to take clock cycles from the code it's trying to schedule.
The big question, then, is how much can the scheduler be like the compiler--that is, just doing its work once and then only stepping in when necessary. If, by moving the scheduler from dedicated on-chip logic to software using general-purpose logic, you make it able to do that much better, then it may be a significant design win. If, however, the scheduler needs to do anywhere near as much work as it would have as dedicated on-chip hardware, you're going to end up losing speed.
Which of these is the case? I have no idea. Obviously, a lot of very smart people (Dave Ditzel, etc.) thought the former. On the other hand, Dave Ditzel is reportedly the one responsible for keeping Sun's chips in-order while the rest of the world moved to out-of-order; a quick comparison between an Alpha 21624 and an UltraSPARC-II (or even the upcoming UltraSPARC-III) shows you who was right on that one. (Hint: not Dave Ditzel.)
What we do know is that Crusoe is a lot slower than Transmeta originally thought a runtime interpreted VLIW processor would be. There have been strong reports that they originally envisioned their processors would be able to beat leading-edge x86 chips handily, and only scaled back to the low-power market once their original benchmarks came back disappointing. Even at the low end of the scale, they're attracting a lot of ridicule amongst chip designers for trying to "reinvent the benchmark" because their chips can't compete. I happen to believe that (work/time)/power is a useful benchmark for the mobile arena; still, there's no denying that Transmeta would rely on traditional benchmarks if they could. Furthermore, it looks as if several chips may end up being able to compete with Crusoe even on (work/time)/power--StrongARM's, the much-maligned Cyrix III, and various other low profile simple RISC chips coming out of the woodwork to compete for the "mobile embedded" market.
So, while I would very much like Transmeta to succeed, so far--just as with IA-64--there's little indication that it's more than a bunch of hype. Perhaps after a disappointing first iteration, VLIW will get its kinks worked out and become the standard general-purpose CPU design philosophy of the next couple decades, just as RISC has been for the last two. (And yes, modern x86 chips are designed according to the RISC philosophy, even though the x86 ISA is CISC.) However, I have to say I doubt it. Looking ahead, all the badassest designs of the future (MAJC, Power4, 21464, SledgeHammer) seem to be moving towards keeping the dynamically scheduling RISC architecture and adapting it for CMP--chip level multiprocessing.
The Alpha is more powerful than Pentium III, but not by as much as you'd might think; most of its advantage for supercomputing comes from its superior bus.
Actually, the main advantage of the Alpha comes from the fact that it is not held back by requiring compatability with the x86's god-awful stack-based floating point registers. That's why a GHz PIII can equal a 733 Alpha 21624 in SpecINT, but gets blown away on SpecFP by a factor of 2.5 or so. The superior chipsets of the high end RISC-based set help quite a bit too, of course, though that advantage is partially matched as far as SPEC goes by Intel's incredible (and non-functioning for most other code) compilers.
As for Sledgehammer and Willamette, they hope to narrow this gap by trying to replace the x87 FPU stack for most code with the double-percision capable SSE2, and by moving to wider buses with faster DRAM. On the other hand, the 21634 and Power4 look remarkably good, and ought to extend the high-end chips' lead for quite some time.
considering that the wholesale price of 1 GHz Athlon Thunderbirds was just dropped, and will probably drop again within a month or 2, it'll only be a few months before a 1GHz Athlon can be bought for about $500 or less.
Dunno if you heard, but the price of the 1 GHz TBird is going to drop to $539 on Monday. So rather than a few months until it's about $500, you only need to wait 4 days...
And one nitpick: while the chip we're talking about is supposed to be a redesign, it won't be much of one. Rumor has it the Samuel 2 will add an improved (i.e. fully clocked) FPU and 64 KB of L2 cache. We'll see. While both of these are very badly needed improvements, the fact is that the Samuel 2 will still be a very simple in-order chip trying to compete with the massively superscalar and agressively out-of-order designs of AMD and Intel. As such it just might end up being a great chip for cheap low-power devices, due to its small die size, but it has no chance of offering a viable (pun intended?) alternative for the desktop.
Jobs' presentation provided a Photoshop (TM) shootout between a dual-processor 500 MHz Power Mac G4 and a single processor 1 GHz Pentium. As expected, the PowerPC finished the test in about half the time it took the PC.
That's because the test was, as expected, rigged. That is, it only used a certain set of filters which happen to run faster on PPC than on x86. It would be quite easy to pick a different set of filters and "show" that the PIII is faster than the G4 clock-for-clock on Photoshop. (Not to mention the fact that Photoshop is perhaps the only mainstream program better optimized for the Mac than the PC.)
A fairer Photoshop benchmark (and using Photoshop as your sole benchmark is pretty shortsighted, to say the least) is PSBench, which runs not 3 specially selected filters like Steve did, but a full 21. The results? A 500 MHz G4 is a bit slower than an 800 MHz P3. A dual 500 MHz G4 is probably not much faster than a 1 GHz P3, and certainly no faster than a (cheaper) dual 800 MHz P3.
For a rather exhaustive look at G4 vs. x86 benchmarks, try here. The upshot? A G4 500 is maybe as fast in raw integer and FPU speed as...a PIII 400. That is to say, the G3 was about equal with the PII clock-for-clock; however, the Coppermine PIII's have since added some stuff which the G3/G4 can't match--namely, a much faster L2 cache and 133 MHz FSB.
Where the G4 really shines, of course, is in those programs which can take advantage of AltiVec--and indeed, those are about the only benchmarks you'll find on that page. (You won't, however, find any gaming benchmarks, because the Mac would of course be "unfairly" limited by its lack of good graphics cards.) In raw SIMD-plus-FPU, a 500 MHz G4 performs about as well as...well, it depends, but a fair guesstimate would be a PIII 750 or an Athlon 650. If you look at the page, you'll find that the Mac wins quite a few benchmarks, and that one or both of the x86 chips wins most of them, and that the margins of victory vary widely.
Suffice it to say, though, that even if you do run Photoshop all day, the performance of Apple's hardware is not a good reason to buy a Mac. With the exception of Seti@Home and RC5 (but not OGR!), there is a significantly cheaper PC which will run any program faster. This isn't to say there aren't other good reasons to buy Macs. But when one platform's top chips double in speed in a year, and the other's only go up by 50 MHz, you can bet that the first platform is going to be faster.
It's disappointing that the Tom's Hardware article doesn't contain an architectural block diagram of the CPU, or much information about how much gets done per clock.
Check out the review at Ace's. It doesn't quite contain a full block diagram, but does a much better job than Tom's at discussing the architecture of the chip.
The summary: whether to try to keep die size/power consumption low or because they didn't have the expertise, Centaur (later bought by Cyrix later bought by VIA, the ones who actually designed this chip) decided to keep it very simple. Thus, the chip is in-order, with a relatively deep pipeline (11 stages), relatively large 128 KB L1 cache (it needs it to try to make up for the fact that as an in-order chip it needs to sit and idle while waiting for any memory accesses), and just 4 execution units--2 SIMD, 1 ALU and 1 FPU.
The good news: it's just 76 mm^2 (on a not-very-good ".18 micron" process), consumes very little power, and runs cool enough to forego a fan. The bad news: no L2 and a half-clocked FPU mean laughable performance as a desktop or even a laptop chip. It might do ok compiling kernels and web browsing, but anything requiring a decent cache or any FPU at all (i.e. playing games, encoding MP3s, anything involving 3D, and even plain old office apps) and you're better off with last year's Celeron or K6-2.
The US government maintains export controls on any processor with a performance of greater than 2 gigaflops, making it slightly difficult for some high tech companies and government agencies in India, China, and Russia to purchase high end Intel chips. By being a Taiwanese company, Via can potentially grab a huge, rapidly growing market from Intel and AMD, which may have legal difficulties selling chips from even their non-US chip fabs to these countries.
Incorrect, and absolutely irrelevent anyways. First off, those export restrictions were lifted a few months ago. And second, current Cyrix III's have their FPU's clocked at only half the chip speed, making the FPU performance of a CIII 550 roughly equivalent to that of a 6-year old Pentium 200, or of a theoretical Athlon 90 or so. Rumor has it the FPU will be running at full clock speed by the time they hit 1000 MHz sometime early next year, but even then you're talking maybe "Athlon 400" performance, possibly worse. And even then, it appears it will only be any good at single-percision FP, not the double-percision which the export controls are concerned with.
In other words, nowhere near worth an export control. And nowhere near worth sticking in anything this side of a web pad, either. Frankly, this chip is just not very good.
even if they manage to release an 1 GHz chip, it's probably gonna be PR-1000 aka "equivalent to a 1 Ghz Pentium III"
First off, the PR ratings were based on the integer speeds of the original Pentiums (P5), not P6 chips.
And second, actually no; Via specifically changed their Cyrix III over from the Joshua core they had developed in-house over to the current "Samuel" core purchased from Centaur, not because the Samuel core had better performance, but because it offered similar performance at higher clock speeds. Thus, the Cyrix III is being marketed at its actual clock speed, not its P5 equivalent. So interestingly enough they corrected their marketing-driven bunk with some ill-concieved marchitecture changes.
Thus, this chip really will be clocked at 1000 MHz--but will only offer the integer performance of a PIII 800 (and the floating-point performance of a 486SX, but that's another story).
Sorry to be picky, but all modern CPU evaluate many instructions simultaneously, using multiple-issue systems for many similar functional units of eack kind. The difference with VLIW is that several instructions are held in the same instruction word.
More to the point, most modern CPU's, the chip itself determines which instructions should be run simultaneously. With VLIW, in theory, the compiler does this. Thus (in theory) the VLIW chip can be a lot simpler, since it doesn't need to spend a whole bunch of chip area on complicated logic to manage the process of choosing which instructions to process simultaneously and on large buffers to hold many instructions while the fastest combinations are chosen.
In conventional VLIW the instructions combined in the same word must not have any dependencies on one another. The Crusoe native instruction set is VLIW in this sense. The Itanium system - which they call EPIC - is more complex, allowing instructions that interfere with one another to be combined in the same word. This ought to be somewhat easier for the compiler, but it seems in fact that elements of it are causing problems.
Ah, what happens when theory becomes practice. See, the problem with all of the above is that traditional VLIW (and it is very a traditional idea, despite Intel pretending they just invented it (and even then, it was HP who invented EPIC)) can only produce code which is known to be dependency-safe at compile time. In the fields where VLIW has been used for decades--i.e. specialized DSP stuff--this means most code. In the fields in which Intel is trying to sell its IA-64 chips--i.e. general purpose, multitasking machines (first servers and eventually workstations and even, they claim, desktops)--this turns out to be almost no code at all. It turns out that virtually nothing that a general-purpose computer tends to do has very many instructions which can be proven at compile-time never to have any dependencies on many other instructions. This compares to a normal superscalar x86/RISC processor, which has the much more fruitful task of determining which instructions are likely to be dependency free at run-time.
This presented a problem. So, with EPIC, HP came up with the idea of having long-words (or "bundles") composed of instructions which were merely likely not to have dependencies on each other. So far so good...except that then you need a bunch of hardware on the chip to determine when you have dependencies and when you don't, and to figure out what to do when you do (after all, the chip still needs to execute all those instructions). That is, all the hardware that any non-VLIW superscalar CPU needs. But wasn't the whole point of VLIW was to make the chip simpler by moving all that stuff into the compiler and keeping it there?
Another feature that most modern CPU's (so called "out-of-order designs") have is the ability to pick one side of a conditional branch--the side which is more likely to be taken--and pretend it has already been taken, executing the results before it knows they will be needed. The problem with this is that now the chip needs to keep track of which instructions are definitely needed and which would have to be "thrown out" if it turns out the wrong branch was taken. This would seem to be counter to VLIW philosophy, but because of the speed gains speculative execution offers, EPIC includes it as well. While branching "hints" are indeed introduced by the IA-64 compiler, this is still just more complexity which ends up not being removed from silicon.
Further holding back Itanium is the fact that without dynamic handling of instructions in the CPU, the chip can't take advantage of something called register renaming, which essentially allows the compiler to pretend it's using certain registers while the on the chip the programs just use whatever registers happen to be available. The upshot of this is that Itanium needs a whopping 128 14-ported (a "port" is like a line into/out of the register) 64-bit general purpose registers. More registers--sounds like a good thing, right? Problem is that 128 14-ported 64-bit registers take up such a phenomenal amount of die space that it's difficult to get them to do all the things they need to do in one clock cycle and still stay in sync. The result is that Itanium won't clock very fast without failing, and Intel had to screw with the pipeline timings late in the design process to get it to "acceptable" clock speeds at all.
The end result of this? Amazingly, in a processor whose entire design philosphy is to remove as much complicated control logic from the chip to the compiler, the portion of Itanic's die dedicated to control logic will be bigger than the entire die of an Alpha 21264 on an identical process!! Intended to be a high-volume chip released at 800 MHz in late 1997 or 1998, Itanium is going to end up a low-volume chip released at 733 MHz in 2001, if indeed it is released at all in anything more than engineering-sample quantities.
Thus everyone's hopes have turned to the next IA-64 chip, McKinley. Intended to be released in late 2001 (put me on the record as doubting it) as a high-volume, moderate clock speed chip on Intel's upcoming.13um process, it may indeed be an impressive performer. (Interestingly enough, McKinley is being designed entirely at HP...) Whether that's because of or despite the EPIC design will be interesting to see. It is, at the least, pretty doubtful that the competing Alpha 21364 and Power4 chips around by then won't be even faster than McKinley, and they'll be manufactured on less advanced processes than Intel's.
Bottom line: at this point in the game, VLIW looks like a damn neat idea that never should have made the jump to general-purpose computing. Whether IA-64 will end up dominating the world anyways will be an interesting story to see. On the one hand, the server market isn't known for rewarding well-designed processors: the lion's share of the market is owned by Sun, whose UltraSPARC-II's are horribly outdated and outclassed on a per-processor basis by everything this side of a Celeron. Meanwhile, the Alpha, universally agreed to be the fastest and most elegant processor around, is languishing in the market. On the other hand, Sun's big strength (other than marketing) is in scalability, and given that the two big OS's for IA-64 appear to be Linux and Windows-64 (laff), it seems Intel won't be able to able to compete on this measure either.
If you want freedom of speech online, and advertising is speech, then what the hell are you thinking?
The actual legal distinction here is that while the First Amendment guarantees you the right to say anything you want, it doesn't guarantee you the right to force anyone to listen to it.
Thus, you are allowed to publish a newspaper saying whatever you want (with some restrictions: libel, etc.), but you don't have the right to force the New York Times to print your screed against evil mind-hijacking black helicopters on the front page. Or, you can say whatever you want to whoever'll listen, but you don't have the right to take your own PA system to the Super Bowl and broadcast your views to millions of people who just want to watch a football game.
So, DeCSS is protected by the First Amendment because it is speech that is simply published on the web for anyone who wants to hear it to get it. The right to publish the phrase "Streaming Teen Sex Slumber Fest" with a hyperlink attached is similarly protected by the First Amendment. The "right" to place it in everybody's email inbox is not.
But it still doesn't prove whether a persons CD buying goes up or down due to Napster...The studies are shit, basically. They don't prove a damn thing.
This argument only holds up if Napster use CAUSES more sales. Really, all we know is that Napster users are also record buyers, but the arrow of causation could point the other way -- that record buyers are more likely to use Napster.
It could be shown that Napster users buy a more-than-average number of records in the first place, and that Napster is causing them to buy fewer than they would, although still more than average.
People buy more CD's after having used Napster than they did before, after controlling for all major demographic factors.
To quote from Jupiter Communications' press release detailing their report: "When we conducted our consumer survey, controlled for key music purchasing factors-such as existing spending level, age, income, gender, and online tenure-we still found that Napster usage is one of the strongest determinants of increased music buying." (emphasis added)
Meanwhile, the only study the RIAA can point to is one which shows that sales at "college record stores" are going down. Unfortunately, this brain-dead excuse for a study miraculously fails to take into account purchases made at online record stores like CDNow!! This despite the fact that college students are always at the leading-edge of adoption of online phenomena, including online shopping.
Oh yeah--and the RIAA's report shows that sales at "college record stores" dropped more in the year before Napster came out than the year since!
So basically, the available evidence if pretty conclusive that so far, Napster has increased CD sales over what they otherwise would have been.
Perhaps "almost certain not to purchase it" was too strong a choice of words.
Still, the fact remains that most people only read most books once, while they listen to music many times. As I see it, there are three possibilities here. You check out a book/download a song from the library/Napster and...
1) you love it--it changes your life. You want to compensate the author/musician; you want to have the best quality copy of it around to cherish forever. Then you buy the book/CD, in either case.
2) you don't like it so much. You don't buy it, but then you wouldn't have wanted to buy it anyways; thus the library/Napster has done you a great service, by allowing you to avoid a sale you wouldn't have been happy with.
3) you like it quite a bit, but it's not life-changing. With respect to the book...well, you wouldn't have felt unhappy or ripped-off if you'd bought it, but since you've already read it and wouldn't again even if you had bought it, no sense in buying it now. With respect to the song, on the other hand, liking it quite a bit is more than enough for you to want to listen to it again and again. And as long as you're going to want to keep listening to it, it's very likely enough for you to want to hear it in the quality it was originally meant to be heard in. Assuming you have a decent stereo, it will sound much better on CD than on MP3, and you know it. Thus you're pretty likely to go buy it.
Since the majority of check-outs/downloads fall into category 3, Napster has the effect of being better for CD sales than libraries are for book sales. Or maybe it's, libraries are good for book sales by making young people who don't have the money to buy their own books into life-long readers, and then they buy lots of books later. But Napster has this effect as well as a much more direct positive effect on album sales.
Thus I'm almost positive that any study would find that Napster users buy more music than they will if Napster is shut down, while library-goers buy fewer books than they would if all the libraries were suddenly shut down.
You make some good points, but I still think they are mostly subsumed under the idea that what one "does" with a book is different from what one "does" with a song. Put it this way--the RIAA *wants* you to listen to a song once, because that will make you more likely to buy it. That's why they pay big bucks to get their songs on the radio, MTV, etc. A book publisher doesn't want you to read a book once for free--once you do that, the chance that you'll want to buy the book is almost nil.
Thus, while the "copyright" vs. "usageright" debate is relevant legally, it's not relevant functionally--it's not relevant to the function that libraries/Napster provides to the public. That function is the same--they provide a way to "use" copyrighted content in the way you would if you bought it...except with a slightly degraded look-and-feel experience, without the benefit of knowing you compensated the artist (or probably didn't, in the case of a CD), and arguably with a greater chance that the particular content you're looking for won't be currently available.
Basically, the objections you note aren't "functional" objections in the way I meant to use the term. (Perhaps a better term would be "utilitarian"--Napster and the library perform the same utility with respect to the way their various media are typically used.) When you say "functional", you mean the underlying functions which are actually making the whole thing possible; when I say "function" I mean the function to the user. In any case, this is made up for by the fact that while there is only one Napster, there are thousands of public libraries. (The number of people using Napster (20 million) may or may not be higher than the number of people using libraries; but the government spends money to try to get more people to use libraries, for chrissakes--it's viewed as a social positive, not a negative.) Thus, while you and I can't read the same copy of the same book, the fact remains that if we both wanted to check it out of our respective libraries at the same time, we wouldn't interfere with each other (because we'd use different libraries). It's a difference in the way the system works, but not in the function it provides to the user.
For example, the fact that you can listen to a particular MP3 at the same time as I can doesn't really matter to me, the user--what matters is, when I log on to Napster looking for a particular song, what's the chance it's going to be there? About the same chance as the chance a particular book is available at the library. There's a "functional" distinction to the system, but not to the user.
If anything, the copy of a book you check out of the library is more perfect than the "perfect" copy off Napster, because with Napster you're making a perfect copy of a copy that was degraded to begin with.
Eh, this response was sort of babbling and unfocused, but I hope you catch my drift. The differences between the way books and music are used makes matches up almost exactly to the differences between the way libraries and Napster work. Thus while the actual processes they go through are indeed different--and maybe different enough to make Napster run afoul of current law while libraries do not--they serve the same function to society, which is the important thing. Copyright protections were made to serve society, not to serve corporations which happen to have traditionally made money a certain way. If the function of a library is beneficial to society (I doubt many people would argue with this) than so is Napster. As such, it should be made legal (if it isn't already), not the other way around.
This would be a valid comparison if:
:P ...
1) You actually had to drive or walk to a building somewhere to "check out" a song
So a library is wonderful, but a library that delivers would be immoral, illegal, and a threat to all we hold dear in society? What's your opinion of the Bookmobile???
and while it was checked out nobody else in the area could "check out" the same song (or only a limited number of people anyhoo)
Napster's "collection" is only as large as the number of people who happen to be connected at that particular time. The chance of finding the song you're looking for on Napster is about equal to the chance of finding the book you're looking for at the library. In either case, if it's not there the first time you check you can always go back later and try to get it again.
The difference is, with a library, you can be certain that eventually you will get to read--and thus not have to purchase--any book you want. Even if they don't have it in their collection, they will get it for you on inter-library loan. Put it another way--would you think Napster any more "ok" if, when the song you wanted wasn't available, you could put in a request and be guaranteed that the system would email you the MP3 within a couple weeks??
The library let you check out as many of their several million publications as you wanted at one time
First, I have never ever heard of a library which limits the number of titles you can check out at one time. People routinely come out of a library with as many as a dozen books in hand--equivalent to hundreds of hours of content. MP3's which provided the same amount of unique content (in terms of length of time) would fill an average hard drive.
Second, there are almost certainly more unique titles at a decent library than there are unique songs available on Napster. In any case, I'm sure you wouldn't think a public library was somehow a scourge on society because it happened to have an incredibly wide selection--you'd think it was a really good library.
and let you keep the publications.
See my original post for why the fact that you don't get to keep your library book as long as you want is irrelevant to the analogy. Basically, it's because what one typically does with a book one purchases--i.e. read it once--is different from what one does with music one purchases--i.e. listen to it many times. The restrictions a library book puts on your enjoyment of it are look-and-feel issues, not functional ones--just like the restrictions MP3 puts on your enjoyment of music.
Heh.. I could go on and on listing reasons why this is a terrible comparison, but I won't... in a hurry - no time to type 'em up
Please do, as your first list was rather lacking.
The difference can be summed up quite simply: Napster makes copies. Libraries don't. And that's really all this trouble comes from.
This is the legal difference. As I stated at the beginning, I'm aware of why Napster more easily falls prey to the accusation of copyright infringement.
This is not, however, a functional difference. Yes, when you go to the library the book you are looking for may be checked out. On the other hand, finding a particular song on Napster is a hit-and-miss affair as well. As a rough estimate, I'd say that the chance a particular song you're looking for is available on Napster when you happen to log in is, well, about as good as the chance the book you're looking for is available at the library when you happen to show up.
The function Napster fulfills in society is still identical to that of a public library, and its moral standing ought to be the same as well.
No, not legally--I understand why copyright law is usually read such that Napster users might be infringing but library card holders are not. (On the other hand I'm pretty sure I remember hearing that the book publishers tried long and hard to sue public libraries out of existence when they first appeared.) But in terms of its effect on the marketplace for music, its moral ramifications, and its societal implications, I challenge anyone to show me a relevant difference between Napster (in its current form) and your local public library.
/. we see people dismissing Napster as nothing but a bunch of immoral law-breaking pirating hooligans. Guess what, people: you've been trolled.
Both are places where you can obtain a copy of a copyrighted work, and use and enjoy it in its intended manner, for free. In both, the original copy of a work is donated out of the generosity of their own heart by someone who has (presumably) legally bought and paid for the original copyrighted work. (Of course, in the case of a public library, such a person has done a "good deed", while with Napster they have engaged in "rampant piracy" or some such thing.) Sure, a library book doesn't have the same look-and-feel as one you'd buy yourself--yellowed pages, that krinkly plastic book jacket--but MP3's are even worse: no physical CD, no liner notes, no cover art; the risk of getting a bad recording, a recording that chirps or hiccups or cuts off just before the end of the song; and the certainty that no matter what you get it won't play on your stereo, and if it could it would sound like crap compared to the original CD.
Yes, you have to return or renew library books after two weeks, but the point is that's good enough for how most people enjoy most books--they read them once and never look at them again. Similarly, Napster allows you an experience that is "good enough for how most people enjoy most songs"--that is, if you've got some tune stuck in your head, or just want some background music while you surf the web, you fire up Napster and get it. No, a public library isn't good enough to replace ownership in the case of those really important books that really impact you and you just want to have around...but neither is Napster. For a truly moving musical experience, you need a real CD (or good vinyl) on a real stereo, not some 128 kpbs muddle, decrypted in an electrically noisy environment, coming out your cheap underpowered magnetically-shielded plastic speakers. That is, the fact that you don't get to keep library books is a look-and-feel issue, not a utility issue--and the public library is still ahead of MP3 in terms of look-and-feel.
If anything, libraries pose a much greater danger to the publishing industry than Napster does to the RIAA, because once you have checked a book out of the library and read it, you are almost certain never to purchase it. With Napster, on the other hand, downloading an MP3 arguably makes you more likely to purchase the CD than before; certainly there is conclusive evidence that Napster increases CD purchases overall.
And yet, public libraries are held up as the paragon of the public good, the ideal of a fostered community, the sort of thing politicians throw into speeches to demonstrate what's right about America (or, more likely, what used to be right about America but no longer exists). Meanwhile, Napster--which, if anything, encourages more community (libraries, after all, are known for explicitly discouraging chatting), illustrates the possibility for knowledge shared throughout humanity which is inherent in the Internet, leads to more legal music purchasing, and facilitates an alternative to an industry which affords the artists much fewer rights and a much lower share of the monetary fruits of their labor than does the publishing industry--is sued, demonized, held up as an example of everything that's wrong and immoral about today's culture.
Huh? What gives?? Before the entertainment industry bought new copyright laws in 1997 and 1998, there was no legal concept of copyright infringement without corresponding non-commercial gains. And yet suddenly everyone believes that sharing music with others is not only illegal (it's still arguable whether that's true) but somehow immoral as well?? Somehow everyone has this ridiculous idea that copyright entitles a copyright holder to oversee every use his/her content is put to, fair use be damned?? (For those who don't understand why this is so absurd: copyright is automatically extended to every single piece of content ever created, no matter by whom or for what purpose. The above idea would mean you would need to get the permission of a gas station before you could submit the receipt they gave you as part of an expense account.)
Napster should be held up as an example of what's right with the world, of a way the promise of technology is enabling people to share the art they love, to expand their musical horizons, or just to get a copy of the new NSync song to play as a joke. It's an example of how the Internet will revolutionize an industry by opening up alternatives to a greedy oligopoly which stifles artists' rights to their own creations.
And yet even on
Well I knew it was a mistake to break my rule about the futility of political discussions on /. (well, anything more political than RDRAM vs. DDR), but I'll bite. Yes, Krugman is a "liberal", if by that you mean someone to the left of you and the GOP party line. As far as economists and Americans go, he's probably just a tad left of center; as far as academics go, he's solidly conservative. Yes, Krugman probably just uses his New York Times column to publicly bash his conservative-but-also-well-respected colleague down Mass. Av., Harvard economist and G.W. Bush advisor Martin Feldstein. Yes, I may just subconsciously enjoy Krugman's column because I think Marty Feldstein is an asshole.
...You do know that virtually the entire academic establishment is liberal, right?
Nonetheless, the fact remains that here is one of the most respected economists in the world saying quite pointedly that the economic policy Bush is promising would have killed the economic boom were he already president, and will probably kill it if he is elected president. It may not be positive credit given to Clinton for creating the new economy, but I think if you listen carefully to all the Democrats' speeches, most of them aren't claiming positive credit anyways. (If they are, well, of course they're wrong; on the other hand, it's a political convention for crying out loud, of course they're going to exaggerate.)
You may argue that this is only because we had a Republican Congress forcing Clinton into fiscal discipline. Ok, fine. Disregarding the fact that the Republican Congress was the one so sure that Clinton's budget would send the country straight to hell in a handbasket that they shut down the government for a month before giving up and signing it, this is a reasonable argument. I'm all for divided government too.
The problem here is that the Congress will definitely be Republican for the next 2 and almost certainly 4 years. That means that if Gore is elected, we'll get a sensible compromise budget which will probably be what's needed to continue our current prosperity, and that if Bush is elected he'll be free of any meaningful checks-and-balances to push through whatever old economic plan he sees fit. Just to refresh your memory, he is currently promising to push through a plan which some very well respected economists (Krugman) think will derail the economy.
Ever wonder why Women's studies majors are liberals? Not because they know what they're talking about!
Women's Studies majors tend to be liberal because it is generally only liberal-minded people who believe women's studies is a field worthy of their time and study. Economics majors tend to be conservative partially because conservative-minded people often believe economics is most worthy of their time and study, but more often because it's a decent way to get into Business School. I'm not sure what you're point is here.
You do know that virtually the entire academic establishment is liberal, right?
I would wager that I know a good deal more about the academic establishment than you. (Note email address.) While parts of it are indeed prone to being absurdly liberal (e.g. your aforementioned Women's Studies), Economics is not one of those parts. Despite the popular notion that all of academia is overrun by Marxists and Feminists, it turns out that most fields and departments are remarkably well insulated from each other. While there are plenty of wacko Marxist and Feminist professors around on leading university campuses, I assure you none of them are in the Economics department, and that, besides, they almost all know quite a lot about what they're talking about.
You bring up the fact that successful business owners tend to be more conservative than respected economists. This, of course, is exactly the point: a "liberal" philosophy turns out to be quite well-suited for an economist, whose job is to ensure the fiscal well being of an entire society. Meanwhile, a conservative philosophy is quite appropriate for a business-owner, whose your job is to ensure the continued fiscal well-being of himself.
Guess which philosophy is better suited for the government?
Sure, the economy is doing well. However, that has between little and nothing to do with Clinton. The president has little control over the economy, beyond his control over taxes, going to war, and a few other significant acts, none of which Clinton has really executed. You'll be hard pressed to find any respected economist, even though they're mostly liberals, that will back Clinton's assertions. In all reality, the state of the economy has more to do with the Greenspan, technology, and arguably Reagan's tough stance against taxes and union abuse.
How about Paul Krugman, Nobel-prize winning economist at MIT? Would you consider him "respected", or is that know-nothing idiot too much of a liberal? (Side note: ever wonder why most respected economists are liberal?? Not because they know what they're talking about! Obviously not that!!)
Of course, I had to look long and hard to find it--all the way to yesterday's New York Times.
According to Krugman, while Clinton isn't wholly responible for the economic boom, or anywhere near it, he *is* largely responsible for balancing the budget, which in turn *is* largely responsible for keeping interest rates low and perpetuating our roaring economy. Conversely, Krugman argues, if Dole had been elected in 1996, and had enacted his promised tax cut, the boom would almost certainly have been shorter lived. Amazingly enough, Bush is proposing a tax cut and which looks remarkably like Dole's, and some pretty impressive spending increases on top of that.
I think I'll let the Nobel-prize winner take it from here: "Not long ago America faced a choice between sober, sensible fiscal discipline and huge, irresponsible tax cuts. We chose discipline, and were rewarded with growth beyond our wildest dreams. So why would anyone today propose exactly the kind of irresponsibility we were lucky to avoid four years ago?"
Thank you for a very interesting and informative post!
Thanks for actually reading the whole damn thing!
I don't think traditional expandable RAM has to go away completely, though. I think the solution would be further extending the NUMA (Non-Uniform Memory Access) concept of cache memory. We've already got very-high-speed L1 and L2 cache. Say this CPU+high-speed-memory card you propose has N ultra-high-speed on-die L1 cache, N*16 super-high-speed off-die L2 cache, and N*(2^10) of very-high-speed, CPU-local RAM. Then have an expandable main memory system of merely high-speed RAM, slower, but expandable and much larger, say, N*(2^12). To fill in some example numbers:
128 KB L1 cache
2 MB L2 cache
128 MB local RAM
512 MB main RAM
That way, you get the best of both worlds.
Interesting. I'd first point out that, to me at least, what you're proposing sounds a bit more like a gigantic (128 MB) L3 DRAM-cache than traditional NUMA. Of course, I don't know too much about NUMA, except that it's supposed to have a way to actually manage which data goes in which memory efficiently--which would be a very difficult problem in such a system.
For one thing, it's worth noting that under almost any concievable implementation, all 128 MB of data in the local DRAM/L3 cache would have to be mirrored in the 512 MB main DRAM--thus essentially "wasting" 1/4 of your main RAM capacity. There are ways around this (e.g. Thunderbird/Duron with their "exclusive" cache hierarchies) but from what I understand they would introduce tremendous latencies into such a system.
And indeed, that would be the biggest problem with this scheme--the latencies. If a program was looking for a piece of data, it would have to first check the L1 cache; then (if it didn't find it there) the L2 cache; then (if it didn't find it there) the very large local DRAM/L3 cache; and only then would it look for it in main memory (and god forbid not find it there either and have to pull it out of virtual memory!).
The upshot of this is that you'd get a pretty large miss-penalty every time you had to search all the way down to your main DRAM to find some data. On the other hand, it wouldn't be as large as the penalty currently associated with virtual memory, and we use that all the time. But still, I think you'd find on such a system that upgrading the main DRAM--like enlarging your virtual memory swap file--wouldn't have the same effect on system performance as upgrading main memory does today.
Could be wrong, though. Certainly an interesting idea.
Just to nitpick, the Pentium 4 bus is not "double wide double data rate". It is 128 bits wide, and quad-pumped. It does transmit data at 400 MHz. When Intel claims it is a 400 MHz bus, they're just as correct as claiming that AMD claiming a 200 MHz bus, and Rambus claiming an 800 MHz bus.
I'm pretty sure I'm right here. For one thing, the maximum bandwidth of the P4 FSB is 3.2 GB/s, which is 2 "pumps" x 100 MHz x 128-bits. For independent proof of this, note that Intel's top-of-the-line P4 chipset, Tehama, uses dual PC800 RDRAM channels, yielding...3.2 GB/s. If it were quad-pumped, 100 MHz and 128 bits wide as you claim, the FSB bandwidth would be 6.4 GB/s.
For another, there's no way I've ever heard of to actually "quad pump" a clock signal. "Double pumping" works because a clock signal is actually made up of two signals--the so-called "rising edge" when the signal turns on, and the so-called "falling edge" when the signal turns off. In contrast, there's just no natural way to divide a signal into four without using a PLL and a seperate clock generator. How do we know Intel isn't doing that? Well...the question becomes: "seperate" from what? The FSB clock *is* the only clock in a chipset; if they wanted to make it go twice as fast, they would just clock it at 200 MHz.
And no, Kingston's "quad-pumped" SDRAM isn't really quad-pumped either; it's just DDR which is cleverly interleaved to essentially make it twice as wide.
happens to the best of us
Apologies for the uber-post, but man this discussion needed an injection of information.
:)
Myth #1: It's Rambus vs. DDR vs. MRAM. It's been mentioned before, but bears repeating: MRAM will not be the next generation memory technology. It will at best be the next-next-next generation memory technology, as it's at least 5 years from commercial viability. However, I'd guess that even in MRAM's wildest dreams it will take longer than that before it ever makes it to PC main memory; first, it will be used as a replacement for what it is actually most like--not DRAM, but flash memory. While it has the potential to maybe one day be faster, smaller, and cheaper than DRAM, until then it will only be used in those places where its most important attribute--nonvolatility--is actually necessary.
Furthermore, there are any number of exotic competing technologies which are a) going to make it to market first and b) actually aimed at the PC main memory market. These include:
VC SDRAM: like SDRAM with a small SRAM cache--already available, but with disappointing performance, due to a bad implementation of a good idea; don't count it out in a future incarnation
FCSDRAM: which allows a more efficient ordering of access requests to cut down latency
DDR-II: the packet-based successor to DDR SDRAM, and the probable next standard
DDR-IIe: DDR-II with caching technology similar but superior to VC SDRAM's
and eDRAM: an exotic technique for putting DRAM directly on a microprocessor, which allows for extraordinary bandwidth and tiny latencies but requires an entirely new manufacturing process.
In any case, the above are not mutually exclusive (indeed, RDRAM is a DDR type of SDRAM), and I wouldn't be at all surprised to see some VC/e FCDDR-II be the PC main memory of choice in a couple years. (It'll have a better name, though
Myth #2: DRAM bandwidth is holding back the performance of today's PC's. Actually, the problem is not in the DRAM chips but rather in the bus that connects them to the CPU--that is, the Front Side Bus (FSB). The FSB on all current Intel chips is only 64-bits wide, single pumped. That means you only have 1.1 GB/s of bandwidth to the CPU with a new 133 MHz FSB P3, 800 MB/s with a 100 MHz FSB P3 or P2, and a measely 533 MB/s with a lowly Celeron. Not so coincidentally, the maximum bandwidth of the various standard types of SDRAM, PC133, PC100 and PC66 are...1.1 GB/s, 800 MB/s, and 533 MB/s respectively.
Ever wonder why 1.6 GB/s RDRAM wasn't any faster than 1.1 GB/s PC133 on all those P3 benchmarks earlier this year? At the time you probably either heard from someone else (or decided yourself) that it was just because "Rambus sucks," which, while true, isn't the whole story. Instead, the reason that the faster RDRAM didn't perform any faster is because its extra 533 MB/s of bandwidth is all dressed up with no place to go--it certainly can't go to the CPU, because the FSB is in the way, and it only lets through 1.1 GB/s. Now, there are couple edge conditions where that extra bandwidth can be utilized by sending some over the AGP bus and keeping some in buffers on the chipset to send later, but by and large the P3 is completely saturated by plain old PC133. This is the same reason why, when DDR chipsets finally come out for the P3 in a couple months, their performance is going to be a mite disappointing--all this extra bandwidth, no place for it to go. As for why the RDRAM system is actually slower most of the time...well, that's because Rambus sucks. (RDRAM has higher latencies than SDRAM, plus Intel's i820 RDRAM chipset is nowhere near as good as its BX or i815 SDRAM chipsets.)
Luckily, this is a bottleneck that is finally getting removed. AMD's Athlon and Duron CPU's both have double-pumped FSB's, meaning they'll be quite happy slurping up the extra bandwidth they get from their DDR chipsets, due out hopefully by October. Their FSB's can currently be set at either 2x100 MHz (1.6 GB/s) or 2x133 MHz (2.1 GB/s). And Intel's upcoming P4 goes a step further--it has a double-wide double-pumped FSB, allowing 3.2 GB/s @ 100 MHz core clock, and 4.3 GB/s @ 133 MHz.
These steps are, to put it mildly, vastly overdue, as the ratio of CPU-clock to FSB-clock has gone from 1:1 in the pre-486 days, to 2:1 with the 486DX2, to, for example, 3.5:1 on the two year-old P2-350 I'm typing on now, to a ridiculous 8.5:1 on the latest greatest (nonexistant) P3-1133 to a miraculously exorbitant 10.5:1 on a Celeron-700. What this means is that that CPU is spending a whole lot more of its time waiting every time it needs to access memory--10.5 clock cycles for every 1 cycle of memory access, to be exact. While the impact of this can and has been minimized through all sorts of tricks like bigger caches, out-of-order execution, and prefetching compilers, the overall performance impact is "damn."
So thankfully these ridiculous ratios will finally be brought down as the next generation of CPU's with decent FSB's ships.
Having read this, you're probably now lulled into believing our third myth. Unfortunately, you're wrong.
Myth #3: DRAM performance will hold back the performance of tomorrow's PC's. As it turns out, that's not true either. For proof, just take a look at the latest generation of PC graphics cards. The latest and greatest offerings from ATi and nvidia both include 64 MB of double-wide DDR SDRAM at speeds up to 2x183=366 MHz. That's 5.9 GB/s of bandwidth, way more than enough to saturate the FSB of top-of-the-line CPU's for at least the next 18 months. All this is available, plus a very complicated GPU, fast RAMDAC, and some other components, on a card selling for about $400--thus we can guess that that 64 MB of 5.9 GB/s RAM costs around $250--or, humorously enough, about the cost of 64 MB of 1.6 GB/s PC800 RDRAM! Furthermore, nvidia just announced the GeForce2 Ultra, with 64 MB of 2x250=500 MHz DDR. That's 8 GB/s!! The cost? Another $100.
But all of this is disregarding that little something called supply-and-demand. There are several legitimate reasons why such high-speed DDR costs more to make than normal-speed DDR (which costs a negligable amount more than plain-old SDRAM), but the main reason for its (not even so) high price is its scarcity and the incredible demand for it by graphics card makers. On the other hand, the main reason RDRAM has come down in price so much (6 months ago it cost around 3 times as much) is because there is a glut of it on the market. Everyone in the industry (except Dell) has realized that the i820 chipset is a dud, a bomb, already shuffled off to obsolescence. RDRAM on the PC is a no-go, at least until the P4 comes out. Thus, excess RDRAM is being sold-off at fire-sale prices. Once the P4 is out in enough volume to actually impact prices (i.e. January or February if Intel is lucky), expect another surge in RDRAM prices. Back on the other hand, in a year or so that 8 GB/s (!) 500 MHz DDR SDRAM in the new GeForce2 Ultra will be pretty mainstream stuff, going for but a modest premium over even bottom-of-the-line SDR SDRAM (which will still be around for some time).
"So great!" you might say. "Let's make chipsets with 8 GB/s FSB's, and all our problems will be solved!" Well...there's the rub.
See, the point of this story is, the problem in getting a high-speed memory subsystem in your PC is not the DRAM--they can get that damn fast already. (8 Gb/s!! Ok I'll stop now.) The problem is the stuff in between: the motherboard and the chipset. That is, the bus.
It turns out that it's easy to get a super-high-speed bus onto a graphics card, but an electrical engineer's nightmare to get one on a PC motherboard. Let's count the reasons why:
1) The traces (wires) on a motherboard are a whole lot longer than on a graphics card. The higher the capacity of a trace, the higher quality (read: more expensive) it has to be. The longer it is, the higher quality it has to be to have the same capacity. Eventually, it's just beyond the capabilities of our current manufacturing to make traces that are long enough and high enough capacity to work with high-speed DRAM on a big motherboard.
2) There's lots of other components on a motherboard. This means more interference ("crosstalk"). This means--you guessed it--the traces need to be even higher quality.
3) A motherboard has to be designed to work with almost any amount of DRAM--one DIMM, two DIMM's, three DIMM's, of varying amounts, made by anyone from Micron to Uncle Noname. Graphics cards are fixed configurations which can be validated once and forgotten about.
4) The DRAM in a graphics card is soldered to the board. The DRAM in a motherboard has to be removable and communicate through a socket, which adds to the electrical engineering complexity.
Plus there's probably a couple more I can't think of at the moment. The point is, the weak link in the memory subsystem is not the DRAM. Today it's the chip's FSB, next year it will be the motherboard and the chipset, but it's not the DRAM.
However, there are ways the DRAM might be changed to get around this limitation. (Disclaimer: I don't know as much about this part of the equation as I do about the rest.) Apparently the packet-based protocol used in RDRAM is one way to do this--for some reason, communicating in packets minimizes the danger of data loss due to crosstalk. Probably for the same reason it works for networks, the Internet, etc.
Great! The problem is, RDRAM isn't designed to maximize bandwidth, but rather to maximize bandwidth/pin. While this is real neat for itty-bitty embedded devices where you need to keep pin count to a minimum, the problem is that each pin is connected to its own trace...and thus RDRAM ends up requiring the motherboard to carry much more bandwidth/trace than DDR SDRAM. See above (#1) for why this is a bad idea.
So, the packet-based, but-otherwise-more-or-less-normal-DDR DDR-II, due out in 1.5-2 years, looks like a good candidate to solve this problem, at least for the time being.
In my opinion, though, even that is only a temporary solution. I'd say eventually the industry is going to have to give up the idea of expandable RAM, and change the entire architecture of the motherboard so that the CPU and main memory are moved off it, onto a daughter card, like the graphics card is now. That would mean you would have to buy your CPU and your RAM together--no more adding more RAM as a quick performance booster, which would be a considerable loss. However, it seems as if it would get rid of the tremendous memory bandwidth problem PC's are facing today in one fell swoop. In comparison to the performance gains realized, it would be an easy tradeoff for the vast majority of consumers, who never upgrade their RAM anyways.
The other possible solution is similar-but-different: a switch to eDRAM, which I discussed lo these long paragraphs ago (up near the top). This, however, would require an even bigger infrastructure change, although the benefits might be even greater.
Just a clarification: when referring to RDRAM, RAMBUS decided that PC800 means 800MB/sec, not 800MHz, so it isn't really running that fast.
Just a clarification: you are completely wrong. The various types of RDRAM do in fact refer to their clock speed, not their bandwidth. PC800 does indeed refer to 800MHz; as RDRAM is 16-bits wide per channel, this means PC800 has a theoretical maximum bandwidth of 1.6 GB/s. By way of comparison, PC133 SDRAM is 64-bits wide and 133 MHz, and so it has a max bandwidth of 1.1 GB/s.
So, to reiterate, you're wrong. Now, however, it begins to get confusing. First off, PC800 RDRAM isn't really running at 800 MHz; it's running double data rate--transmitting twice per clock--at 400 MHz. As far as the PC industry goes, it's an acceptable fudge, and not nearly so bad as Intel saying the double-wide double data rate 100 MHz FSB on the P4 is "400 MHz".
Then it gets even more confusing. See, it turns out that PC 700 RDRAM actually runs at 2x356=712 MHz most of the time (good!) whereas PC 600 RDRAM actually runs at 2x266=533 MHz most of the time (bad!). This has to do with the vagaries of timing these cobbled together brands of RDRAM (only marketed because the yields on PC 800 were so awful) to run with 133 MHz FSB chipsets. If run on a 100 MHz FSB chipset--which they never are--they will run at their advertised 600 and 700 MHz rates.
So...in order to get rid of all this confusion but keep the handy-dandy "PC___" designation (and to one-up Rambus in the "my number's higher than yours" game), JEDEC has decided that from now on all its DRAM standards will be numbered based on their maximum bandwidth rather than their clock speed, actual or DDR or otherwise. Thus, the DDR we will see in DDR motherboards in a couple months will either be branded PC1600 (2 x 100 MHz x 64-bits) or PC2100 (2 x 133 MHz x 64-bits).
All done? Not hardly. It turns out that the first generation of PC2100 will have higher latency timings for the various stages of a random access than will PC1600, thus making it slower in certain situations while faster in others. Of course, within a couple months, lower latency PC2100 will be around, which may or may not be designated PC2100A. See how this all helps the customer and makes things easier???
Of course, the DDR for graphics cards is categorized neither by its maximum bandwidth nor its clock rate but rather by its clock period: i.e. 2x166 MHz DDR is called "6ns DDR" when its on a video card (because 1 second / 6 nanoseconds = 166 million); 2x183 is 5.5ns, and the new GeForce2 Ultra's are shipping with incredible 2x250 MHz 4ns DDR SDRAM.
And, of course, any and all of the above DRAM is overclockable to any speeds and latency timings you want; it's just only guaranteed to work at the marketed speed. Oh, and how fast any of this all is depends just as much on your chipset and, in the case of RDRAM, your power consumption settings. (Even if you're plugged into the wall, don't be too profligate with those power settings or the whole thing will overheat!)
And I forgot to mention VC SDRAM, which is available now, and FCSDRAM, eDRAM, DDR-II and DDR-IIe, any of which might/will make the jump to PC main memory in the coming years (at least before MRAM). Isn't it all so simple now?? Good.
I think you're underestimating the X-Box by quite a bit.
Actually, it won't be 10x more powerful than the PS2. More like twice as powerful.
It's less a matter of "the X-Box is n times as powerful" and much more a matter of the programming paradigm the consoles are best suited for. The PS2 is impressive in terms of pure FP thouroughput, memory bandwidth, etc. Where it suffers is in its lack of high-level programming tools and serious dearth of onboard RAM, especially video RAM. Specifically, the PS2 has 32 MB of main memory, but only 4 MB of video memory. The only good thing is that the two are connected with a high-bandwidth (3.2 GB/s) bus. This compares to the typical setup on a current high-end PC game: whole bunch of main RAM, 32 MB of video RAM, but a low speed (AGP is a bad joke) bus connecting the two. This means that a whole generation of programmers who learned to program 3D games according to the current PC model--that is, "just load all the data you need for a level into video RAM at the start, and work out of video RAM as much as possible"--have to try to figure out a completely different way of doing things. No matter how good they are, they'll never get around the fact that 4 MB just ain't enough to hold detailed textures, not to mention your z-buffer, framebuffer, etc. The obvious solution--find some way to store some of that stuff in the main memory and access it only when needed--ends up requiring a totally different approach to the rendering process. Happily enough, each developer needs to roll the solutions to these problems on their own, in a foreign assembly language, because high-level libraries for the PS2 are, at this point, almost nonexistant.
The result? Developers, especially all those PC developers looking to make the jump to the much higher volume world console gaming, are none too enthusiastic. Meanwhile, despite the very impressive potential of the PS2, the first generation of games is so badly programmed they barely look any different from games for the Dreamcast. In many cases, they look worse (after all, at least DC has 8 MB of video RAM).
Contrast the X-Box. It has a 64 MB unified memory architecture. Not so coincidentally, by the time it comes out, most decent PC 3D cards will have...64 MB of memory. (The fact that the X-Box's 64 MB will also have to hold the game code, etc. is not as large a problem as you think--indeed, most in-game code can fit into a CPU's cache.) The X-Box can access this RAM across a 6.4 MB/s bus--twice as good as the PS2, and better than any current PC card (except the new GeForce2 Ultra).
Best of all, the X-Box will work with both 3D gaming API's around for the PC: DirectX and OpenGL. While one might have some complaints about the peculiarites of these API's, they are many many many many times better than any API's available for consoles, much less the PS2. Plus, their use makes porting any PC game to the X-Box a snap.
Developers, by the way, are much more enthused about X-Box than PS2 these days...
In the same situation, the original Playstation whooped Nintendo's ass even though the N64 was more than 3X faster, and featured stuff like texture filtering and full screen anti-aliasing (which PSX doesn't support.) Of course, Nintendo actually knew the console industry, and knew how to deliver a simple, stable, easy to use product
I disagree. The N64 failed because it used cartridges instead of CD's. For one thing, this meant that its superior processing power was wasted on games with very low detail textures, and thus that its graphics looked no better than those on the "underpowered" PS. For another, it meant that Nintendo could continue to pocket a $15 licensing fee/media cost for each game sold, as opposed to about $3 for each PS game. Guess which console's games cost less? Guess which had more developer support?? Nintendo's error was in treating the market as if they still had a monopoly.
Microsoft is bringing too much PC garbage into the XBox to be able to do that. XBox will not be simple, stable, nor easy to use. It will require updates, and upgrades, and patches.
How do you know? There is simply no basis for this in fact. None. Zero.
Meanwhile, the PS2 will need a cable modem peripheral for Internet capability, fast becoming one of the most important aspects of the modern video-game experience. (Built into X-Box.) As history shows us, that is indeed a killer. How many console peripherals have been widely successful, in the history of console games?? None.
Now, the X-Box does have a hard drive, but it will not be end-user accessible. It is mainly for saving games and caching purposes. If used as MS says it will be used, it is only an asset.
And the X-Box uses a stripped-down version of the Win2k kernel. So? Has anyone shown W2k to be any less stable than, say, Linux running a GUI? Didn't think so. Is there any reason to think Embedded W2k won't be as stable as, say, Embedded Linux? No.
Nothing against MS, it's just that it doesn't understand the industry.
Precisely what was said about Sony before the PS. Sony made great strides to study the industry and not presume to attack it the same way it had in other industries, and from all appearances so has MS.
None of this takes into account the fact that Playstation 2 is coming out more than a year earlier. As history shows us, that's a killer. PSX whopped Nintendo largely due to the fact that N64 came out more than a year later.
Uh...the Sega Saturn came out before the PS. It failed miserably. Why?? Funny you should ask. Seems it was too difficult to program for...
Lastly, Sony is a lot bigger than Microsoft, and they have more developer support and consumer mindshare.
False, fasle and debatable.
MS is going to be eaten for lunch.
Don't be so sure.
have u played Deus X ? Was wondering about that game ? someone give me a review so I can decide if I should spend my hard earned $$$'s :)
Deus Ex review index
Summary? About half the reviews contain the words "game of the year" somewhere in their text...
As a matter of interest, whats your take on Crusoe's VLIW instractions ? To what extent can the problems with VLIW be circumvented by running the compiler at run-time ?
My initial guess would be that you can do it to some extent, provided your compiler is sophisticated enough, and you're prepared to compile several versions of the same source for different input data.
My guess would be similar--that, by looking for dependencies at run-time instead of compile-time, Crusoe has a much better shot at generating fast code and keeping the CPU small, cool, and simple. After all, with their approach, they are successfully able to do what IA-64 can only promise: move all the complexities of instruction scheduling from hardware to software.
Or are they? Because Crusoe (the hardware) is a straight-up in-order VLIW chip, its runtime compiler is actually doing two things: recompiling compiled x86 (or whatever) instructions, and scheduling them. Most of the criticism levied at Crusoe's approach focuses on the first half of this equation, and proceeds along the lines that "JIT is a bad idea, because it's why Java is so slow." As it turns out, I couldn't disagree more. For one thing, much of the reason Java is slower than C/C++ is because it is safer and more OO--it runs its own garbage collector and forces everything to be an object, amongst other things. For another, it's not actually slower! The newest Java JIT's manage to generate faster code than static compilers in many cases--and well they should, because they know more about the machine they are compiling to and the most common critical paths through the software than a static compiler ever could. Indeed, HP is working on a runtime interpreter which will speed up almost any precompiled code.
The reason JIT's can work so well is because they only need to compile the code once, then sit back and profile it, recompiling only when necessary. In other words, they incur a lot of overhead at first, but pretty much stay out of the way afterwards unless they'll really help out.
Now on to the second half of Crusoe's compiler--the scheduler. As I mentioned before, this sounds like a good idea--taking some functionality off of hardware and moving it into software. But when you think about it, you realize there's no such thing as "taking functionality off of hardware and moving it into software"--after all, the "software" still needs to execute on the same hardware!
What you're actually doing, then, is moving a function from having dedicated on-chip hardware performing it to having to be run with normal general-purpose hardware. This still has the very real benefit of making the chip a lot simpler, but now you've added a scheduler that needs to take clock cycles from the code it's trying to schedule.
The big question, then, is how much can the scheduler be like the compiler--that is, just doing its work once and then only stepping in when necessary. If, by moving the scheduler from dedicated on-chip logic to software using general-purpose logic, you make it able to do that much better, then it may be a significant design win. If, however, the scheduler needs to do anywhere near as much work as it would have as dedicated on-chip hardware, you're going to end up losing speed.
Which of these is the case? I have no idea. Obviously, a lot of very smart people (Dave Ditzel, etc.) thought the former. On the other hand, Dave Ditzel is reportedly the one responsible for keeping Sun's chips in-order while the rest of the world moved to out-of-order; a quick comparison between an Alpha 21624 and an UltraSPARC-II (or even the upcoming UltraSPARC-III) shows you who was right on that one. (Hint: not Dave Ditzel.)
What we do know is that Crusoe is a lot slower than Transmeta originally thought a runtime interpreted VLIW processor would be. There have been strong reports that they originally envisioned their processors would be able to beat leading-edge x86 chips handily, and only scaled back to the low-power market once their original benchmarks came back disappointing. Even at the low end of the scale, they're attracting a lot of ridicule amongst chip designers for trying to "reinvent the benchmark" because their chips can't compete. I happen to believe that (work/time)/power is a useful benchmark for the mobile arena; still, there's no denying that Transmeta would rely on traditional benchmarks if they could. Furthermore, it looks as if several chips may end up being able to compete with Crusoe even on (work/time)/power--StrongARM's, the much-maligned Cyrix III, and various other low profile simple RISC chips coming out of the woodwork to compete for the "mobile embedded" market.
So, while I would very much like Transmeta to succeed, so far--just as with IA-64--there's little indication that it's more than a bunch of hype. Perhaps after a disappointing first iteration, VLIW will get its kinks worked out and become the standard general-purpose CPU design philosophy of the next couple decades, just as RISC has been for the last two. (And yes, modern x86 chips are designed according to the RISC philosophy, even though the x86 ISA is CISC.) However, I have to say I doubt it. Looking ahead, all the badassest designs of the future (MAJC, Power4, 21464, SledgeHammer) seem to be moving towards keeping the dynamically scheduling RISC architecture and adapting it for CMP--chip level multiprocessing.
But, as always, only time will tell.
The Alpha is more powerful than Pentium III, but not by as much as you'd might think; most of its advantage for supercomputing comes from its superior bus.
Actually, the main advantage of the Alpha comes from the fact that it is not held back by requiring compatability with the x86's god-awful stack-based floating point registers. That's why a GHz PIII can equal a 733 Alpha 21624 in SpecINT, but gets blown away on SpecFP by a factor of 2.5 or so. The superior chipsets of the high end RISC-based set help quite a bit too, of course, though that advantage is partially matched as far as SPEC goes by Intel's incredible (and non-functioning for most other code) compilers.
As for Sledgehammer and Willamette, they hope to narrow this gap by trying to replace the x87 FPU stack for most code with the double-percision capable SSE2, and by moving to wider buses with faster DRAM. On the other hand, the 21634 and Power4 look remarkably good, and ought to extend the high-end chips' lead for quite some time.
Insightful post. One addition:
considering that the wholesale price of 1 GHz Athlon Thunderbirds was just dropped, and will probably drop again within a month or 2, it'll only be a few months before a 1GHz Athlon can be bought for about $500 or less.
Dunno if you heard, but the price of the 1 GHz TBird is going to drop to $539 on Monday. So rather than a few months until it's about $500, you only need to wait 4 days...
And one nitpick: while the chip we're talking about is supposed to be a redesign, it won't be much of one. Rumor has it the Samuel 2 will add an improved (i.e. fully clocked) FPU and 64 KB of L2 cache. We'll see. While both of these are very badly needed improvements, the fact is that the Samuel 2 will still be a very simple in-order chip trying to compete with the massively superscalar and agressively out-of-order designs of AMD and Intel. As such it just might end up being a great chip for cheap low-power devices, due to its small die size, but it has no chance of offering a viable (pun intended?) alternative for the desktop.
Jobs' presentation provided a Photoshop (TM) shootout between a dual-processor 500 MHz Power Mac G4 and a single processor 1 GHz Pentium. As expected, the PowerPC finished the test in about half the time it took the PC.
That's because the test was, as expected, rigged. That is, it only used a certain set of filters which happen to run faster on PPC than on x86. It would be quite easy to pick a different set of filters and "show" that the PIII is faster than the G4 clock-for-clock on Photoshop. (Not to mention the fact that Photoshop is perhaps the only mainstream program better optimized for the Mac than the PC.)
A fairer Photoshop benchmark (and using Photoshop as your sole benchmark is pretty shortsighted, to say the least) is PSBench, which runs not 3 specially selected filters like Steve did, but a full 21. The results? A 500 MHz G4 is a bit slower than an 800 MHz P3. A dual 500 MHz G4 is probably not much faster than a 1 GHz P3, and certainly no faster than a (cheaper) dual 800 MHz P3.
For a rather exhaustive look at G4 vs. x86 benchmarks, try here. The upshot? A G4 500 is maybe as fast in raw integer and FPU speed as...a PIII 400. That is to say, the G3 was about equal with the PII clock-for-clock; however, the Coppermine PIII's have since added some stuff which the G3/G4 can't match--namely, a much faster L2 cache and 133 MHz FSB.
Where the G4 really shines, of course, is in those programs which can take advantage of AltiVec--and indeed, those are about the only benchmarks you'll find on that page. (You won't, however, find any gaming benchmarks, because the Mac would of course be "unfairly" limited by its lack of good graphics cards.) In raw SIMD-plus-FPU, a 500 MHz G4 performs about as well as...well, it depends, but a fair guesstimate would be a PIII 750 or an Athlon 650. If you look at the page, you'll find that the Mac wins quite a few benchmarks, and that one or both of the x86 chips wins most of them, and that the margins of victory vary widely.
Suffice it to say, though, that even if you do run Photoshop all day, the performance of Apple's hardware is not a good reason to buy a Mac. With the exception of Seti@Home and RC5 (but not OGR!), there is a significantly cheaper PC which will run any program faster. This isn't to say there aren't other good reasons to buy Macs. But when one platform's top chips double in speed in a year, and the other's only go up by 50 MHz, you can bet that the first platform is going to be faster.
It's disappointing that the Tom's Hardware article doesn't contain an architectural block diagram of the CPU, or much information about how much gets done per clock.
Check out the review at Ace's. It doesn't quite contain a full block diagram, but does a much better job than Tom's at discussing the architecture of the chip.
The summary: whether to try to keep die size/power consumption low or because they didn't have the expertise, Centaur (later bought by Cyrix later bought by VIA, the ones who actually designed this chip) decided to keep it very simple. Thus, the chip is in-order, with a relatively deep pipeline (11 stages), relatively large 128 KB L1 cache (it needs it to try to make up for the fact that as an in-order chip it needs to sit and idle while waiting for any memory accesses), and just 4 execution units--2 SIMD, 1 ALU and 1 FPU.
The good news: it's just 76 mm^2 (on a not-very-good ".18 micron" process), consumes very little power, and runs cool enough to forego a fan. The bad news: no L2 and a half-clocked FPU mean laughable performance as a desktop or even a laptop chip. It might do ok compiling kernels and web browsing, but anything requiring a decent cache or any FPU at all (i.e. playing games, encoding MP3s, anything involving 3D, and even plain old office apps) and you're better off with last year's Celeron or K6-2.
The US government maintains export controls on any processor with a performance of greater than 2 gigaflops, making it slightly difficult for some high tech companies and government agencies in India, China, and Russia to purchase high end Intel chips. By being a Taiwanese company, Via can potentially grab a huge, rapidly growing market from Intel and AMD, which may have legal difficulties selling chips from even their non-US chip fabs to these countries.
Incorrect, and absolutely irrelevent anyways. First off, those export restrictions were lifted a few months ago. And second, current Cyrix III's have their FPU's clocked at only half the chip speed, making the FPU performance of a CIII 550 roughly equivalent to that of a 6-year old Pentium 200, or of a theoretical Athlon 90 or so. Rumor has it the FPU will be running at full clock speed by the time they hit 1000 MHz sometime early next year, but even then you're talking maybe "Athlon 400" performance, possibly worse. And even then, it appears it will only be any good at single-percision FP, not the double-percision which the export controls are concerned with.
In other words, nowhere near worth an export control. And nowhere near worth sticking in anything this side of a web pad, either. Frankly, this chip is just not very good.
even if they manage to release an 1 GHz chip, it's probably gonna be PR-1000 aka "equivalent to a 1 Ghz Pentium III"
First off, the PR ratings were based on the integer speeds of the original Pentiums (P5), not P6 chips.
And second, actually no; Via specifically changed their Cyrix III over from the Joshua core they had developed in-house over to the current "Samuel" core purchased from Centaur, not because the Samuel core had better performance, but because it offered similar performance at higher clock speeds. Thus, the Cyrix III is being marketed at its actual clock speed, not its P5 equivalent. So interestingly enough they corrected their marketing-driven bunk with some ill-concieved marchitecture changes.
Thus, this chip really will be clocked at 1000 MHz--but will only offer the integer performance of a PIII 800 (and the floating-point performance of a 486SX, but that's another story).
Sorry to be picky, but all modern CPU evaluate many instructions simultaneously, using multiple-issue systems for many similar functional units of eack kind. The difference with VLIW is that several instructions are held in the same instruction word.
.13um process, it may indeed be an impressive performer. (Interestingly enough, McKinley is being designed entirely at HP...) Whether that's because of or despite the EPIC design will be interesting to see. It is, at the least, pretty doubtful that the competing Alpha 21364 and Power4 chips around by then won't be even faster than McKinley, and they'll be manufactured on less advanced processes than Intel's.
More to the point, most modern CPU's, the chip itself determines which instructions should be run simultaneously. With VLIW, in theory, the compiler does this. Thus (in theory) the VLIW chip can be a lot simpler, since it doesn't need to spend a whole bunch of chip area on complicated logic to manage the process of choosing which instructions to process simultaneously and on large buffers to hold many instructions while the fastest combinations are chosen.
In conventional VLIW the instructions combined in the same word must not have any dependencies on one another. The Crusoe native instruction set is VLIW in this sense. The Itanium system - which they call EPIC - is more complex, allowing instructions that interfere with one another to be combined in the same word. This ought to be somewhat easier for the compiler, but it seems in fact that elements of it are causing problems.
Ah, what happens when theory becomes practice. See, the problem with all of the above is that traditional VLIW (and it is very a traditional idea, despite Intel pretending they just invented it (and even then, it was HP who invented EPIC)) can only produce code which is known to be dependency-safe at compile time. In the fields where VLIW has been used for decades--i.e. specialized DSP stuff--this means most code. In the fields in which Intel is trying to sell its IA-64 chips--i.e. general purpose, multitasking machines (first servers and eventually workstations and even, they claim, desktops)--this turns out to be almost no code at all. It turns out that virtually nothing that a general-purpose computer tends to do has very many instructions which can be proven at compile-time never to have any dependencies on many other instructions. This compares to a normal superscalar x86/RISC processor, which has the much more fruitful task of determining which instructions are likely to be dependency free at run-time.
This presented a problem. So, with EPIC, HP came up with the idea of having long-words (or "bundles") composed of instructions which were merely likely not to have dependencies on each other. So far so good...except that then you need a bunch of hardware on the chip to determine when you have dependencies and when you don't, and to figure out what to do when you do (after all, the chip still needs to execute all those instructions). That is, all the hardware that any non-VLIW superscalar CPU needs. But wasn't the whole point of VLIW was to make the chip simpler by moving all that stuff into the compiler and keeping it there?
Another feature that most modern CPU's (so called "out-of-order designs") have is the ability to pick one side of a conditional branch--the side which is more likely to be taken--and pretend it has already been taken, executing the results before it knows they will be needed. The problem with this is that now the chip needs to keep track of which instructions are definitely needed and which would have to be "thrown out" if it turns out the wrong branch was taken. This would seem to be counter to VLIW philosophy, but because of the speed gains speculative execution offers, EPIC includes it as well. While branching "hints" are indeed introduced by the IA-64 compiler, this is still just more complexity which ends up not being removed from silicon.
Further holding back Itanium is the fact that without dynamic handling of instructions in the CPU, the chip can't take advantage of something called register renaming, which essentially allows the compiler to pretend it's using certain registers while the on the chip the programs just use whatever registers happen to be available. The upshot of this is that Itanium needs a whopping 128 14-ported (a "port" is like a line into/out of the register) 64-bit general purpose registers. More registers--sounds like a good thing, right? Problem is that 128 14-ported 64-bit registers take up such a phenomenal amount of die space that it's difficult to get them to do all the things they need to do in one clock cycle and still stay in sync. The result is that Itanium won't clock very fast without failing, and Intel had to screw with the pipeline timings late in the design process to get it to "acceptable" clock speeds at all.
The end result of this? Amazingly, in a processor whose entire design philosphy is to remove as much complicated control logic from the chip to the compiler, the portion of Itanic's die dedicated to control logic will be bigger than the entire die of an Alpha 21264 on an identical process!! Intended to be a high-volume chip released at 800 MHz in late 1997 or 1998, Itanium is going to end up a low-volume chip released at 733 MHz in 2001, if indeed it is released at all in anything more than engineering-sample quantities.
Thus everyone's hopes have turned to the next IA-64 chip, McKinley. Intended to be released in late 2001 (put me on the record as doubting it) as a high-volume, moderate clock speed chip on Intel's upcoming
Bottom line: at this point in the game, VLIW looks like a damn neat idea that never should have made the jump to general-purpose computing. Whether IA-64 will end up dominating the world anyways will be an interesting story to see. On the one hand, the server market isn't known for rewarding well-designed processors: the lion's share of the market is owned by Sun, whose UltraSPARC-II's are horribly outdated and outclassed on a per-processor basis by everything this side of a Celeron. Meanwhile, the Alpha, universally agreed to be the fastest and most elegant processor around, is languishing in the market. On the other hand, Sun's big strength (other than marketing) is in scalability, and given that the two big OS's for IA-64 appear to be Linux and Windows-64 (laff), it seems Intel won't be able to able to compete on this measure either.
If you want freedom of speech online, and advertising is speech, then what the hell are you thinking?
The actual legal distinction here is that while the First Amendment guarantees you the right to say anything you want, it doesn't guarantee you the right to force anyone to listen to it.
Thus, you are allowed to publish a newspaper saying whatever you want (with some restrictions: libel, etc.), but you don't have the right to force the New York Times to print your screed against evil mind-hijacking black helicopters on the front page. Or, you can say whatever you want to whoever'll listen, but you don't have the right to take your own PA system to the Super Bowl and broadcast your views to millions of people who just want to watch a football game.
So, DeCSS is protected by the First Amendment because it is speech that is simply published on the web for anyone who wants to hear it to get it. The right to publish the phrase "Streaming Teen Sex Slumber Fest" with a hyperlink attached is similarly protected by the First Amendment. The "right" to place it in everybody's email inbox is not.
But it still doesn't prove whether a persons CD buying goes up or down due to Napster...The studies are shit, basically. They don't prove a damn thing.
Wrong.
This argument only holds up if Napster use CAUSES more sales. Really, all we know is that Napster users are also record buyers, but the arrow of causation could point the other way -- that record buyers are more likely to use Napster.
It could be shown that Napster users buy a more-than-average number of records in the first place, and that Napster is causing them to buy fewer than they would, although still more than average.
People buy more CD's after having used Napster than they did before, after controlling for all major demographic factors.
To quote from Jupiter Communications' press release detailing their report: "When we conducted our consumer survey, controlled for key music purchasing factors-such as existing spending level, age, income, gender, and online tenure-we still found that Napster usage is one of the strongest determinants of increased music buying." (emphasis added)
Meanwhile, the only study the RIAA can point to is one which shows that sales at "college record stores" are going down. Unfortunately, this brain-dead excuse for a study miraculously fails to take into account purchases made at online record stores like CDNow!! This despite the fact that college students are always at the leading-edge of adoption of online phenomena, including online shopping.
Oh yeah--and the RIAA's report shows that sales at "college record stores" dropped more in the year before Napster came out than the year since!
So basically, the available evidence if pretty conclusive that so far, Napster has increased CD sales over what they otherwise would have been.