very few things in life are free, and commercial software is not one of them
You're not the only person to have expressed this idea, but I figured I'd pick on you to correct it.
The idea that, just because something is closed source, if it's free you have to be giving up something--in this case, giving up a rather disturbing amount of your privacy without your consent--is ludicrous.
The reason RealJukebox is free is because it is a disabled demo. You can only encode mp3s at 96kbps, unlike the $30 RealJukebox Plus, which lets you encode at CD quality. This is, of course, an incredibly common practice in the closed source world, and even in the closed/open hybrid world (eg. Sendmail vs. Sendmail Pro). Essentially, it's an advertisement, a test drive--you get to see how the product behaves, in the hopes that you'll want to pay up for a version which is actually usable. Never once have I seen it used to condone a blatant and unagreed to violation of privacy, just because "you get what you paid for". Just because the majority of people stick with the free version is absolutely no excuse: I'm sure many more buy the plus version than would if there was no free version at all, and I'm sure Real agrees with me.
Besides...the Plus version still illegally violates your privacy without your consent, so the point is null anyways.
Doesn't RealPlayer's install program actually ask you if you want to send information to Real.com?
I know for a fact that there's an option to send "connection statistics" to the content provider. Isn't this what the hoo-ha is all about? Seems a bit silly that people are consenting to send in information about what they're watching/listening and then bitch about it happening.
This post is offtopic, guys. This story is not about RealPlayer. It is about RealJukebox. I realize lots of you are confused because they only thing Real makes for Linux is RealPlayer, but that's not what we're talking about.
RealJukebox is an mp3/CD player/ripper for Windows. That is, it's like Winamp (but it also rips). It is not used to play content from the internet, and there is no reason for it to compile "connection statistics" or any such thing. The big deal here is, it is sending information on mp3s you are playing off of your own hard drive, CD's you are playing from your own CD drive, and, presumably, mp3s you are making from your own CD's. The information they are taking from you is of absolutely no use in improving their product; the most benign possible interpretation of it is that they are using it to market information in aggregate. However, the fact that their privacy policy and EULA (neither of which mention this logging) have been revealed to be blatant lies tends to make me not believe the most benign interpretation.
In any case, in absolutely no way is the user asked or informed about this. The best they can do is refuse to register (which they are not informed is an option) so that the information logged on them can only be tied to an IP address, not an email address and name. Oh wait--no, that's not true either, as you have to input an email address and name before you download the software.
This is scary, folks. If you don't think it is, it's because you don't know the facts.
There is a difference between failing to mention something and keeping something a secret. Unfortunately, most privacy activists fail to realize this difference, and so it becomes the custom to assume that whenever somebody fails to mention something, it automatically means they are attempting to keep it a secret.
Yes, there is a difference. However, considering that Real has a privacy statement on their page--a long, legal document which for talks in great detail about how they gather personal information when you resister their products, and the use of GUIDs when you request realvideo content from their servers, but very noticably and egregiously does NOT mention the fact that they log every CD and mp3 you play from your own computer--we can pretty easily conclude that this is a deliberate secret. Now, IANAL, but I'm pretty sure that any time a company puts a legal document like a privacy policy up for public perusal, it can legally be considered to imply that it is reasonably complete. The fact that they ommitted the teensy weensy fact that they log every action you preform every time you use their software seems like a clear cut case of deception to me.
The fact that they ommitted it from the license agreement you need to agree to when installing RealJukebox is even more clearly illegal.
As for anyone wondering why this information could possibly be so dangerous...consider the recording industry's probable response to the mp3 revolution: watermarking. For those who don't know, watermarking is a plan to put a little electronic signature (don't worry; it won't interfere with the music quality *too* much) in every song a record label wants to sell digitally. That way, the story goes, the record labels could track the progress of these songs as they get illegally copied and passed around, and can sue people who put them up for free download, or some such thing. Point is, it was a pretty flimsy story, and it certainly didn't threaten the average user who just played mp3s off his or her local drive...until now.
I'm sure, Fastolfe, this qualifies me as a paranoid delusional, but has anyone considered the possibilities when you combine software which reads watermarks (which future versions of RealJukebox will if they don't already, pretty much by definition), software which compiles registered information (your name, address, and email) and assigns you a GUID, and software which secretly (or maybe it just does it "without telling you about it; there's a difference") sends all pertinent information about the mp3s you're playing...
Yep, that's right: suddenly, if they want to (that is, if they pay Realnetworks enough money), any record label can obtain a list--names, emails, and addresses--of a substantial fraction of those people who have pirated mp3s on their hard drives.
Wow.
Damn. And the fact that their site is signed off by Truste makes it even worse. All of this makes me want to vomit. Oh well; at least I never used the damn thing cause it stayed resident in memory and crashed all the time. In any case, that sucker's uninstalled for good.
Yep, should have said more pipelined instead of more superscalar, but I was right that having a deeper pipeline means it's easier to fab high clock speed parts. And that the reason the K6 was so damn hard to fab is that its pipeline is only 6 stages deep.
And I really swear that I meant to say that a GPU takes a good deal of the advantage off of the Athlon's awesome floating point for the average user. There are, of course, lots of uses for an FPU that have nothing to do with transforming and lighting polygons. However, the average Joe buying an Athlon is mostly interested in using its FPU to play some Quake3, and I'd bet that 90% of the unaverage Janes left over who'd buy an Athlon for a different reason just want 3D Studio to render faster; a GeForce would take most of the load off of the Athlon's FPU in both cases, especially the latter.
I have to say, I really just don't get the PC hardware industry. That is to say, in my heart of hearts, I have close to no doubt that Intel seriously pressured all the mobo manufacturers not to make/market Athlon boards, and, gross as that is, I of course understand it.
What I don't get is, if that indeed happened, why has none of them just come out and said so? Honestly, this isn't as stupid as it looks. Let's count the reasons why not:
1. The Athlon is a superior product. Yes, a 133MHz bus Coppermine on an i820 mobo is just about at parity as far as performance/MHz goes. (Benchmarks I've seen--a lot of sites had prerelease i820s they used for testing (with only 2 RIMM slots filled of course)--put the CMines faster at office type stuff, the Athlons whipping up on FPU benchmarks and rendering type stuff, and the two about even on Q3ish stuff, which at this point is not yet optimized for the Athlons new FPU pipeline and expanded 3DNow set.) But the only reason AMD's pausing at 700 or 750 MHz for now is because they're ramping up their.18u copper (i.e. like the metal) parts. From what I've heard, they'll hit 1 GHz about 2 months faster than Intel (I read that AMD'll prolly get there in 2/00, Intel in 4/00), and the gap should only grow. After all, unless you believe the Register that Intel's gonna launch Willamette in December (Note: Are they nuts?!?! On second thought, this wouldn't be the first time the Register has inexplicably been unable to understand the difference between taping out and being available from Dell...) then you have to accept the fact that Intel will be stuck with an amazing-for-its-time (remember, Coppermines have the same core as a PPro from way back in 1995) but still less scalable, not to mention not copper, core until probably next fall. Point is, it's a pretty safe bet that the Athlon will be the faster chip for the next 9 months. And even safer that it'll be better price/performance.
2. People know this. Certainly if there are enough people who know what they're doing and want speed for mobo manufacturers to build high quality boards specially for overclocking, and even dual Celeron boards, then there's more than enough market to justify making Athlon boards.
3. AMD is not having any production problems. While this may surprise the ignorant among us who just assumed that AMD was a bunch of blubbering idiots for not being able to keep the K6's up to MHz with PIIs, it's really no surprise at all. See, the K6 design just wasn't very superscalar. For those who don't know what that particular buzzword means, it refers to how many stages the pipeline is divided into. More stages means the processor does less things in each clock cycle, which means you can fit more cycles in a second. The downside is higher latency when a prediction misses, but as it turned out, branch prediction is good enough that deep pipelines/high MHz works better than low latency/low MHz. So anyways, the K6 designers guessed the wrong solution to that one, and ended up with a 6 stage pipeline in comparison to the P6's 13 (IIRC) stages. Hence, the fact that AMD was able to stay within one or two speed bins of Intel for all that time is actually a testament to the high quality of their manufacturing capabilities. As for that huge shortage this February...well, consider the fact that up until a couple months ago, AMD had exactly one fab, and a small one at that. Intel has eight. How much would you like to bet that, at one fab or another, Intel has problems just as severe as the AMD ones all the time, but you just never hear about it because they can shift production to another plant? Of course, now that AMD has a second fab, and, not only that, but a huge state of the art one, the all-eggs-in-one-basket problem is pretty much solved as well.
4. Intel has screwed the mobo manufacturers over big time. This i820 thing is a huge huge huge debacle, and it's all Intel's fault. Furthermore, no one in the industry can be happy that Intel insisted on switching over to RDRAM well before its time, either. Fact is, with proper economies of scale (that is, if the mobo manufacturers would just make the damn things), an Athlon motherboard and RAM could sell for about half the price of an i820 with RDRAM. Why anyone would be scared of burning bridges with Intel after what Intel's just done to them is beyond me.
5. Intel's under major antitrust scrutiny. I mean, if they were bullying mobo companies into shelving, overpricing, or undermarketing their Athlon boards, why on earth wouldn't one of them just pick up the phone and call the FTC? Or better yet, The Wall Street Journal?? And yet they appear to think they're in a better bargaining position if they just keep it to themselves and maybe grumble off a few anonymous leaks to hardware fan sites on the web?? Huh???
So what's going on here? I honestly don't know. On paper, and in the benchmark labs, and on the roadmaps, AMD has Intel blown out of the water for quite some time. On the one hand, it happens to be true that the recent trend toward graphics cards with GPUs takes a good deal of the advantage off of the Athlon's superior floating point performance, but you'd be pretty hard pressed to say that, from a theoretical perspective, things look anything but shitty for Intel. Except that, possibly due to nothing more than some well placed, and presumably illegal, intimidation (and not just directed at the mobo people; witness Dell and Gateway, the sort of names average people think of when they think of fast high quality computers, not offering any Athlon systems), things look just fine for them.
It's a pretty scary thought that this sort of thing could still go on right after the MS trial. But I just don't have any other explanation.
Sorry for the long post; I've got lots to say about this.
Hmm. First off, of course this is old news, although most people haven't heard about it yet. I first learned about the issue in a pretty fascinating article in the NYT Magazine ~2 years ago; also, Slate had one of those little dialogue thingies about a year ago between (IIRC) Erlich and I think the guy who wrote the NYTM article. As usual for debates when at least one of the participants is a total nutcase who believes his entire credibility rests on never admitting he was wrong (I'll let y'all figure out who that was here), the dialogue ended like a particularly vicious vi vs. Emacs spat, but it was pretty informative nonetheless. In any case, NYT and Slate both give free access to current content but charge for a look at their archives, so no links here. (Note: if that isn't the most absurd internet business model I've ever heard of...but I digress.)
Just for some base understanding on the numbers here, the replacement fertility rate for a population is generally taken to be 2.1 children/woman of childbirthing age (the extra.1 is to take care of all the kids who die before they reach adulthood and can reproduce). Here in the US, we're just below that--about 2.05 kids/woman--and once you take immigration into account, our population is expected to be slowly growing for quite a while. In much of western europe, though, it's already quite a bit different. In most of the Scandanavian countries, as well as France and Germany, they're already down to about 1.4/woman. Same thing in Japan. In Italy, it's an astonishing 1.2--elementary schools are closing all over the country; in some towns, there are more residents over the age of 85 than under the age of 6. China and Russia each have similar fertility numbers (both about 1.4/woman), although each represents a very different situation. In China, of course, the low numbers are probably overall a very good thing: the social problems they've run into because of their restrictive fertility policies (mainly things like, it's lonely not to have any siblings, aunts and uncles, or cousins) obviously don't compare to not having enough to eat. In Russia these days, everything demographic is a bad thing. Not only do they have low fertility rates, but the average life expectancy for Russian males has dropped to something like 63 years. The end result is that Russia's population is actually crashing now, as opposed to countries with low birth rates, where the implosion, if it comes, won't be until the baby boom generation starts dying in serious numbers--prolly around 2020 or so.
Anyways, the second point (which, btw, even Erlich conceded eventually) is that the "most likely" UN demographic scenario referred to by J--actually, even the UN only calls it the "middle variant" scenario, and makes no claims as to its validity--is complete bunk. Essentially, it comes about by assuming that, starting right now, today, the fertility rates in every single country around the world will magically (and linearly!) begin to converge to 2.1, which they will hit in the year 2050, and then stay there, with a world population of ~8.5 billion, forever. Obviously, that's a ridiculous assumption. Indeed, the low variant figures cited in the linked article are by far the best guesses we have. They don't assume any miraculous changes in the modern lifestyle of people in developed countries that would spontaneously raise the fertility rate up to a sustaining number, and they don't assume that the uneven but precipitous decline in third world fertility rates will magically stop at the 2.1 mark either.
Of course, they're still almost completely worthless. The thing is, we have very little idea as to what causes mass cultural phenomena like prevailing birth rates. Take the exact opposite event: the Baby Boom. At the height of the 18-year long Baby Boom in the US, fertility rates were something like 3.6. (Compare this to the notoriously out of control demographics of India today: fertility rate 3.7.) Then, in a matter of a couple years around 1963 or so, it all stopped. Now the obvious questions are a) why did it happen, and b) why did it stop. Problem is, we don't really know the answer to either of them.
The prevailing notion seems to be that the Baby Boom happened because times were economically good, and people felt economically secure. This is demonstrably an insufficient condition--after all, fertility rates in the other two economic booms of the century--the 20's and the 90's--have been lower than normal. And the idea that today's economic upturn is somehow "less secure" than previous ones simply isn't supported by, for example, polls in which people overwhelmingly say that they feel economically secure.
Now, what did happen in the Baby Boom that was completely different from what's happening in developing nations today is that the culture at large strongly supported the idea that women should marry early, stay at home, and raise children. Then came feminism. While it's not really true to say that we know what stopped the Baby Boom--indeed, the feminist movement was concurrent with the Baby Bust at best (The Feminine Mystique wasn't published until 1963)--it seems like a pretty good bet that the gains of feminism are by now too firmly entrenched to allow a return to the days when women went to college, if at all, to find husbands, married at 20, and stayed at home to have 4 or 5 kids.
As the article points out, this will probably lead to some pretty severe social problems down the road. For example, if instead of being News for Nerds,/. were, say, News for Construction Workers, well, the reaction to this news might be a little more concerned. After all, a declining population means there's no need for new houses.
Of course, it's not just housing construction that'll be hurt by this. As the article pointed out, dropping birth rates and increasing life expectancies lead to inevitable problems paying for Social Security. Now, as it turns out, this is a bit of a false issue here--the real cause of the Social Security crisis set to hit in about 2030 that we've been hearing so much about isn't so much the low birth rates of today as the extraordinarily high birth rates of the Baby Boom; in other words, assuming fertility rates in the developed world do remain at their current low levels, we'll still only have to go through one Social Security crunch. Still, it's worth noting that, depending on the performance of the economy over the next 30 years (and that's a big depending: for example, if you raise the projected annual GDP growth for the next 30 years by just.1% over current guesses, the Social Security shortfall disappears completely. Of course, if you lower it by.1%, the shortfall doubles), we could be in for a lot of trouble once the Baby Boomers retire. And the situation will be considerably worse in places like Japan, France and Italy--all three have more generous welfare stats than the US, and all three have a considerably greater demographic gap looming.
Furthermore, disregarding all the money taken out of the economy to pay for Social Security, let's not forget all the money that doesn't go into the economy because of a shortage of workers and young consumers. Not that the poor economic performance of the 70's can at all be traced to one root cause, but it's worth noting that the decline hit in 1973--10 years after the Baby Bust--and lasted until 1982. That is to say, for 38 years after WWII, there was a huge supply of young people acting as both consumers and labor, and the economy steadily grew. Then, that supply of young people dried up...and the economy suddenly stagnated. Worth noting.
Furthermore, for an issue closer to home with most of us here, it's worth considering that most of the great ideas that we all care about come from young people. An old society is probably doomed to not be a technologically innovative one.
Of course, most of the debate so far has been centered on the idea that, since overpopulation in the developing world is a problem, there couldn't possibly be anything wrong with underpopulation. And to be fair, that's sort of due to the tone taken by the article: I, for one, find something very disturbing at the least in the author's implicit notion that the fact that brown people will outnumber us great civilized white people by an even greater margin in 50 years than they do now is necessarily cause for alarm. Still, we have to consider the ideas that a) the fertility rates of the developing world today are no greater than the fertility rates in the west when it was still developing; in fact they're considerably lower; and b) they're dropping very very rapidly.
Now, the fact that they're dropping very rapidly is a very good thing. Some of the causes of the drop--increased industrialization; increased access to health care and birth control; increased life expectancy; increased education for women--are very very good things. But there's no reason why the decline in fertility rates in the third world won't continue until they, too, are below replacement rates. And if any countries need an infusion of young labor and consumers to stimulate their economies, it's developing nations.
Of course, this is not to say that depopulation isn't better than the alternative. Our natural resources are running out, for example: oil reserves are constantly overestimated by oil producing nations, in a futile arms race to get a larger percentage of OPEC quotas for themselves; an article I read in SciAm about a year ago estimated that we'll be out of easy-to-find oil by 2010. But underpopulation still has many attendant problems, both economic and social. I know I, for one, wouldn't want to have grown up without siblings or cousins, and with very few people my age in general. And, furthermore, that I wouldn't want the few friends my age to be spoiled rotten only children of rich parents who spent too much time working to give their kid any parenting except for expensive toys...
Hmm. Sorry if that was a bit disjointed and lengthy. Anyways, just my seven cents or so...
No problem. Frankly, the only reason I came down on you so hard was that I've really grown to like some of the stuff over at ars, and find Hannibal's architecture articles particularly informative, detailed and, most importantly, written well enough for the layman to understand. In fact, they're part of the reason I'm only a mostly-layman these days.
Oh, and because I find/. gets a bit too civil these days; shaking things up when you're pretty convinced you're right is always fun.;)
As for RISC being a true innovation, and not at all obvious at the time: yes, you're absolutely right. It's only in hindsight and with the story smoothed out a bit that we realize that the environment which made "CISC" processors a good design had ceased to exist by the 80's. I don't want to take anything away from the original designers of the RISC philosophy; but still, I very much agree with Hannibal's thesis that that debate has just about nothing to do with the merits of today's CPUs.
Urg. Sorry, but I'm just gonna repost the comment I made about a week ago when some other wierdo spouted the same ignorant blather.
Oh wait: it wasn't just any wierdo. Believe it or not, it was you, Millennium. Perhaps you could read what people respond to your comments. After all, saying something incorrect once just makes you look uninformed; saying the same thing after you've been publicly corrected makes you look willfully stupid...
--begin repost--
They're already at price/performance parity, more or less. The G4 is roughly triple the speed of a P3, and this is using Intel's own benchmarks, mind you. We're not talking Bytemarks here, boys and girls, we're talking benchmarks no one dares discredit.
Oh lord. Another one falls for the Apple FUD.
No, we're not talking Bytemarks here; this one, if you can believe it, is even worse. You see, at least Bytemarks is a benchmark. It's about 10 years old and has absolutely no bearing whatsoever on the performance of a modern CPU, but at least when they came up with it, someone was trying to get an idea of how fast a chip would run.
These 6 tests are not benchmarks, in any normal sense of the word. Benchmarks measure how long it takes for a computer to perform a real-world task. These tests (Apple's got 'em posted here; scroll to the bottom) measure the speed of individual ops.
That's right: the G4 performs 6 specific operations an average of 3 times faster than a P3. We're talking things with names like "1024 dim. DotProd" and "256 Pt. Complex FFT". The G4 can take a dot product 3.68 times faster than a P3. Oh wait--not even that; a dot product in a specific dimension. Whoopdee. A 128-bit unit can do operations on very large numbers faster than a 32-bit one. Wow. This is like posting the fact that a 64-bit CPU can add two 64-bit numbers faster than a 32-bit one. Who would have thought.
And yes, these benchmarks were "published on Intel's own website." Of course they were. In the technical specs on the SSE core. Deep in the technical specs on the SSE core. Where information that is completely useless to anyone not planning on optimizing a compiler belongs.
Essentially, this benchmark is as misleading as quoting MFLOPS (oh yeah: Apple stooped to that one too...). Except that usually when you quote MFLOPS you at least generally need to average over the entire set of floating point ops. Not here folks. They picked out their favorite 6.
Oh wait--here's another difference: when you quote MFLOPS, you actually need to, uh, benchmark the thing. These numbers are all theoretical--just compare the number of clock cycles it takes to do an operation, and multiply by MHz. Now, it turns out they'd probably be even more in the G4's favor in practice--if I remember correctly, the AltiVec unit has a much better designed pipeline than the P3's SSE unit. But still, these numbers are absolutely, completely, worthless.
I don't have the URL offhand, but I've seen the Intel page they copied these tests from, and there were literally hundreds for them to choose from.
The point is, you can always find an operation that is carried out in less clock cycles on one particular archicture as compared to another. Always. Now it turns out that, in this case, the AltiVec apparently really is vastly superior for the sorts of things it does when compared to Intel's SSE or AMD's 3DNow. (Of course, it also takes up half the chip. Any guesses as to why they can't fab any 500's??)
However, the fact is that except for very specific applications (SETI@home in particular, and some signal processing stuff, IIRC), it doesn't make all too much of a difference. A 700 MHz Athlon will smoke a G4 450 or 500 or whatever on your basic integer stuff, and a 600 MHz P3'll be right up there with it. For the stuff that can be done with AltiVec, the G4'll certainly come out ahead, but for general floating point work, again, they're about equal. It goes without saying that, at this point, nothing crunches graphics like a year-old PC with an NVIDIA GeForce in it (except maybe something from sgi)--which, of course, is about the only thing the average user needs good float performance for anyways.
In the end, the G4 is just a decent chip with a neat vector processor that's proving hard to fab. Is it damn fast? Yes. Is your new G4 450 going to touch the Coppermine P3 733 that's shipping by the time yours actually ships? Nope. Is it "two or three years ahead of its time" like Stevie says? No way.
-Dave
P.S. And yes, you can sell them to China as well. As much as I want to like Apple these days (a simplified vertically integrated product line is a very good idea in many cases; OS X just might be incredible; and geez--did you check out the new iMac subwoofer??), the fact that every single word out of their marketing department/CEO's lips is a baldfaced lie...gives me pause.
Now let's see. Why is it that the author of this article is so "clueless", as you say?
When the first RISC machines came out, superscalar execution hadn't been invented yet.
Some processors (Cray for one) had been doing this years before RISC came out.
Unfortunately, the actual quotation from the article is "When the first RISC machines came out, Seymore Cray was the only one really doing superscalar execution." Whoops. Looks like ya' dropped the ball on that one.
I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling
Well, that's very forward thinking of you. Of course, I guess that makes you clueless as well, because, once again, it's exactly what the author of the article wrote: "VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP. Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software."
So this leaves us with your remaining "point":
The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.
Well that's a brilliant insight you've uncovered there (covered in the article here), but the point of this "clueless" article (which you obviously did not read) was that there no longer is a debate. The term RISC refers to a CPU design philosophy which was invented in 1981. That was 18 years ago. It was intended as a replacement to "CISC", the CPU design philosophy which came about in the early 70's.
That is to say, the CPUs of today, whether P6 or PA-RISC or G4, and the systems that they are in, bear almost no resemblence whatsoever to either a "CISC" chip or a RISC chip. The only similarity is that the P6's and K7's of the world are compatible with the x86 ISA, which was originally written (back in 1977 IIRC) for a "CISC" chip. Yes, this adds an extra decoding step (to break down instructions into "RISC-like" ops), and yes, theoretically that means increased die-size and complexity, which of course means lower clock speeds. Oh wait--that reminds me: which currently shipping chip has the fastest clock speed?? Oh yeah--the 700MHz Athlon. With a 750 part set to be shipped later this week. And, looks like, a 900 in time for New Year's. One of those ungainly "CISC" chips, huh.
Hmm...but let's take a look at how all those competing "RISC" chips have used their incredibly simple architectures to keep die size down. Like the PA-RISC, which is, IIRC, about 6 or 7 times the size of a PIII. Or those new G4's, with their impressive yield of 0% at 500MHz. The simplicity of today's modern "RISC" chips in action.
Now, none of this is to say that the G4 or the PA or whathaveyou isn't a great design. Just that the resemblence of today's CPU's to a true "CISC" or RISC chip is so tangential as to make the categorization meaningless. And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time. By 1981, the state-of-the-art had advanced to the point where RISC was a better solution. Duh.
Since then, compilers have gotten better, transistor densities have increased, and RAM prices have plummetted, allowing all the advancements which the author termed "post-RISC". And, looking at the CPU's of tomorrow, we see all sorts of new techniques on the horizon: optimization based on advancements in compiler/software technology, ala IA-64, MAJC, and (apparently) Transmeta; or optimizations based on incresing transistor densities, like some of the new physical parallelization designs that appear to be a couple generations down the road for Alphas and IBM chips.
But as long as people like you insist on categorizing these chips into meaningless 20-year design philosophies, the tech world will be a more ignorant place.
They're already at price/performance parity, more or less. The G4 is roughly triple the speed of a P3, and this is using Intel's own benchmarks, mind you. We're not talking Bytemarks here, boys and girls, we're talking benchmarks no one dares discredit.
Oh lord. Another one falls for the Apple FUD.
No, we're not talking Bytemarks here; this one, if you can believe it, is even worse. You see, at least Bytemarks is a benchmark. It's about 10 years old and has absolutely no bearing whatsoever on the performance of a modern CPU, but at least when they came up with it, someone was trying to get an idea of how fast a chip would run.
These 6 tests are not benchmarks, in any normal sense of the word. Benchmarks measure how long it takes for a computer to perform a real-world task. These tests (Apple's got 'em posted here; scroll to the bottom) measure the speed of individual ops.
That's right: the G4 performs 6 specific operations an average of 3 times faster than a P3. We're talking things with names like "1024 dim. DotProd" and "256 Pt. Complex FFT". The G4 can take a dot product 3.68 times faster than a P3. Oh wait--not even that; a dot product in a specific dimension. Whoopdee. A 128-bit unit can do operations on very large numbers faster than a 32-bit one. Wow. This is like posting the fact that a 64-bit CPU can add two 64-bit numbers faster than a 32-bit one. Who would have thought.
And yes, these benchmarks were "published on Intel's own website." Of course they were. In the technical specs on the SSE core. Deep in the technical specs on the SSE core. Where information that is completely useless to anyone not planning on optimizing a compiler belongs.
Essentially, this benchmark is as misleading as quoting MFLOPS (oh yeah: Apple stooped to that one too...). Except that usually when you quote MFLOPS you at least generally need to average over the entire set of floating point ops. Not here folks. They picked out their favorite 6.
Oh wait--here's another difference: when you quote MFLOPS, you actually need to, uh, benchmark the thing. These numbers are all theoretical--just compare the number of clock cycles it takes to do an operation, and multiply by MHz. Now, it turns out they'd probably be even more in the G4's favor in practice--if I remember correctly, the AltiVec unit has a much better designed pipeline than the P3's SSE unit. But still, these numbers are absolutely, completely, worthless.
I don't have the URL offhand, but I've seen the Intel page they copied these tests from, and there were literally hundreds for them to choose from.
The point is, you can always find an operation that is carried out in less clock cycles on one particular archicture as compared to another. Always. Now it turns out that, in this case, the AltiVec apparently really is vastly superior for the sorts of things it does when compared to Intel's SSE or AMD's 3DNow. (Of course, it also takes up half the chip. Any guesses as to why they can't fab any 500's??)
However, the fact is that except for very specific applications (SETI@home in particular, and some signal processing stuff, IIRC), it doesn't make all too much of a difference. A 700 MHz Athlon will smoke a G4 450 or 500 or whatever on your basic integer stuff, and a 600 MHz P3'll be right up there with it. For the stuff that can be done with AltiVec, the G4'll certainly come out ahead, but for general floating point work, again, they're about equal. It goes without saying that, at this point, nothing crunches graphics like a year-old PC with an NVIDIA GeForce in it (except maybe something from sgi)--which, of course, is about the only thing the average user needs good float performance for anyways.
In the end, the G4 is just a decent chip with a neat vector processor that's proving hard to fab. Is it damn fast? Yes. Is your new G4 450 going to touch the Coppermine P3 733 that's shipping by the time yours actually ships? Nope. Is it "two or three years ahead of its time" like Stevie says? No way.
-Dave
P.S. And yes, you can sell them to China as well. As much as I want to like Apple these days (a simplified vertically integrated product line is a very good idea in many cases; OS X just might be incredible; and geez--did you check out the new iMac subwoofer??), the fact that every single word out of their marketing department/CEO's lips is a baldfaced lie...gives me pause.
No, it's not true. Email to AOL can not run scripts. The procedure Moravik describes is exactly correct. Indeed, unlike a program like Outlook--which still requires the user to expressly click on an attachment to run it--AOL makes you actually save it to your HD, find it, and double-click on it. Furthermore, it pops up an annoying little message about how you should never run code you don't trust, every single time you download an attachment. And finally, if someone in the family is too stupid to figure all this out, you can prevent their screen name from recieving email attachments altogether (assuming the person with the master account knows enough to do that).
The point is, AOL's email attachment model is too strict, IMO. It's just downright annoying and inefficient. And, it seems to me, adding all these extra steps isn't going to stop anyone from running an attachment that they were going to run otherwise...although I suppose the big red warning is a nice feature for newbies.
As always, once you hook it up to the big bad internet, your computer is only as secure as your knowledge of security issues. And AOL does as good a job of pointing these issues out as can really be expected.
In the press on this topic, Compaq was quoted as saying that only 5% of their Alphas went out as NT systems.
Actually, the figure I saw was 2%.
Furthermore, MS is still using Alpha as the development system for 64-bit W2k; they just apparently won't be polishing it, marketing it, etc.
Now, this seems pretty darn stupid of Compaq to me to discontinue plans to market 64-bit NT. Yeah, yeah, 2%--why bother, right? Thing is, that 2% refers to running a 32-bit OS on a 64-bit CPU. If you were going to the expense of buying an Alpha, why hinder it with an OS that doesn't take advantage of its architecture? Hence the 2% figure makes a lot of sense.
But now that Intel is coming out with a 64-bit chip, well, Microsoft decides that's important enough to warrant a 64-bit OS...and this is the time Compaq chooses to pull the plug on Alpha NT?? Huh???
Especially since, according to all reports, by the time Merced is finally released (Q2 next year? Q3??), the Alpha's going to be walloping it. By the middle of next year, the roadmaps I've seen have the 21264's hitting well over a GHz...I think I've even seen 1.4 tossed around (but it was prolly at The Register, so, grain of salt). More importantly, benchmark roadmaps (these, I remember, were leaked from Compaq, so more salt) have a 1GHz Alpha beating an 800MHz Merced by ~40-50% (SPECint, IIRC).
So what's up???
Two theories. Wait, make that three (er, four):
1. Compaq's stated reason: they want to revitalize Tru64, and support Linux. Plus, no demand for NT Alpha. Possible...but I dunno. Tru64 seems to be a losing battle as a long term strategy; it's faster than Linux on Alphas now, but a few years down the road?? Seems smarter to go the sgi route, let your proprietary UNIX die, and let Linux sell your boxes. As for the lack of demand for 32-bit Alpha, see above. I think once it was 64-bit, people would buy. An appropriately high end Alpha box'd kick the hell out of an 8-way Xeon box on NT, and prolly a 16-Athlon as well.
2. Merced NT doesn't have much in common with Alpha NT, so MS doesn't want to spend time on it. Here, I pretty much have little idea what I'm talking about, but it would make sense to me if programming for a VLIW chip is just too different from programming for anything else. Cause VLIW is waaay different--far more different from existing architectures than CISC is from RISC, at least the way "CISC" and "RISC" chips are made these days. So perhaps the whole, "we're making a 64-bit OS anyways, why not port to Alpha?" idea doesn't actually work. On the other hand, most VLIW issues seem to occur in the compiler...and they're still using Alpha as the development chip for 64-bit W2k. So...
3. Maybe Merced'll be faster than we thought. This is my conspiracy theory of the day, and you have to understand that I've been pretty disappointed by Intel tech lately, so it's taking quite a bit for me to say this. But still...I mean, even if they didn't count on selling many Alphas for NT, don't you think Compaq would love to be able to claim how their much cheaper (and they will be) Alphas kicked the tar out of those new Merceds in a fair fight with the same OS?? (Note: yeah, it wouldn't actually be fair...but it'd sure look that way.) So either Compaq got wind of the fact that Merced won't be slower after all...or perhaps they realized MS wouldn't do what it takes to make the 64-bit Alpha W2k compete with the Merced W2k...or perhaps...
4! Intel paid 'em off!! Ok, this is too fun to pass up. Essentially this goes like, Intel's just spent, what, 3 or 4 years now on a laughingstock of an overpriced chip (yes, I have no doubt that eventually IA64 will be amazing...but not on Merced), and they desperately want to avoid any controlled comparisons. So they politely ask Compaq and MS to stop development on 64-bit NT for Alpha. Besides, Compaq'll be selling their share of Merced boxes, so they've got as much to lose as anyone.
Yes, it was pretty damned stupid. But no, it wasn't just reading headers.
The message was sent from an anonymous account at Yahoo. Now, this was incredibly dumb--what "owner of Bucking Consulting, a software consulting firm" would send mail from a free account?--but the headers still don't say anything about microsoft in them. However, they do contain the originating IP address, which was traced back to MS.
"The one computer security expert who could trace it back to Microsoft"? Not quite. But it wasn't as absurdly obvious as you might think.
Re:But NumLock needs to be off for the arrow keys
on
Changing the Keyboard
·
· Score: 1
Some computers boot with NumLock on, some with it off. This is usually selectable in the BIOS...
Actually, it goes something like this: (Only "something like," because the details of what exactly the Scientific Method is and how it works are still a matter of much philosophical debate. But rest assured, nobody thinks it's what they tought you in 5th grade anymore.)
A hypothesis is an educated guess about the results of an experiment to be preformed. The experiment should be designed to, as much as is possible, either confirm or refute the hypothesis (and only the hypothesis).
A theory is something rather different. A theory is an explanation for a group of related phenomena--for a subset of reality, if you will. A theory is judged to be successful if it is a compelling explanation: generally, if it makes sense logically, explains the way reality is--both from normal observation and from the observation of controlled experiments--better than any previous theory, is not contradicted by any observations of reality, and is the simplest it can possibly be and still accomplish the above.
Contrary to what you probably learned in school, real scientists don't go around doing lots and lots of experiments, or even worse, just making lots and lots of uncontrolled observations, and then coming up with a theory. They come up with a theory because they think the existing one isn't compelling enough--sometimes, because new evidence contradicts it, but most times because they find its explanation unsatisfactory. (Well, most times it's a combination of the two--the old theory is usually stretched to try to accomodate the new evidence, to the point where its explanatory powers are no longer any good.)
And no, it's not true that "the more times an experiment verifies a theory, the more likely it's true." I can drop an apple on my head a million times, and it won't make Newtonian gravity any more likely to be true. Furthermore, if you have no explanation for why the apple keeps hitting you on the head, it doesn't make it any more likely that the same thing will happen the million-and-first time you drop the apple.
That's why if you just think of a science as a sort of compliation of observations, and not as an attempt at a coherent explanation of reality--like, incidentally, the creationist "scientists" often tend to--then the fact that no one's ever witnessed, say, a fish evolving into a frog becomes a big argument against evolution. Luckily, that's not how science works. Remember, the big deal about Newton wasn't that he noticed that apples hit the ground when they detach from trees (safe guess that most people notice that), nor that they accelerate at a constant rate on the way down(that was Galileo)...but that the reason it falls is the same reason that the planets go around the sun. Similarly, when the church tried Galileo for saying, well, that the planets went around the sun, they didn't dispute that his observations fit such a theory. Instead, they told him, why can't you just say that the planets actually go around the earth, but that God made them go around the earth all funny so that it looked *just like* they were actually going around the sun. He, of course, said nope, because science isn't about observations, it's about...compelling explanations.
Phew.
Ok, so finally (this is long enough without going into the math stuff), a law isn't just a theory which gets supported over and over. In fact, just about every law we have, we now know to be just approximations--none, that I can think of, are still thought to be strictly correct. Nope, a law is a theory which explains a relatively broad subset of reality, and most importantly, does it very tersely--generally in a sentence or two. Thus, F=MA or every action produces an equal and opposite reaction, those are laws. Quantum theory, despite being arguably as important, will never be a law, cause you can't sum it up like that.
Perhaps, how about the G4?
on
Athlon Reviews
·
· Score: 1
As has been pointed out, the "Pentium Toaster" ads only used the Bytemark benchmark, which is extraordinarily old and has very little relevance to the sorts of things CPUs do these days. For one thing, it includes no floating point tests at all, IIRC--and these days, most things the average user (i.e. no compiling) runs into that'll tax his/her CPU are floating point dependant. And furthermore, (also pointed out before), the MacOS hampers performance considerably. And if you want to do any sort of multitasking at all, it hampers it hilariously. Obscenely, even. Check out this article at the always impressive Ars Techinca for some ROFL confirmation. To be fair, this was benched before OS 8.6, which allows (gasp!) multithreading...but if I understand correctly, apps need to be rewritten to take advantage of it anyways.
As for real, cross-platform, general CPU benchmarks, there's pretty much only SPEC, limited as it is. Yes, to some degree it depends on issues of compilers, chipsets, RAM, etc. But it's good enough to at least be relevant.
Apparently, as far as SPEC95 goes, the G3 is about 14% faster/MHz than a P3 in SPECint, and about 9% slower/MHz than a P3 in SPECfp. Course, the G3 doesn't come anywhere near close to the P3 or K7 in MHz terms anyways.
And double of course, what really matters is app performance. Here, assuming one stays with the MacOS, we run into some serious problems. Essentially, ClarisWorks (now AppleWorks?) was way more optimized for Mac than PC (duh), and it showed. Photoshop is probably equally optimized for both--and no, contrary to what you've heard, it isn't necessarily faster on the Mac. Look a bit further in the Ars article above: turns out that while the Mac wins the Gaussian blur test w/64 megs RAM...it loses with 128 megs on a 100MB file...it loses on the lighting effects (FP intensive) tests...and, this is the big one, it takes 3 times longer to load the 100 MB TIFF in the first place. Woops. And as for, say, anything made by the Microsoft corporation, don't even bother: to say it's better optimized for PC is the understatement of the year. IIRC, MacOffice97 worked by just porting the relevant Win95 API's and keeping the program itself the same. MacOffice98 might be better...but not by too much.
Obviously, none of the above applies to K7 vs. P3 discussions--except, of course, for 3DNow(!) stuff, but by now most all video card drivers etc. are quite well optimized for 3DNow, and with AMD having the fastest chip on the market, that'll only improve. In any case, just read all the K7 reviews above, and you'll see that this thing doesn't just chew up the P3 in one or two CPU benchmarks...it whups it handily in just about everything. Synthetic benchmarks, Winstone, games, encoding, rendering, you name it. And this is before apps are optimized for it (new 3DNow instructions; 3-issue FPU unit, etc. all could benefit from optimizations).
[Note: from here on out, I'm pretty much talking out the ass of this page here on JC's News. Dunno how accurate it all is, but JC generally knows quite a bit about what he's talking about. And I've read some other stuff that backs him up.]
Now about the G4...well, it seems that the design goals of the G4 were to get SPECint 20 and SPECfp 20 @450MHz (I've heard this elsewhere, although I don't recall a mention of 450 specifically)--implying that it will run at around 450 on introduction. Now, the K7 at 600 beats both of those marks handily, and indeed if you assume, as JC does, that SPEC scales linearly (course it doesn't, but...) then the G4 is just a hair slower at SPECint (and exactly the same at 500MHz as the G3. Anyone else out there know if the G3 and G4 have exactly the same integer unit?), and a bit faster at SPECfp. Note that I'm not sure if he's using old guesses at the K7's SPEC marks, or real numbers...and I'm too lazy to figure it out right now.
Now, of course the target goals for the G4 were made back when they said it'd be coming out...well, by now. Instead it's going to ship in "Q3 1999"--where Q3 1999 is read, "January." So we can expect higher MHz on intro than 450.
Of course, by then, the Athlon'll be at 750 at least. Probably 850. Rumor has it 1GHz. We'll see. In any case, JC goes ahead and pits a projected G4-550 against a (projected?) K7-750...and guess what, the K7 is a hell of a lot faster.
On the *other* hand, the real wild card in all of this is the G4's AltiVec vector processing unit (for those who don't know, vector processing is the sort of thing Crays (used to?) use--very very good at many things that normal CPUs use floating point to do). On paper, it totally totally kicks ass. Like orders of magnitude faster than SSE/3DNow. And from what I hear, it'll be way easier to optimize for than SSE/3DNow, and waaaaaay easier than MMX (which required assembly programming)--i.e., it might just require a recompile with the "optimize for AltiVec" box checked.
On the other other hand, with the recent emphasis on nonupgradable machines (with comparitively poor 3D acceleration) in their consumer line, and a reported general lack of attention to gaming among Apple bigwigs (course, this was in some ZDnet story, so who knows if it's true), the amazing power of AltiVec might only end up being used in embedded DSP machines by Motorola and IBM.
On the fourth hand, if I had an iBook I could surf the internet while I was in the bathroom. Draw your own conclusions.
Xeon cache goes up to 2MB. And only on the 500MHz part and below.
The Xeon III 550 only ships with 512 kB, so far.
Of course, by the time those Athlons with up to 8MB L2 start shipping (prolly not until Q2--these will be on a copper.18u process, as will all K7's starting around Dec/Jan if all goes well), this will have changed. But the 2MB limit on Xeons stays, as far as I've heard...probably all the way up until Foster (the Xeon of Willamettes) comes out, oh, say, early 2001.
Of course, if Intel finds that its butt is being kicked around in the server market, they'll probably try to get bigger caches on the Xeons, too. The main reason against it is that it's damn hard to fab such a huuuuuuge cache and have it run fast enough (full clock speed for Xeons, and probably for the server Athlons too)--and it would be surprising that AMD would be that far ahead of Intel on a pure manufacturing issue.
[On the other hand, AMD will be able to crank out K7s at higher MHz than P3s, even with possibly worse fabs, because the K7 design is more superpipelined than the P3, especially in the FPU.]
It's not exactly the same subject but I was thinking that The Onion's recent ParentCorner on protecting our children from the horrors of internet porn might provide some helpful advice...
The Onion ParentCorner Presents
Protecting Your Kids From Inappropriate On-Line Material
The Internet is a valuable educational tool, but for parents, it can also be a nightmare. Here are some tips for keeping your kids away from sexually explicit web sites and other questionable on-line content.
Drape your computer in terrifying slaughterhouse entrails to make it unappealing to youngsters.
Go to the favorites file in your web browser. Retitle "Goat Porn" folder "Financial."
Young boys are understandably curious about Internet porn, but not if you patiently explain to them that women's vaginas have razor-sharp teeth that can bite off a child's hand.
Tape pages of The Bible securely over your child's eyes, ears and mouth, then double his daily butterchurn chore-hours.
Periodically check your family computer's log-on history for any pornographic sites not visited by yourself.
Make sure your child does not use the Internet after 9 p.m.
Do not allow your kids to become desensitized to violence. Beat them harder each day.
Glue storybook pictures to your computer's monitor. Tell your child that this is the Internet.
Ask yourself why, if you can't exercise even a moderate degree of control over your children, you bothered to have kids in the first place.
Write letter asking web site "Cock-Craving Asian Nympho-Teen Cum Sluts" to tone it down a bit.
Replace your children with responsible adults.
Provide your child with a detailed list of every web site he or she is not to visit.
Force your child to look at pornography for many hours straight until child begs, "No more!"
A good idea...but just to supplement it, you might want to know that "all the theaters with bad policy" is more or less those theaters who belong to NATO.
No, not that NATO, silly! The National Association of Theater Owners--apparently a really really big industry group which most any theater except perhaps little independants belongs to. It's not actually true that Clinton just made a speech blaming Columbine on The Matrix and asked theaters to card kids and beat them with little clubs. What really happened is he had his people tell NATO "enforce the R rating and beat kids with little clubs, or else Clinton will make a speech and complain." And NATO agreed. So then Clinton made a speech and said, "because The Matrix caused the Columbine tragedy, I'm happy to announce that NATO has decided to card kids and beat them with little clubs. I'm also pleased to announce that everyone buying a little club and beating children with it will qualify for a targeted tax break."
So while the theater manager is sorta to blame, you might want to go to the top. Figure out how, and write/call/fax/email NATO to complain. Yeah, legally this has absolutely nothing to do with the government...but w/c/f/e your Congresspeople and the President as well.
AND boycott NATO theaters. Just because the manager is following orders doesn't make it right...
It is d.net's official position that security through obscurity doesn't work to prevent this type of crack--sending back blocks without checking them--and I think they do actually believe that, especially since it's now been done several times. It's worth noting that they do have a scheme to check this sort of thing--i.e. sending a known positive to the suspected client and seeing if it returns a negative or not.
A couple things to note about this scheme:
1) Apparently at this point the key word here is suspected: they only test someone with suspicious activity (say, returning 800,000 blocks a day on a chip which will not be built for several years). Of course, other than the drop in rate, there's no reason I can see why they don't check on everyone every once in a while.
2) Many people have suggested a checking scheme based on hashing negative results--essentially sending some portion of the blocks out to two people and seeing if they get the "same" negative result. Nugget says that he realizes this is a better idea and will incorporate it into the next client.
Ok, fine. But I think the reason they haven't incorporated a hash check yet is not, as has been suggested, because they can't stand to lose any speed (people around here have been throwing around figures like 20%). If I understand all the issues correctly (a big if, but still), they only need to double check every, say, 1000 blocks or so in order to get a handle on most any cheating. After all, even someone who bothered running a "covert" hacked client--one that would report blocks fast, but not so fast as to arouse suspicion--would still report at least 1000 blocks a day. Double checking 1/1000 blocks would only slow things down by.1% but would deter anyone from not checking their blocks, IMO.
No, what I think d.net is more worried about is someone who cracks the client--or, as is, in their thinking (and I have to say mine too), more likely, modifies an open source client--to send out a negative when it gets the winning key, and notify the computer user instead. Then they just report the answer to RC5 themselves, and get $10,000 instead of $2000. d.net loses $2000--$2000 which, I would hope we all agree, they deserve--and some worthy charity loses $6000.
First off, the hash checking scheme wouldn't catch this, although the known positive scheme would (or might, depending on what exactly it means for them to send a known positive block, and how this differs from a winning block).
And second off, I hope I'm wrong, but I have this feeling that such an abuse would be much more widespread with an open source client.
As for the other drawbacks of open sourcing, there's the issue of reliability--how do you know someone's altered client isn't giving off incorrect results because they didn't understand the changes they made? Without checking of both kinds--known positive and hash--we'd never know. Hence open source means they have to double check results way more often than is necessary now.
There's the issue of rival servers to d.net popping up, taking d.net's share of the prize and making coordinating unchecked blocks more complicated.
And finally there's the best reason not to open source: it works fine already. Somebody here suggested that an open source client might find a better checking algorithm. Again, I'm not expert on RC5, but from my understanding of it, there is no better algorithm. After all, the specs to RC5 encryption are public domain, and have always been so. If a better algorithm does come along (very unlikely, but possible), it'll come from a mathmetician, not some random guy on/.
Yes, you can buy stocks in odd amounts (i.e. not multiples of 100, or sometimes multiples of 50 or 25 depending on the stock price). However, it's generally not a good idea.
The reason why is liquidity. It's easy to forget this, but every time you want to buy or sell some shares of stock, there needs to be somebody else willing to sell you or buy from you the same amount of shares. Since most of the world buys stock in multiples of 100, it's hard to find someone who will sell you, say, exactly 62 shares of something--and it will be even harder when you want to sell to find someone who wants to buy exactly 62 shares.
Now, of course, you're generally not the one who has to deal with this--your broker is. So in order to discourage you and to offset the greater effort involved in finding a buyer/seller, they charge you higher fees for trading odd lots than lots of 100. Plus, the fact that no one wants to buy/sell odd amounts of stock means that there's less supply/demand respectively--which means you inevitably pay more/get less.
Nor does it take into account the fact that Intel has chained itself to Rambus RAM for their upcoming Camino chipset, despite the fact that no one has thus far been able to manufacture it with any sort of decent yield, it's hideously expensive, and it's no faster than PC100 anyways.
Nor the fact that, while the Athlon should hit 1 GHz by early 1Q 00 or even before the end of this year, Intel's roadmap doesn't have the (slower at equiavalent MHz) P3 hitting 800 until 2Q 00.
Nor the fact that the Athlon's point to point SMP, eventually supporting upwards of 16 processors and up to 8 MB L2 cache, should cream the bus-limited SMP performance of the Xeon for servers and high end workstations.
Nor that Intel is stuck with the darn-good-for-its-time but already 3 year old (remember the Pentium Pro?) P6 core until Willamette debuts in (hopefully) Q3 next year.
Nor that Intel will have to deal with the considerable difficulties of moving to copper for Willamette (AMD got around it by liscensing their copper process from Motorola, who has spent a year working out the kinks).
Bottom line: if I were Intel, I wouldn't be too happy about anything to do with AMD.
Actually, it's not so funny. Friend of mine (my roommate actually) used the original Back Orifice to remote admin the network at the place he worked.
And why not? It's free, it does everything he wanted, and most importantly, it consumes very little resources compared to competing commercial products. And my friend got paid a bunch for 10 minutes a week of playing around with it from his dorm-room computer.
Question is, why can't I get a job like that?
Re:Pricing: K7-500, $324 up to $500 ?
on
Carmack on the K7
·
· Score: 1
Again, the prices to consumers will begin to approach the OEM's price/1000 once the supply can meet the demand. OEM's sell CPU's on Pricewatch only when they can get more for them than they can get building a system with them.
So, since the K7 just came out, and AMD is only selling a few thousand the first month, and there are more than a few thousand people who realize what a kickass chip it is and are willing to pay a premium for it, and because it makes them look cool to be the first to offer K7-based systems...most OEM's would rather take all the K7's they can get their hands on and put them in computers rather than sell them seperately.
Unless, of course, they can make a huge profit on them.
Now, once the number of K7's out there stops being numbered in the tens of thousands and starts being numbered in the millions, then OEM's will start having more than they need. So, they'll try to offload them--at a profit if they can, at a loss if they can't. Whether they can or not depends on what other people on Pricewatch are charging. The more OEM's with excess chips, the lower they have to charge...and the more the price resembles their cost from AMD.
Supply and demand.
How do we know AMD didn't secretly raise the price? Well, because, with several thousand OEM's in this country, perhaps one of them might have said something if they did.
The reason the Xeon costs so damn much is because it comes with (up to) 2MB of full-speed L2 cache. And while this helps the Xeon along on SPEC benchmarks a bit, where it really shines--and justifies the exorbitant price (somewhat)-- is in running large databases and such things. That's why the Xeon mainly shows up in...yep, database servers.
Now, the K7 will eventually come in configurations of up to 8 MB (!) of full-speed L2 cache...but for now their only selling them with 512k of half-speed L2 (same as a PIII). And since they didn't post exactly which kind of Xeon the K7 beat so handily, I'm guessing it was the version with a 512k L2 cache. Now, this is still impressive, since the cache is full-speed, and that should make a decent difference in SPEC scores...but let's remember that these Xeons sell for ~$930 (Pricewatch), not ~$3500 like their 2MB big brothers.
Of course, having said that, if you were thinking of spending $930 for a 512k Xeon, say, for a workstation or something, then hell yeah you'd be better off spending either $720 (Pricewatch again) for a K7 550, or $950 for a K7 600 (yep). And once K7's start getting onto the market in appreciable numbers (right now, they're being sucked up by OEMs as fast as they can be fabbed), the prices there will go way down--in general, the lowest price on Pricewatch is often very very close to the manufacturers price/1000. It's known as supply and demand, people.
Slashdot Mirror
very few things in life are free, and commercial software is not one of them
You're not the only person to have expressed this idea, but I figured I'd pick on you to correct it.
The idea that, just because something is closed source, if it's free you have to be giving up something--in this case, giving up a rather disturbing amount of your privacy without your consent--is ludicrous.
The reason RealJukebox is free is because it is a disabled demo. You can only encode mp3s at 96kbps, unlike the $30 RealJukebox Plus, which lets you encode at CD quality. This is, of course, an incredibly common practice in the closed source world, and even in the closed/open hybrid world (eg. Sendmail vs. Sendmail Pro). Essentially, it's an advertisement, a test drive--you get to see how the product behaves, in the hopes that you'll want to pay up for a version which is actually usable. Never once have I seen it used to condone a blatant and unagreed to violation of privacy, just because "you get what you paid for". Just because the majority of people stick with the free version is absolutely no excuse: I'm sure many more buy the plus version than would if there was no free version at all, and I'm sure Real agrees with me.
Besides...the Plus version still illegally violates your privacy without your consent, so the point is null anyways.
Doesn't RealPlayer's install program actually ask you if you want to send information to Real.com?
I know for a fact that there's an option to send "connection statistics" to the content provider. Isn't this what the hoo-ha is all about? Seems a bit silly that people are consenting to send in information about what they're watching/listening and then bitch about it happening.
This post is offtopic, guys. This story is not about RealPlayer. It is about RealJukebox. I realize lots of you are confused because they only thing Real makes for Linux is RealPlayer, but that's not what we're talking about.
RealJukebox is an mp3/CD player/ripper for Windows. That is, it's like Winamp (but it also rips). It is not used to play content from the internet, and there is no reason for it to compile "connection statistics" or any such thing. The big deal here is, it is sending information on mp3s you are playing off of your own hard drive, CD's you are playing from your own CD drive, and, presumably, mp3s you are making from your own CD's. The information they are taking from you is of absolutely no use in improving their product; the most benign possible interpretation of it is that they are using it to market information in aggregate. However, the fact that their privacy policy and EULA (neither of which mention this logging) have been revealed to be blatant lies tends to make me not believe the most benign interpretation.
In any case, in absolutely no way is the user asked or informed about this. The best they can do is refuse to register (which they are not informed is an option) so that the information logged on them can only be tied to an IP address, not an email address and name. Oh wait--no, that's not true either, as you have to input an email address and name before you download the software.
This is scary, folks. If you don't think it is, it's because you don't know the facts.
There is a difference between failing to mention something and keeping something a secret. Unfortunately, most privacy activists fail to realize this difference, and so it becomes the custom to assume that whenever somebody fails to mention something, it automatically means they are attempting to keep it a secret.
Yes, there is a difference. However, considering that Real has a privacy statement on their page--a long, legal document which for talks in great detail about how they gather personal information when you resister their products, and the use of GUIDs when you request realvideo content from their servers, but very noticably and egregiously does NOT mention the fact that they log every CD and mp3 you play from your own computer--we can pretty easily conclude that this is a deliberate secret. Now, IANAL, but I'm pretty sure that any time a company puts a legal document like a privacy policy up for public perusal, it can legally be considered to imply that it is reasonably complete. The fact that they ommitted the teensy weensy fact that they log every action you preform every time you use their software seems like a clear cut case of deception to me.
The fact that they ommitted it from the license agreement you need to agree to when installing RealJukebox is even more clearly illegal.
As for anyone wondering why this information could possibly be so dangerous...consider the recording industry's probable response to the mp3 revolution: watermarking. For those who don't know, watermarking is a plan to put a little electronic signature (don't worry; it won't interfere with the music quality *too* much) in every song a record label wants to sell digitally. That way, the story goes, the record labels could track the progress of these songs as they get illegally copied and passed around, and can sue people who put them up for free download, or some such thing. Point is, it was a pretty flimsy story, and it certainly didn't threaten the average user who just played mp3s off his or her local drive...until now.
I'm sure, Fastolfe, this qualifies me as a paranoid delusional, but has anyone considered the possibilities when you combine software which reads watermarks (which future versions of RealJukebox will if they don't already, pretty much by definition), software which compiles registered information (your name, address, and email) and assigns you a GUID, and software which secretly (or maybe it just does it "without telling you about it; there's a difference") sends all pertinent information about the mp3s you're playing...
Yep, that's right: suddenly, if they want to (that is, if they pay Realnetworks enough money), any record label can obtain a list--names, emails, and addresses--of a substantial fraction of those people who have pirated mp3s on their hard drives.
Wow.
Damn. And the fact that their site is signed off by Truste makes it even worse. All of this makes me want to vomit. Oh well; at least I never used the damn thing cause it stayed resident in memory and crashed all the time. In any case, that sucker's uninstalled for good.
-David
Whoops and double whoops.
Yep, should have said more pipelined instead of more superscalar, but I was right that having a deeper pipeline means it's easier to fab high clock speed parts. And that the reason the K6 was so damn hard to fab is that its pipeline is only 6 stages deep.
And I really swear that I meant to say that a GPU takes a good deal of the advantage off of the Athlon's awesome floating point for the average user. There are, of course, lots of uses for an FPU that have nothing to do with transforming and lighting polygons. However, the average Joe buying an Athlon is mostly interested in using its FPU to play some Quake3, and I'd bet that 90% of the unaverage Janes left over who'd buy an Athlon for a different reason just want 3D Studio to render faster; a GeForce would take most of the load off of the Athlon's FPU in both cases, especially the latter.
I have to say, I really just don't get the PC hardware industry. That is to say, in my heart of hearts, I have close to no doubt that Intel seriously pressured all the mobo manufacturers not to make/market Athlon boards, and, gross as that is, I of course understand it.
.18u copper (i.e. like the metal) parts. From what I've heard, they'll hit 1 GHz about 2 months faster than Intel (I read that AMD'll prolly get there in 2/00, Intel in 4/00), and the gap should only grow. After all, unless you believe the Register that Intel's gonna launch Willamette in December (Note: Are they nuts?!?! On second thought, this wouldn't be the first time the Register has inexplicably been unable to understand the difference between taping out and being available from Dell...) then you have to accept the fact that Intel will be stuck with an amazing-for-its-time (remember, Coppermines have the same core as a PPro from way back in 1995) but still less scalable, not to mention not copper, core until probably next fall. Point is, it's a pretty safe bet that the Athlon will be the faster chip for the next 9 months. And even safer that it'll be better price/performance.
What I don't get is, if that indeed happened, why has none of them just come out and said so? Honestly, this isn't as stupid as it looks. Let's count the reasons why not:
1. The Athlon is a superior product. Yes, a 133MHz bus Coppermine on an i820 mobo is just about at parity as far as performance/MHz goes. (Benchmarks I've seen--a lot of sites had prerelease i820s they used for testing (with only 2 RIMM slots filled of course)--put the CMines faster at office type stuff, the Athlons whipping up on FPU benchmarks and rendering type stuff, and the two about even on Q3ish stuff, which at this point is not yet optimized for the Athlons new FPU pipeline and expanded 3DNow set.) But the only reason AMD's pausing at 700 or 750 MHz for now is because they're ramping up their
2. People know this. Certainly if there are enough people who know what they're doing and want speed for mobo manufacturers to build high quality boards specially for overclocking, and even dual Celeron boards, then there's more than enough market to justify making Athlon boards.
3. AMD is not having any production problems. While this may surprise the ignorant among us who just assumed that AMD was a bunch of blubbering idiots for not being able to keep the K6's up to MHz with PIIs, it's really no surprise at all. See, the K6 design just wasn't very superscalar. For those who don't know what that particular buzzword means, it refers to how many stages the pipeline is divided into. More stages means the processor does less things in each clock cycle, which means you can fit more cycles in a second. The downside is higher latency when a prediction misses, but as it turned out, branch prediction is good enough that deep pipelines/high MHz works better than low latency/low MHz. So anyways, the K6 designers guessed the wrong solution to that one, and ended up with a 6 stage pipeline in comparison to the P6's 13 (IIRC) stages. Hence, the fact that AMD was able to stay within one or two speed bins of Intel for all that time is actually a testament to the high quality of their manufacturing capabilities. As for that huge shortage this February...well, consider the fact that up until a couple months ago, AMD had exactly one fab, and a small one at that. Intel has eight. How much would you like to bet that, at one fab or another, Intel has problems just as severe as the AMD ones all the time, but you just never hear about it because they can shift production to another plant? Of course, now that AMD has a second fab, and, not only that, but a huge state of the art one, the all-eggs-in-one-basket problem is pretty much solved as well.
4. Intel has screwed the mobo manufacturers over big time. This i820 thing is a huge huge huge debacle, and it's all Intel's fault. Furthermore, no one in the industry can be happy that Intel insisted on switching over to RDRAM well before its time, either. Fact is, with proper economies of scale (that is, if the mobo manufacturers would just make the damn things), an Athlon motherboard and RAM could sell for about half the price of an i820 with RDRAM. Why anyone would be scared of burning bridges with Intel after what Intel's just done to them is beyond me.
5. Intel's under major antitrust scrutiny. I mean, if they were bullying mobo companies into shelving, overpricing, or undermarketing their Athlon boards, why on earth wouldn't one of them just pick up the phone and call the FTC? Or better yet, The Wall Street Journal?? And yet they appear to think they're in a better bargaining position if they just keep it to themselves and maybe grumble off a few anonymous leaks to hardware fan sites on the web?? Huh???
So what's going on here? I honestly don't know. On paper, and in the benchmark labs, and on the roadmaps, AMD has Intel blown out of the water for quite some time. On the one hand, it happens to be true that the recent trend toward graphics cards with GPUs takes a good deal of the advantage off of the Athlon's superior floating point performance, but you'd be pretty hard pressed to say that, from a theoretical perspective, things look anything but shitty for Intel. Except that, possibly due to nothing more than some well placed, and presumably illegal, intimidation (and not just directed at the mobo people; witness Dell and Gateway, the sort of names average people think of when they think of fast high quality computers, not offering any Athlon systems), things look just fine for them.
It's a pretty scary thought that this sort of thing could still go on right after the MS trial. But I just don't have any other explanation.
Sorry for the long post; I've got lots to say about this.
.1 is to take care of all the kids who die before they reach adulthood and can reproduce). Here in the US, we're just below that--about 2.05 kids/woman--and once you take immigration into account, our population is expected to be slowly growing for quite a while. In much of western europe, though, it's already quite a bit different. In most of the Scandanavian countries, as well as France and Germany, they're already down to about 1.4/woman. Same thing in Japan. In Italy, it's an astonishing 1.2--elementary schools are closing all over the country; in some towns, there are more residents over the age of 85 than under the age of 6. China and Russia each have similar fertility numbers (both about 1.4/woman), although each represents a very different situation. In China, of course, the low numbers are probably overall a very good thing: the social problems they've run into because of their restrictive fertility policies (mainly things like, it's lonely not to have any siblings, aunts and uncles, or cousins) obviously don't compare to not having enough to eat. In Russia these days, everything demographic is a bad thing. Not only do they have low fertility rates, but the average life expectancy for Russian males has dropped to something like 63 years. The end result is that Russia's population is actually crashing now, as opposed to countries with low birth rates, where the implosion, if it comes, won't be until the baby boom generation starts dying in serious numbers--prolly around 2020 or so.
/. were, say, News for Construction Workers, well, the reaction to this news might be a little more concerned. After all, a declining population means there's no need for new houses.
.1% over current guesses, the Social Security shortfall disappears completely. Of course, if you lower it by .1%, the shortfall doubles), we could be in for a lot of trouble once the Baby Boomers retire. And the situation will be considerably worse in places like Japan, France and Italy--all three have more generous welfare stats than the US, and all three have a considerably greater demographic gap looming.
Hmm. First off, of course this is old news, although most people haven't heard about it yet. I first learned about the issue in a pretty fascinating article in the NYT Magazine ~2 years ago; also, Slate had one of those little dialogue thingies about a year ago between (IIRC) Erlich and I think the guy who wrote the NYTM article. As usual for debates when at least one of the participants is a total nutcase who believes his entire credibility rests on never admitting he was wrong (I'll let y'all figure out who that was here), the dialogue ended like a particularly vicious vi vs. Emacs spat, but it was pretty informative nonetheless. In any case, NYT and Slate both give free access to current content but charge for a look at their archives, so no links here. (Note: if that isn't the most absurd internet business model I've ever heard of...but I digress.)
Just for some base understanding on the numbers here, the replacement fertility rate for a population is generally taken to be 2.1 children/woman of childbirthing age (the extra
Anyways, the second point (which, btw, even Erlich conceded eventually) is that the "most likely" UN demographic scenario referred to by J--actually, even the UN only calls it the "middle variant" scenario, and makes no claims as to its validity--is complete bunk. Essentially, it comes about by assuming that, starting right now, today, the fertility rates in every single country around the world will magically (and linearly!) begin to converge to 2.1, which they will hit in the year 2050, and then stay there, with a world population of ~8.5 billion, forever. Obviously, that's a ridiculous assumption. Indeed, the low variant figures cited in the linked article are by far the best guesses we have. They don't assume any miraculous changes in the modern lifestyle of people in developed countries that would spontaneously raise the fertility rate up to a sustaining number, and they don't assume that the uneven but precipitous decline in third world fertility rates will magically stop at the 2.1 mark either.
Of course, they're still almost completely worthless. The thing is, we have very little idea as to what causes mass cultural phenomena like prevailing birth rates. Take the exact opposite event: the Baby Boom. At the height of the 18-year long Baby Boom in the US, fertility rates were something like 3.6. (Compare this to the notoriously out of control demographics of India today: fertility rate 3.7.) Then, in a matter of a couple years around 1963 or so, it all stopped. Now the obvious questions are a) why did it happen, and b) why did it stop. Problem is, we don't really know the answer to either of them.
The prevailing notion seems to be that the Baby Boom happened because times were economically good, and people felt economically secure. This is demonstrably an insufficient condition--after all, fertility rates in the other two economic booms of the century--the 20's and the 90's--have been lower than normal. And the idea that today's economic upturn is somehow "less secure" than previous ones simply isn't supported by, for example, polls in which people overwhelmingly say that they feel economically secure.
Now, what did happen in the Baby Boom that was completely different from what's happening in developing nations today is that the culture at large strongly supported the idea that women should marry early, stay at home, and raise children. Then came feminism. While it's not really true to say that we know what stopped the Baby Boom--indeed, the feminist movement was concurrent with the Baby Bust at best (The Feminine Mystique wasn't published until 1963)--it seems like a pretty good bet that the gains of feminism are by now too firmly entrenched to allow a return to the days when women went to college, if at all, to find husbands, married at 20, and stayed at home to have 4 or 5 kids.
As the article points out, this will probably lead to some pretty severe social problems down the road. For example, if instead of being News for Nerds,
Of course, it's not just housing construction that'll be hurt by this. As the article pointed out, dropping birth rates and increasing life expectancies lead to inevitable problems paying for Social Security. Now, as it turns out, this is a bit of a false issue here--the real cause of the Social Security crisis set to hit in about 2030 that we've been hearing so much about isn't so much the low birth rates of today as the extraordinarily high birth rates of the Baby Boom; in other words, assuming fertility rates in the developed world do remain at their current low levels, we'll still only have to go through one Social Security crunch. Still, it's worth noting that, depending on the performance of the economy over the next 30 years (and that's a big depending: for example, if you raise the projected annual GDP growth for the next 30 years by just
Furthermore, disregarding all the money taken out of the economy to pay for Social Security, let's not forget all the money that doesn't go into the economy because of a shortage of workers and young consumers. Not that the poor economic performance of the 70's can at all be traced to one root cause, but it's worth noting that the decline hit in 1973--10 years after the Baby Bust--and lasted until 1982. That is to say, for 38 years after WWII, there was a huge supply of young people acting as both consumers and labor, and the economy steadily grew. Then, that supply of young people dried up...and the economy suddenly stagnated. Worth noting.
Furthermore, for an issue closer to home with most of us here, it's worth considering that most of the great ideas that we all care about come from young people. An old society is probably doomed to not be a technologically innovative one.
Of course, most of the debate so far has been centered on the idea that, since overpopulation in the developing world is a problem, there couldn't possibly be anything wrong with underpopulation. And to be fair, that's sort of due to the tone taken by the article: I, for one, find something very disturbing at the least in the author's implicit notion that the fact that brown people will outnumber us great civilized white people by an even greater margin in 50 years than they do now is necessarily cause for alarm. Still, we have to consider the ideas that a) the fertility rates of the developing world today are no greater than the fertility rates in the west when it was still developing; in fact they're considerably lower; and b) they're dropping very very rapidly.
Now, the fact that they're dropping very rapidly is a very good thing. Some of the causes of the drop--increased industrialization; increased access to health care and birth control; increased life expectancy; increased education for women--are very very good things. But there's no reason why the decline in fertility rates in the third world won't continue until they, too, are below replacement rates. And if any countries need an infusion of young labor and consumers to stimulate their economies, it's developing nations.
Of course, this is not to say that depopulation isn't better than the alternative. Our natural resources are running out, for example: oil reserves are constantly overestimated by oil producing nations, in a futile arms race to get a larger percentage of OPEC quotas for themselves; an article I read in SciAm about a year ago estimated that we'll be out of easy-to-find oil by 2010. But underpopulation still has many attendant problems, both economic and social. I know I, for one, wouldn't want to have grown up without siblings or cousins, and with very few people my age in general. And, furthermore, that I wouldn't want the few friends my age to be spoiled rotten only children of rich parents who spent too much time working to give their kid any parenting except for expensive toys...
Hmm. Sorry if that was a bit disjointed and lengthy. Anyways, just my seven cents or so...
-Dave
No problem. Frankly, the only reason I came down on you so hard was that I've really grown to like some of the stuff over at ars, and find Hannibal's architecture articles particularly informative, detailed and, most importantly, written well enough for the layman to understand. In fact, they're part of the reason I'm only a mostly-layman these days.
/. gets a bit too civil these days; shaking things up when you're pretty convinced you're right is always fun. ;)
Oh, and because I find
As for RISC being a true innovation, and not at all obvious at the time: yes, you're absolutely right. It's only in hindsight and with the story smoothed out a bit that we realize that the environment which made "CISC" processors a good design had ceased to exist by the 80's. I don't want to take anything away from the original designers of the RISC philosophy; but still, I very much agree with Hannibal's thesis that that debate has just about nothing to do with the merits of today's CPUs.
Urg. Sorry, but I'm just gonna repost the comment I made about a week ago when some other wierdo spouted the same ignorant blather.
Oh wait: it wasn't just any wierdo. Believe it or not, it was you, Millennium. Perhaps you could read what people respond to your comments. After all, saying something incorrect once just makes you look uninformed; saying the same thing after you've been publicly corrected makes you look willfully stupid...
--begin repost--
They're already at price/performance parity, more or less. The G4 is roughly triple the speed of a P3, and this is using Intel's own benchmarks, mind you. We're not talking Bytemarks here, boys and girls, we're talking benchmarks no one dares discredit.
Oh lord. Another one falls for the Apple FUD.
No, we're not talking Bytemarks here; this one, if you can believe it, is even worse. You see, at least Bytemarks is a benchmark. It's about 10 years old and has absolutely no bearing whatsoever on the performance of a modern CPU, but at least when they came up with it, someone was trying to get an idea of how fast a chip would run.
These 6 tests are not benchmarks, in any normal sense of the word. Benchmarks measure how long it takes for a computer to perform a real-world task. These tests (Apple's got 'em posted here; scroll to the bottom) measure the speed of individual ops.
That's right: the G4 performs 6 specific operations an average of 3 times faster than a P3. We're talking things with names like "1024 dim. DotProd" and "256 Pt. Complex FFT". The G4 can take a dot product 3.68 times faster than a P3. Oh wait--not even that; a dot product in a specific dimension. Whoopdee. A 128-bit unit can do operations on very large numbers faster than a 32-bit one. Wow. This is like posting the fact that a 64-bit CPU can add two 64-bit numbers faster than a 32-bit one. Who would have thought.
And yes, these benchmarks were "published on Intel's own website." Of course they were. In the technical specs on the SSE core. Deep in the technical specs on the SSE core. Where information that is completely useless to anyone not planning on optimizing a compiler belongs.
Essentially, this benchmark is as misleading as quoting MFLOPS (oh yeah: Apple stooped to that one too...). Except that usually when you quote MFLOPS you at least generally need to average over the entire set of floating point ops. Not here folks. They picked out their favorite 6.
Oh wait--here's another difference: when you quote MFLOPS, you actually need to, uh, benchmark the thing. These numbers are all theoretical--just compare the number of clock cycles it takes to do an operation, and multiply by MHz. Now, it turns out they'd probably be even more in the G4's favor in practice--if I remember correctly, the AltiVec unit has a much better designed pipeline than the P3's SSE unit. But still, these numbers are absolutely, completely, worthless.
I don't have the URL offhand, but I've seen the Intel page they copied these tests from, and there were literally hundreds for them to choose from.
The point is, you can always find an operation that is carried out in less clock cycles on one particular archicture as compared to another. Always. Now it turns out that, in this case, the AltiVec apparently really is vastly superior for the sorts of things it does when compared to Intel's SSE or AMD's 3DNow. (Of course, it also takes up half the chip. Any guesses as to why they can't fab any 500's??)
However, the fact is that except for very specific applications (SETI@home in particular, and some signal processing stuff, IIRC), it doesn't make all too much of a difference. A 700 MHz Athlon will smoke a G4 450 or 500 or whatever on your basic integer stuff, and a 600 MHz P3'll be right up there with it. For the stuff that can be done with AltiVec, the G4'll certainly come out ahead, but for general floating point work, again, they're about equal. It goes without saying that, at this point, nothing crunches graphics like a year-old PC with an NVIDIA GeForce in it (except maybe something from sgi)--which, of course, is about the only thing the average user needs good float performance for anyways.
In the end, the G4 is just a decent chip with a neat vector processor that's proving hard to fab. Is it damn fast? Yes. Is your new G4 450 going to touch the Coppermine P3 733 that's shipping by the time yours actually ships? Nope. Is it "two or three years ahead of its time" like Stevie says? No way.
-Dave
P.S. And yes, you can sell them to China as well. As much as I want to like Apple these days (a simplified vertically integrated product line is a very good idea in many cases; OS X just might be incredible; and geez--did you check out the new iMac subwoofer??), the fact that every single word out of their marketing department/CEO's lips is a baldfaced lie...gives me pause.
- When the first RISC machines came out, superscalar execution hadn't been invented yet.
Unfortunately, the actual quotation from the article is "When the first RISC machines came out, Seymore Cray was the only one really doing superscalar execution." Whoops. Looks like ya' dropped the ball on that one.Some processors (Cray for one) had been doing this years before RISC came out.
- I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling
Well, that's very forward thinking of you. Of course, I guess that makes you clueless as well, because, once again, it's exactly what the author of the article wrote: "VLIW got a bad wrap when it first came out, because compilers weren't up to the task of ferreting out dependencies and ordering instructions in packets for maximum ILP. Now however, it has become feasible, so it's time for a fresh dose of the same medicine that RISC dished out almost 20 years ago: move complexity from hardware to software."So this leaves us with your remaining "point":
- The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.
Well that's a brilliant insight you've uncovered there (covered in the article here), but the point of this "clueless" article (which you obviously did not read) was that there no longer is a debate. The term RISC refers to a CPU design philosophy which was invented in 1981. That was 18 years ago. It was intended as a replacement to "CISC", the CPU design philosophy which came about in the early 70's.That is to say, the CPUs of today, whether P6 or PA-RISC or G4, and the systems that they are in, bear almost no resemblence whatsoever to either a "CISC" chip or a RISC chip. The only similarity is that the P6's and K7's of the world are compatible with the x86 ISA, which was originally written (back in 1977 IIRC) for a "CISC" chip. Yes, this adds an extra decoding step (to break down instructions into "RISC-like" ops), and yes, theoretically that means increased die-size and complexity, which of course means lower clock speeds. Oh wait--that reminds me: which currently shipping chip has the fastest clock speed?? Oh yeah--the 700MHz Athlon. With a 750 part set to be shipped later this week. And, looks like, a 900 in time for New Year's. One of those ungainly "CISC" chips, huh.
Hmm...but let's take a look at how all those competing "RISC" chips have used their incredibly simple architectures to keep die size down. Like the PA-RISC, which is, IIRC, about 6 or 7 times the size of a PIII. Or those new G4's, with their impressive yield of 0% at 500MHz. The simplicity of today's modern "RISC" chips in action.
Now, none of this is to say that the G4 or the PA or whathaveyou isn't a great design. Just that the resemblence of today's CPU's to a true "CISC" or RISC chip is so tangential as to make the categorization meaningless. And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time. By 1981, the state-of-the-art had advanced to the point where RISC was a better solution. Duh.
Since then, compilers have gotten better, transistor densities have increased, and RAM prices have plummetted, allowing all the advancements which the author termed "post-RISC". And, looking at the CPU's of tomorrow, we see all sorts of new techniques on the horizon: optimization based on advancements in compiler/software technology, ala IA-64, MAJC, and (apparently) Transmeta; or optimizations based on incresing transistor densities, like some of the new physical parallelization designs that appear to be a couple generations down the road for Alphas and IBM chips.
But as long as people like you insist on categorizing these chips into meaningless 20-year design philosophies, the tech world will be a more ignorant place.
What a dissappointing comment.
They're already at price/performance parity, more or less. The G4 is roughly triple the speed of a P3, and this is using Intel's own benchmarks, mind you. We're not talking Bytemarks here, boys and girls, we're talking benchmarks no one dares discredit.
Oh lord. Another one falls for the Apple FUD.
No, we're not talking Bytemarks here; this one, if you can believe it, is even worse. You see, at least Bytemarks is a benchmark. It's about 10 years old and has absolutely no bearing whatsoever on the performance of a modern CPU, but at least when they came up with it, someone was trying to get an idea of how fast a chip would run.
These 6 tests are not benchmarks, in any normal sense of the word. Benchmarks measure how long it takes for a computer to perform a real-world task. These tests (Apple's got 'em posted here; scroll to the bottom) measure the speed of individual ops.
That's right: the G4 performs 6 specific operations an average of 3 times faster than a P3. We're talking things with names like "1024 dim. DotProd" and "256 Pt. Complex FFT". The G4 can take a dot product 3.68 times faster than a P3. Oh wait--not even that; a dot product in a specific dimension. Whoopdee. A 128-bit unit can do operations on very large numbers faster than a 32-bit one. Wow. This is like posting the fact that a 64-bit CPU can add two 64-bit numbers faster than a 32-bit one. Who would have thought.
And yes, these benchmarks were "published on Intel's own website." Of course they were. In the technical specs on the SSE core. Deep in the technical specs on the SSE core. Where information that is completely useless to anyone not planning on optimizing a compiler belongs.
Essentially, this benchmark is as misleading as quoting MFLOPS (oh yeah: Apple stooped to that one too...). Except that usually when you quote MFLOPS you at least generally need to average over the entire set of floating point ops. Not here folks. They picked out their favorite 6.
Oh wait--here's another difference: when you quote MFLOPS, you actually need to, uh, benchmark the thing. These numbers are all theoretical--just compare the number of clock cycles it takes to do an operation, and multiply by MHz. Now, it turns out they'd probably be even more in the G4's favor in practice--if I remember correctly, the AltiVec unit has a much better designed pipeline than the P3's SSE unit. But still, these numbers are absolutely, completely, worthless.
I don't have the URL offhand, but I've seen the Intel page they copied these tests from, and there were literally hundreds for them to choose from.
The point is, you can always find an operation that is carried out in less clock cycles on one particular archicture as compared to another. Always. Now it turns out that, in this case, the AltiVec apparently really is vastly superior for the sorts of things it does when compared to Intel's SSE or AMD's 3DNow. (Of course, it also takes up half the chip. Any guesses as to why they can't fab any 500's??)
However, the fact is that except for very specific applications (SETI@home in particular, and some signal processing stuff, IIRC), it doesn't make all too much of a difference. A 700 MHz Athlon will smoke a G4 450 or 500 or whatever on your basic integer stuff, and a 600 MHz P3'll be right up there with it. For the stuff that can be done with AltiVec, the G4'll certainly come out ahead, but for general floating point work, again, they're about equal. It goes without saying that, at this point, nothing crunches graphics like a year-old PC with an NVIDIA GeForce in it (except maybe something from sgi)--which, of course, is about the only thing the average user needs good float performance for anyways.
In the end, the G4 is just a decent chip with a neat vector processor that's proving hard to fab. Is it damn fast? Yes. Is your new G4 450 going to touch the Coppermine P3 733 that's shipping by the time yours actually ships? Nope. Is it "two or three years ahead of its time" like Stevie says? No way.
-Dave
P.S. And yes, you can sell them to China as well. As much as I want to like Apple these days (a simplified vertically integrated product line is a very good idea in many cases; OS X just might be incredible; and geez--did you check out the new iMac subwoofer??), the fact that every single word out of their marketing department/CEO's lips is a baldfaced lie...gives me pause.
No, it's not true. Email to AOL can not run scripts. The procedure Moravik describes is exactly correct. Indeed, unlike a program like Outlook--which still requires the user to expressly click on an attachment to run it--AOL makes you actually save it to your HD, find it, and double-click on it. Furthermore, it pops up an annoying little message about how you should never run code you don't trust, every single time you download an attachment. And finally, if someone in the family is too stupid to figure all this out, you can prevent their screen name from recieving email attachments altogether (assuming the person with the master account knows enough to do that).
The point is, AOL's email attachment model is too strict, IMO. It's just downright annoying and inefficient. And, it seems to me, adding all these extra steps isn't going to stop anyone from running an attachment that they were going to run otherwise...although I suppose the big red warning is a nice feature for newbies.
As always, once you hook it up to the big bad internet, your computer is only as secure as your knowledge of security issues. And AOL does as good a job of pointing these issues out as can really be expected.
In the press on this topic, Compaq was quoted as saying that only 5% of their Alphas went out as NT systems.
Actually, the figure I saw was 2%.
Furthermore, MS is still using Alpha as the development system for 64-bit W2k; they just apparently won't be polishing it, marketing it, etc.
Now, this seems pretty darn stupid of Compaq to me to discontinue plans to market 64-bit NT. Yeah, yeah, 2%--why bother, right? Thing is, that 2% refers to running a 32-bit OS on a 64-bit CPU. If you were going to the expense of buying an Alpha, why hinder it with an OS that doesn't take advantage of its architecture? Hence the 2% figure makes a lot of sense.
But now that Intel is coming out with a 64-bit chip, well, Microsoft decides that's important enough to warrant a 64-bit OS...and this is the time Compaq chooses to pull the plug on Alpha NT?? Huh???
Especially since, according to all reports, by the time Merced is finally released (Q2 next year? Q3??), the Alpha's going to be walloping it. By the middle of next year, the roadmaps I've seen have the 21264's hitting well over a GHz...I think I've even seen 1.4 tossed around (but it was prolly at The Register, so, grain of salt). More importantly, benchmark roadmaps (these, I remember, were leaked from Compaq, so more salt) have a 1GHz Alpha beating an 800MHz Merced by ~40-50% (SPECint, IIRC).
So what's up???
Two theories. Wait, make that three (er, four):
1. Compaq's stated reason: they want to revitalize Tru64, and support Linux. Plus, no demand for NT Alpha. Possible...but I dunno. Tru64 seems to be a losing battle as a long term strategy; it's faster than Linux on Alphas now, but a few years down the road?? Seems smarter to go the sgi route, let your proprietary UNIX die, and let Linux sell your boxes. As for the lack of demand for 32-bit Alpha, see above. I think once it was 64-bit, people would buy. An appropriately high end Alpha box'd kick the hell out of an 8-way Xeon box on NT, and prolly a 16-Athlon as well.
2. Merced NT doesn't have much in common with Alpha NT, so MS doesn't want to spend time on it. Here, I pretty much have little idea what I'm talking about, but it would make sense to me if programming for a VLIW chip is just too different from programming for anything else. Cause VLIW is waaay different--far more different from existing architectures than CISC is from RISC, at least the way "CISC" and "RISC" chips are made these days. So perhaps the whole, "we're making a 64-bit OS anyways, why not port to Alpha?" idea doesn't actually work. On the other hand, most VLIW issues seem to occur in the compiler...and they're still using Alpha as the development chip for 64-bit W2k. So...
3. Maybe Merced'll be faster than we thought. This is my conspiracy theory of the day, and you have to understand that I've been pretty disappointed by Intel tech lately, so it's taking quite a bit for me to say this. But still...I mean, even if they didn't count on selling many Alphas for NT, don't you think Compaq would love to be able to claim how their much cheaper (and they will be) Alphas kicked the tar out of those new Merceds in a fair fight with the same OS?? (Note: yeah, it wouldn't actually be fair...but it'd sure look that way.) So either Compaq got wind of the fact that Merced won't be slower after all...or perhaps they realized MS wouldn't do what it takes to make the 64-bit Alpha W2k compete with the Merced W2k...or perhaps...
4! Intel paid 'em off!! Ok, this is too fun to pass up. Essentially this goes like, Intel's just spent, what, 3 or 4 years now on a laughingstock of an overpriced chip (yes, I have no doubt that eventually IA64 will be amazing...but not on Merced), and they desperately want to avoid any controlled comparisons. So they politely ask Compaq and MS to stop development on 64-bit NT for Alpha. Besides, Compaq'll be selling their share of Merced boxes, so they've got as much to lose as anyone.
Pretty spooky, huh!!
Yes, it was pretty damned stupid. But no, it wasn't just reading headers.
The message was sent from an anonymous account at Yahoo. Now, this was incredibly dumb--what "owner of Bucking Consulting, a software consulting firm" would send mail from a free account?--but the headers still don't say anything about microsoft in them. However, they do contain the originating IP address, which was traced back to MS.
"The one computer security expert who could trace it back to Microsoft"? Not quite. But it wasn't as absurdly obvious as you might think.
Some computers boot with NumLock on, some with it off. This is usually selectable in the BIOS...
Actually, it goes something like this: (Only "something like," because the details of what exactly the Scientific Method is and how it works are still a matter of much philosophical debate. But rest assured, nobody thinks it's what they tought you in 5th grade anymore.)
A hypothesis is an educated guess about the results of an experiment to be preformed. The experiment should be designed to, as much as is possible, either confirm or refute the hypothesis (and only the hypothesis).
A theory is something rather different. A theory is an explanation for a group of related phenomena--for a subset of reality, if you will. A theory is judged to be successful if it is a compelling explanation: generally, if it makes sense logically, explains the way reality is--both from normal observation and from the observation of controlled experiments--better than any previous theory, is not contradicted by any observations of reality, and is the simplest it can possibly be and still accomplish the above.
Contrary to what you probably learned in school, real scientists don't go around doing lots and lots of experiments, or even worse, just making lots and lots of uncontrolled observations, and then coming up with a theory. They come up with a theory because they think the existing one isn't compelling enough--sometimes, because new evidence contradicts it, but most times because they find its explanation unsatisfactory. (Well, most times it's a combination of the two--the old theory is usually stretched to try to accomodate the new evidence, to the point where its explanatory powers are no longer any good.)
And no, it's not true that "the more times an experiment verifies a theory, the more likely it's true." I can drop an apple on my head a million times, and it won't make Newtonian gravity any more likely to be true. Furthermore, if you have no explanation for why the apple keeps hitting you on the head, it doesn't make it any more likely that the same thing will happen the million-and-first time you drop the apple.
That's why if you just think of a science as a sort of compliation of observations, and not as an attempt at a coherent explanation of reality--like, incidentally, the creationist "scientists" often tend to--then the fact that no one's ever witnessed, say, a fish evolving into a frog becomes a big argument against evolution. Luckily, that's not how science works. Remember, the big deal about Newton wasn't that he noticed that apples hit the ground when they detach from trees (safe guess that most people notice that), nor that they accelerate at a constant rate on the way down(that was Galileo)...but that the reason it falls is the same reason that the planets go around the sun. Similarly, when the church tried Galileo for saying, well, that the planets went around the sun, they didn't dispute that his observations fit such a theory. Instead, they told him, why can't you just say that the planets actually go around the earth, but that God made them go around the earth all funny so that it looked *just like* they were actually going around the sun. He, of course, said nope, because science isn't about observations, it's about...compelling explanations.
Phew.
Ok, so finally (this is long enough without going into the math stuff), a law isn't just a theory which gets supported over and over. In fact, just about every law we have, we now know to be just approximations--none, that I can think of, are still thought to be strictly correct. Nope, a law is a theory which explains a relatively broad subset of reality, and most importantly, does it very tersely--generally in a sentence or two. Thus, F=MA or every action produces an equal and opposite reaction, those are laws. Quantum theory, despite being arguably as important, will never be a law, cause you can't sum it up like that.
As has been pointed out, the "Pentium Toaster" ads only used the Bytemark benchmark, which is extraordinarily old and has very little relevance to the sorts of things CPUs do these days. For one thing, it includes no floating point tests at all, IIRC--and these days, most things the average user (i.e. no compiling) runs into that'll tax his/her CPU are floating point dependant. And furthermore, (also pointed out before), the MacOS hampers performance considerably. And if you want to do any sort of multitasking at all, it hampers it hilariously. Obscenely, even. Check out this article at the always impressive Ars Techinca for some ROFL confirmation. To be fair, this was benched before OS 8.6, which allows (gasp!) multithreading...but if I understand correctly, apps need to be rewritten to take advantage of it anyways.
As for real, cross-platform, general CPU benchmarks, there's pretty much only SPEC, limited as it is. Yes, to some degree it depends on issues of compilers, chipsets, RAM, etc. But it's good enough to at least be relevant.
Apparently, as far as SPEC95 goes, the G3 is about 14% faster/MHz than a P3 in SPECint, and about 9% slower/MHz than a P3 in SPECfp. Course, the G3 doesn't come anywhere near close to the P3 or K7 in MHz terms anyways.
And double of course, what really matters is app performance. Here, assuming one stays with the MacOS, we run into some serious problems. Essentially, ClarisWorks (now AppleWorks?) was way more optimized for Mac than PC (duh), and it showed. Photoshop is probably equally optimized for both--and no, contrary to what you've heard, it isn't necessarily faster on the Mac. Look a bit further in the Ars article above: turns out that while the Mac wins the Gaussian blur test w/64 megs RAM...it loses with 128 megs on a 100MB file...it loses on the lighting effects (FP intensive) tests...and, this is the big one, it takes 3 times longer to load the 100 MB TIFF in the first place. Woops. And as for, say, anything made by the Microsoft corporation, don't even bother: to say it's better optimized for PC is the understatement of the year. IIRC, MacOffice97 worked by just porting the relevant Win95 API's and keeping the program itself the same. MacOffice98 might be better...but not by too much.
Obviously, none of the above applies to K7 vs. P3 discussions--except, of course, for 3DNow(!) stuff, but by now most all video card drivers etc. are quite well optimized for 3DNow, and with AMD having the fastest chip on the market, that'll only improve. In any case, just read all the K7 reviews above, and you'll see that this thing doesn't just chew up the P3 in one or two CPU benchmarks...it whups it handily in just about everything. Synthetic benchmarks, Winstone, games, encoding, rendering, you name it. And this is before apps are optimized for it (new 3DNow instructions; 3-issue FPU unit, etc. all could benefit from optimizations).
[Note: from here on out, I'm pretty much talking out the ass of this page here on JC's News. Dunno how accurate it all is, but JC generally knows quite a bit about what he's talking about. And I've read some other stuff that backs him up.]
Now about the G4...well, it seems that the design goals of the G4 were to get SPECint 20 and SPECfp 20 @450MHz (I've heard this elsewhere, although I don't recall a mention of 450 specifically)--implying that it will run at around 450 on introduction. Now, the K7 at 600 beats both of those marks handily, and indeed if you assume, as JC does, that SPEC scales linearly (course it doesn't, but...) then the G4 is just a hair slower at SPECint (and exactly the same at 500MHz as the G3. Anyone else out there know if the G3 and G4 have exactly the same integer unit?), and a bit faster at SPECfp. Note that I'm not sure if he's using old guesses at the K7's SPEC marks, or real numbers...and I'm too lazy to figure it out right now.
Now, of course the target goals for the G4 were made back when they said it'd be coming out...well, by now. Instead it's going to ship in "Q3 1999"--where Q3 1999 is read, "January." So we can expect higher MHz on intro than 450.
Of course, by then, the Athlon'll be at 750 at least. Probably 850. Rumor has it 1GHz. We'll see. In any case, JC goes ahead and pits a projected G4-550 against a (projected?) K7-750...and guess what, the K7 is a hell of a lot faster.
On the *other* hand, the real wild card in all of this is the G4's AltiVec vector processing unit (for those who don't know, vector processing is the sort of thing Crays (used to?) use--very very good at many things that normal CPUs use floating point to do). On paper, it totally totally kicks ass. Like orders of magnitude faster than SSE/3DNow. And from what I hear, it'll be way easier to optimize for than SSE/3DNow, and waaaaaay easier than MMX (which required assembly programming)--i.e., it might just require a recompile with the "optimize for AltiVec" box checked.
On the other other hand, with the recent emphasis on nonupgradable machines (with comparitively poor 3D acceleration) in their consumer line, and a reported general lack of attention to gaming among Apple bigwigs (course, this was in some ZDnet story, so who knows if it's true), the amazing power of AltiVec might only end up being used in embedded DSP machines by Motorola and IBM.
On the fourth hand, if I had an iBook I could surf the internet while I was in the bathroom. Draw your own conclusions.
Xeon cache goes up to 2MB. And only on the 500MHz part and below.
.18u process, as will all K7's starting around Dec/Jan if all goes well), this will have changed. But the 2MB limit on Xeons stays, as far as I've heard...probably all the way up until Foster (the Xeon of Willamettes) comes out, oh, say, early 2001.
The Xeon III 550 only ships with 512 kB, so far.
Of course, by the time those Athlons with up to 8MB L2 start shipping (prolly not until Q2--these will be on a copper
Of course, if Intel finds that its butt is being kicked around in the server market, they'll probably try to get bigger caches on the Xeons, too. The main reason against it is that it's damn hard to fab such a huuuuuuge cache and have it run fast enough (full clock speed for Xeons, and probably for the server Athlons too)--and it would be surprising that AMD would be that far ahead of Intel on a pure manufacturing issue.
[On the other hand, AMD will be able to crank out K7s at higher MHz than P3s, even with possibly worse fabs, because the K7 design is more superpipelined than the P3, especially in the FPU.]
The Onion ParentCorner Presents
Protecting Your Kids From Inappropriate On-Line Material
The Internet is a valuable educational tool, but for parents, it can also be a nightmare. Here are some tips for keeping your kids away from sexually explicit web sites and other questionable on-line content.
Drape your computer in terrifying slaughterhouse entrails to make it unappealing to youngsters.
Go to the favorites file in your web browser. Retitle "Goat Porn" folder "Financial."
Young boys are understandably curious about Internet porn, but not if you patiently explain to them that women's vaginas have razor-sharp teeth that can bite off a child's hand.
Tape pages of The Bible securely over your child's eyes, ears and mouth, then double his daily butterchurn chore-hours.
Periodically check your family computer's log-on history for any pornographic sites not visited by yourself.
Make sure your child does not use the Internet after 9 p.m.
Do not allow your kids to become desensitized to violence. Beat them harder each day.
Glue storybook pictures to your computer's monitor. Tell your child that this is the Internet.
Ask yourself why, if you can't exercise even a moderate degree of control over your children, you bothered to have kids in the first place.
Write letter asking web site "Cock-Craving Asian Nympho-Teen Cum Sluts" to tone it down a bit.
Replace your children with responsible adults.
Provide your child with a detailed list of every web site he or she is not to visit.
Force your child to look at pornography for many hours straight until child begs, "No more!"
A good idea...but just to supplement it, you might want to know that "all the theaters with bad policy" is more or less those theaters who belong to NATO.
No, not that NATO, silly! The National Association of Theater Owners--apparently a really really big industry group which most any theater except perhaps little independants belongs to. It's not actually true that Clinton just made a speech blaming Columbine on The Matrix and asked theaters to card kids and beat them with little clubs. What really happened is he had his people tell NATO "enforce the R rating and beat kids with little clubs, or else Clinton will make a speech and complain." And NATO agreed. So then Clinton made a speech and said, "because The Matrix caused the Columbine tragedy, I'm happy to announce that NATO has decided to card kids and beat them with little clubs. I'm also pleased to announce that everyone buying a little club and beating children with it will qualify for a targeted tax break."
So while the theater manager is sorta to blame, you might want to go to the top. Figure out how, and write/call/fax/email NATO to complain. Yeah, legally this has absolutely nothing to do with the government...but w/c/f/e your Congresspeople and the President as well.
AND boycott NATO theaters. Just because the manager is following orders doesn't make it right...
It is d.net's official position that security through obscurity doesn't work to prevent this type of crack--sending back blocks without checking them--and I think they do actually believe that, especially since it's now been done several times. It's worth noting that they do have a scheme to check this sort of thing--i.e. sending a known positive to the suspected client and seeing if it returns a negative or not.
.1% but would deter anyone from not checking their blocks, IMO.
/.
A couple things to note about this scheme:
1) Apparently at this point the key word here is suspected: they only test someone with suspicious activity (say, returning 800,000 blocks a day on a chip which will not be built for several years). Of course, other than the drop in rate, there's no reason I can see why they don't check on everyone every once in a while.
2) Many people have suggested a checking scheme based on hashing negative results--essentially sending some portion of the blocks out to two people and seeing if they get the "same" negative result. Nugget says that he realizes this is a better idea and will incorporate it into the next client.
Ok, fine. But I think the reason they haven't incorporated a hash check yet is not, as has been suggested, because they can't stand to lose any speed (people around here have been throwing around figures like 20%). If I understand all the issues correctly (a big if, but still), they only need to double check every, say, 1000 blocks or so in order to get a handle on most any cheating. After all, even someone who bothered running a "covert" hacked client--one that would report blocks fast, but not so fast as to arouse suspicion--would still report at least 1000 blocks a day. Double checking 1/1000 blocks would only slow things down by
No, what I think d.net is more worried about is someone who cracks the client--or, as is, in their thinking (and I have to say mine too), more likely, modifies an open source client--to send out a negative when it gets the winning key, and notify the computer user instead. Then they just report the answer to RC5 themselves, and get $10,000 instead of $2000. d.net loses $2000--$2000 which, I would hope we all agree, they deserve--and some worthy charity loses $6000.
First off, the hash checking scheme wouldn't catch this, although the known positive scheme would (or might, depending on what exactly it means for them to send a known positive block, and how this differs from a winning block).
And second off, I hope I'm wrong, but I have this feeling that such an abuse would be much more widespread with an open source client.
As for the other drawbacks of open sourcing, there's the issue of reliability--how do you know someone's altered client isn't giving off incorrect results because they didn't understand the changes they made? Without checking of both kinds--known positive and hash--we'd never know. Hence open source means they have to double check results way more often than is necessary now.
There's the issue of rival servers to d.net popping up, taking d.net's share of the prize and making coordinating unchecked blocks more complicated.
And finally there's the best reason not to open source: it works fine already. Somebody here suggested that an open source client might find a better checking algorithm. Again, I'm not expert on RC5, but from my understanding of it, there is no better algorithm. After all, the specs to RC5 encryption are public domain, and have always been so. If a better algorithm does come along (very unlikely, but possible), it'll come from a mathmetician, not some random guy on
Yes, you can buy stocks in odd amounts (i.e. not multiples of 100, or sometimes multiples of 50 or 25 depending on the stock price). However, it's generally not a good idea.
The reason why is liquidity. It's easy to forget this, but every time you want to buy or sell some shares of stock, there needs to be somebody else willing to sell you or buy from you the same amount of shares. Since most of the world buys stock in multiples of 100, it's hard to find someone who will sell you, say, exactly 62 shares of something--and it will be even harder when you want to sell to find someone who wants to buy exactly 62 shares.
Now, of course, you're generally not the one who has to deal with this--your broker is. So in order to discourage you and to offset the greater effort involved in finding a buyer/seller, they charge you higher fees for trading odd lots than lots of 100. Plus, the fact that no one wants to buy/sell odd amounts of stock means that there's less supply/demand respectively--which means you inevitably pay more/get less.
Nor does it take into account the fact that Intel has chained itself to Rambus RAM for their upcoming Camino chipset, despite the fact that no one has thus far been able to manufacture it with any sort of decent yield, it's hideously expensive, and it's no faster than PC100 anyways.
Nor the fact that, while the Athlon should hit 1 GHz by early 1Q 00 or even before the end of this year, Intel's roadmap doesn't have the (slower at equiavalent MHz) P3 hitting 800 until 2Q 00.
Nor the fact that the Athlon's point to point SMP, eventually supporting upwards of 16 processors and up to 8 MB L2 cache, should cream the bus-limited SMP performance of the Xeon for servers and high end workstations.
Nor that Intel is stuck with the darn-good-for-its-time but already 3 year old (remember the Pentium Pro?) P6 core until Willamette debuts in (hopefully) Q3 next year.
Nor that Intel will have to deal with the considerable difficulties of moving to copper for Willamette (AMD got around it by liscensing their copper process from Motorola, who has spent a year working out the kinks).
Bottom line: if I were Intel, I wouldn't be too happy about anything to do with AMD.
Actually, it's not so funny. Friend of mine (my roommate actually) used the original Back Orifice to remote admin the network at the place he worked.
And why not? It's free, it does everything he wanted, and most importantly, it consumes very little resources compared to competing commercial products. And my friend got paid a bunch for 10 minutes a week of playing around with it from his dorm-room computer.
Question is, why can't I get a job like that?
Again, the prices to consumers will begin to approach the OEM's price/1000 once the supply can meet the demand. OEM's sell CPU's on Pricewatch only when they can get more for them than they can get building a system with them.
So, since the K7 just came out, and AMD is only selling a few thousand the first month, and there are more than a few thousand people who realize what a kickass chip it is and are willing to pay a premium for it, and because it makes them look cool to be the first to offer K7-based systems...most OEM's would rather take all the K7's they can get their hands on and put them in computers rather than sell them seperately.
Unless, of course, they can make a huge profit on them.
Now, once the number of K7's out there stops being numbered in the tens of thousands and starts being numbered in the millions, then OEM's will start having more than they need. So, they'll try to offload them--at a profit if they can, at a loss if they can't. Whether they can or not depends on what other people on Pricewatch are charging. The more OEM's with excess chips, the lower they have to charge...and the more the price resembles their cost from AMD.
Supply and demand.
How do we know AMD didn't secretly raise the price? Well, because, with several thousand OEM's in this country, perhaps one of them might have said something if they did.
Patience, my child.
No, no, no.
The reason the Xeon costs so damn much is because it comes with (up to) 2MB of full-speed L2 cache. And while this helps the Xeon along on SPEC benchmarks a bit, where it really shines--and justifies the exorbitant price (somewhat)-- is in running large databases and such things. That's why the Xeon mainly shows up in...yep, database servers.
Now, the K7 will eventually come in configurations of up to 8 MB (!) of full-speed L2 cache...but for now their only selling them with 512k of half-speed L2 (same as a PIII). And since they didn't post exactly which kind of Xeon the K7 beat so handily, I'm guessing it was the version with a 512k L2 cache. Now, this is still impressive, since the cache is full-speed, and that should make a decent difference in SPEC scores...but let's remember that these Xeons sell for ~$930 (Pricewatch), not ~$3500 like their 2MB big brothers.
Of course, having said that, if you were thinking of spending $930 for a 512k Xeon, say, for a workstation or something, then hell yeah you'd be better off spending either $720 (Pricewatch again) for a K7 550, or $950 for a K7 600 (yep). And once K7's start getting onto the market in appreciable numbers (right now, they're being sucked up by OEMs as fast as they can be fabbed), the prices there will go way down--in general, the lowest price on Pricewatch is often very very close to the manufacturers price/1000. It's known as supply and demand, people.