maybe the GeForce4 MX (and not GeForce2) was included on the minimum requirements list because it "kind of" supports Pixel Shader 1.1 (which GeForce2 lacks). I say "kind of" because the GF4 MX's T&L unit requires help from the CPU to process vertex shaders (think Winmodems).
Check your article again: that's Vertex Shaders 1.1, not Pixel Shaders.
What does surprise me is no special support for the R100 (Radeon 7xxx) series, which supported PS 1.0, and could do 3 textures per pass.
That's not my recollection, nor does the chart at Beyond3D agree with you. R1x0 seems to support fixed-function environment-mapped bump-mapping only, which is not flexible enough to implement the D3 lighting algorithm.
Yes. Presumably the Chronicle reporter either didn't understand or didn't want to confuse his readers by explaining that the GF4 MX has less advanced functionality than the "lower-numbered" GF3.
I know that origionally Carmak wanted to require programable shaders, is that still the case, or did he relent and support the fixed function pipline that the Geforce 4 MX line inherited from the Geforce 2?
The Doom 3 engine does not and was never conceived of as requiring general-purpose programable fragment shaders. From the beginning Carmack targeted it at the "register-combiner" fragment pipeline of the GeForce 1 (NV1x) family, which allows for restricted combinations of pixel operations but not the programmability of even the very simple PS 1.0-1.3 style shader languages introduced in DX8. (So it's something of a halfway point between the DX7- style fixed-function pixel pipeline and the DX8+ style programmable pipeline. The NV1x register-combiner pipeline did not have an analogue in the Radeon 7x00 series (R1x0) and was not exposed in DX7, so ironically Doom 3--written in OpenGL of course, so using Nvidia's proprietary extensions is allowed--will be one of the first and only games to use the technology.)
Except for some minor effects in the ARB2 (PS 2.0+ level functionality) path, Doom 3 will not be exercising any fragment level functionality that can't be done with register combiners; the only difference is the number of passes required per fragment (5 or more for NV1x in common situations; 2 or 3 for NV2x; and 1 for NV3x+ and R2x0+).
So, leaving performance--and possibly memory size limitations--out of it, Doom 3 is perfectly compatible with any NV1x card, all the way down to the GeForce 1 SDR. Of course this is like saying that you can run Windows XP on a 386; it doesn't address whether the thing is playable or not. Last I heard, id intended on including at least some GF4 MX cards on the minimum requirements list, which would indicate that a GF2 or GF2-Ultra would be even more playable (which is to say not very).
What did the Mozilla Foundation do that has made Mozilla such a huge success? Maybe more to the point, why haven't other OSS projects taken off like Mozilla? Any ideas on what can be done on other OSS projects to achieve similar success?
First off, I'd question your premise. Mozilla's technical achievements are impressive but not unique among high-profile OSS projects, and its marketshare is still badly lagging. Look at Apache, Linux, Perl, MySQL, KDE, Gnome. Mozilla is far from the only tremendous OSS success story.
Having said that, a few thoughts on what made Mozilla more likely to achieve success than a typical OSS project:
Highly visible niche - Web browsing, email, and "Internet suite" stuff in general are the most common tasks PC users perform. More importantly, the state of web browsing on Unix/Linux back in 1998 was truly awful, so you had a large slate of potential developers from the OSS community to draw on. (Although Mozilla did a poor job of that at first.) Nowadays, the size of the web browsing user base and the frequency of use means plenty of high quality bug reports and feature requests.
Corporate backing - Mozilla began life with all the resources of Netscape behind it. That meant plenty of experienced full-time salaried developers, plus a ton of press and the name-recognition and mindshare that go along with it.
Main competitor standing still - Except for Critical Security Updates, Microsoft has literally not touched IE in 3 years, and the last truly significant upgrade was 5.5, 4 years ago. Because IE is not a revenue source (unlike Office), MS has no incentive to add features or improve the product unless their marketshare drops, which it has not. (Sorry, 1% doesn't count.) Indeed, MS has a huge interest in maintaining backward compatability with non-standards compliant IE; the strategic purpose of IE is to enhance Windows lock-in by being the only way to access IE-only websites. (XAML serves the same purpose in Longhorn, which is why Mozilla won't be a true success on this measure unless it can get mindshare and marketshare for the redesigned Mozilla 2.0 XUL.) But the point is, it's easy to look good against 4 year-old competition.
It's not that hard - I know I might get flamed for this, but really. If tiny ol' Opera can produce a credible, full featured Internet suite, and the much smaller KHTML team can put together an excellent rendering engine, then the Internet tool space is not all that impossible to get right. By which I mean only that the Mozilla project--even including all the great work they've done on Bugzilla and the rest--is not a level of complexity equal to, say, KDE or Gnome, or even Linux. Hell, Firefox is essentially all the work of one programmer--which, while incredible (and also a testament to the modularity of the Mozilla code), still underlines the point.
Finally, it's worth pointing out that as recently as a couple years ago, the Mozilla project was generally regarded as a failure. Certainly the organization and management of the project have improved tremendously since the early days, but I think the main reason the tenure of the Mozilla Foundation has been so much more successful than the Netscape/AOL days is simply that they inherited a nearly-mature product and proceeded to spend the last year polishing the hell out of it. A huge amount of the architectural heavy-lifting that has allowed Firefox to be such a great program was done three, four years ago, but it wasn't until maybe Moz Suite 1.0 two years ago that you even had and end-user product that could stand up to IE 6.
Meaning that I wouldn't dispair for other OSS projects that still trail their MS analogues. A solid technical design--which most of them have--means the opportunity for the sort of rapid improvement and polish Mozilla has received in the past couple years. Once the user base begins to move in, usability bugs follow, and from there, perhaps, things begin to snowball. (I'm looking at you, OpenOffice...)
Re:It's Gone Beyond Science Fiction into Mainstrea
on
Open Source Life?
·
· Score: 1
Again, two problems with that:
1) The resulting crop was 95-98% Roundup-resistant canola. That could not have happened from the random reuse of seeds from a conventional canola field that happened to have some cross-pollination from the neighbors.
2) He wasn't found liable for damages!
Re:It's Gone Beyond Science Fiction into Mainstrea
on
Open Source Life?
·
· Score: 2, Informative
The court found it likely that he specifically saved the seeds from a small area of his previous crops that proved extremely resistant to Roundup. >95% of his crop the next year was found to be Roundup-resistant. That's pretty unlikely to have been the result of him planting seeds from all parts of his land (previously planted with conventional canoloa) equally.
Nonetheless, he did not use Roundup and thereby take advantage of the GM seeds' properties, thus the court assessed no damages for his actions. They did rule that Monsanto can patent a genetic modification. That's the only real precedent of the case and the only real issue anyone can argue with IMO. Assuming you grant the patent, the fact that a hypothetical farmer who purposely harvested wind-blown GM seeds and took advantage of their properties without paying the patent owner would be liable for infringement seems unremarkable to me.
Re:It's Gone Beyond Science Fiction into Mainstrea
on
Open Source Life?
·
· Score: 5, Informative
Their seed ended up on his land through no fault of his, yet they claim they have a right to be paid license fees or to force him to spend his time and money removing corn derived from their migrating seed.
This version of events was determined to be false by the trial court, and that decision was upheld by the Supreme Court. Instead they found that he had saved seed that he knew was Monsanto-patented, (genetically modified to resist Roundup herbicide) and planted it without paying them a license fee.
No damages were assessed, however, because the court found that he did not accrue any extra profit as a result of using the genetically modified canola seed as opposed to regular canola. The reason being that he didn't take advantage of the invention because he didn't use Roundup and therefore had no way of making extra profit based on the patented bits.
(Also, for what it's worth, the case concerned canola, not corn.)
Basically, the only way you can view the Schmeiser decision as unfairly pro-Monsanto is if you believe that genetic modifications should be inherently unpatentable. (Which is not necessarily a silly position--I'm not sure I don't think that.)
Or if you are ignorant of the true facts of the case.
I think it's safe to assume that a large chunk of the remaining.71B is IBM iSeries nee AS/400 and that there are some other minor issues like a few remaining dribs of proprietary file and print NOS and so on.
Ah--OS/400 (or whatever they call it these days). That's what I was missing.
With that in place the numbers make much more sense.
That leaves $.94 billion unaccounted for; I was thinking this chunk could be VMS and NSK revenues, but that makes it difficult to fit HP's 32.5% share of x86 revenues into the $.94 billion left over when you subtract it plus HP's $1.17 billion in proprietary Unix sales from HP's $3.07 billion total sales. (And that's ignoring HP's Q1 IA64 sales, which were very substantial.)
Of course all these questions are surely answered in the report itself, but I'm not gonna pay 95 bucks to find out.
*How do I know the figures in the com.com article are QoQ and not YoY? Because the Gartner summary (linked above) puts overall YoY revenue growth at 24.1%, not the 9.3% reported in the article. Which makes both the 57.3% Linux growth and the 12.5% Sun decline even more stunning.
What's wrong with just saying, "We fixed an exploit discovered by someone at some company in this component of the operating system." ? Need bugfixes also give information on exactly how to reproduce the bug?
They might as well. Anyone halfway competent can just decompile the patch and see exactly what's being fixed. In fact, this is generally how exploits are written even when the vendor does release detailed information about the bug.
One thing people don't seem to realize is that Deep Junior was a hell of a lot slower than Deep Blue, even though the Deep Blue match was over 5 years ago. That's because Junior was running on "ordinary" commodity hardware (8-way Xeon I think?) while Blue was a collection of hundreds of custom ASICs that do nothing but calculate chess moves. End result: Blue could search and evaluate ~200 million positions per second, while Junior as configured in this match "only" did ~3 million.
Nonetheless, Junior was almost certainly the better player. For one thing, the terms of the Deep Blue match were heavily tilted against Kasparov: he didn't get a chance to play against Deep Blue or even examine any games Deep Blue played before the match. For another, strategies of "anti-computer" chess are far more developed today than in 1997, when they barely existed (after all, the only way to build a world-class chess playing computer in 1997 was to build a supercomputer out of custom hardware). Third, Kasparov screwed up much more seriously in the 1997 match--one game he accepted a draw when he in fact had a provable win, apparently because he trusted the computer's evaluation of the position, and on several occasions he made terrible blunders.
Indeed indications are that even the normal Junior program on a decent PC plays the Kasparov-Blue games better than Blue did (except for a couple especially "brilliant" moves on Blue's part).
Not only is Junior (marginally) the best computer program available today, it is by a good measure the "most human-like". That is, it is still makes its share of "non-human" moves (although far fewer than Deep Blue), and still has no clue how to analyze certain positions, but its evaluation function has a much better understanding of position and is thus more willing to initiate complex piece exchanges than the other major programs. This showed up several times during the match, in two outstanding moves in particular (which netted come-from-behind draws for Junior in games 4 and 5).
Kasparov, by taking Junior out of its opening book, was able to exit the opening phase with the initiative in every single game. But in every game except for 1 and 6, Junior managed to draw even. In games 2 and 3, it was by virtue of outstanding tactical defense, which should have forced two draws (except that Kasparov screwed up the end of game 3 and lost). In game 5 it was with a shocking bishop sacrifice counterattack (extremely uncomputer-like) which nullified Kasparov's last turn as white (which is an advantage).
Perhaps game 4 is the best synopsis of the state of Junior's play. Kasparov played the opening perfectly according to plan, and ended up in a classic anti-computer position. Normally you can then just wait for the computer to screw up and then rip it apart. But while Junior did make a couple useless non-human moves, for the most part it played extremely well. Kasparov kept waiting to have an opportunity (perhaps too long), until finally Junior broke open the position by initiating an excellent multi-piece exchange. Kasparov had to settle for a draw.
OTOH, Junior had no idea what was going on in the endgame. Kasparov had a provable draw after move 47, but Junior, having no idea how to evaluate the position (no computer program does), thought it was winning. It played on until move 61 before the embarrassed programmers overruled the program and took the draw.
Overall, it seems that computers still have a ways to go before they can pass the Grandmaster Turing test. And it seems Kasparov really did just chicken out by accepting the draw in game 6. But the fact remains that Kasparov played quite well (for the most part) and simply couldn't convert his advantage in any game after the first. Meanwhile, while it still made a few computer-like moves that stuck out like sore thumbs, for the most part Junior played very solid chess with occasional strong speculative moves that would be aggressive even for a human.
Ok, I get you now. That article isn't a definitive debunking, but rather a quick article (it originally appeared in the Sunday Times of London, BTW, which might explain the lack of hyperlinks for instance) summarizing the debunking Moore has already recieved.
If you're really interested, I would suggest you start by looking up the works by Dan Lyons and Ben Fritz that Sullivan refers to; I would imagine they'll contain the detail you're looking for...
But I need something hard, something more than "he's wrong," and "that's obviously absurd." Once I have that about Chomsky and/or Moore, I'll have to defer the assessment that they're distorting things. In other words, innocent until proven guilty.
I'm not sure what more you're looking for. All the points brought up in the article are pretty damning IMO, but if you want proof that Moore is consciously distorting things, look again at the bits about the bank and the Bush TV ad. Remember, Bowling For Columbine is (supposedly) a documentary. Everything in it is supposed to be simply a recording of real events.
Anyone watching the movie is clearly left believing that they hand out guns at that bank and that Bush mentioned Willie Horton in that campaign ad. Both are lies. Moore had to deliberately insert these lies into his film--in the first case, by staging a fictional scene at the bank, in the second, by altering a real Bush ad. In neither case is the audience given any clue that what they saw was not actual documentary footage.
Let me add that I happen to sympathize with the points Moore is making here, before the distortions he adds in: I think it's creepy that a bank is offering a voucher for a gun (to be picked up at a gun store after a background check) as a promotion; and I think Bush I's ads on the Mass. prison furlough issue were sensationalist and meant to tap into irrational and often racist fears. But I don't think anyone can claim the changes Moore makes don't dramatically distort the actual facts and arguments at issue. And you certainly can't claim the distortions aren't deliberate.
Provide examples of Chomsky or Moore being selective in their facts. By American standards I'm fairly far to the right of both of them (I'm pro-gun, for example) but my differences with them are in their interpretation of the facts. To their credit I've found both of them to be quite reliable and unselective when it comes to the actual reporting.
Provide something more than your say-so.
Here's Andrew Sullivan's quick article debunking Bowling For Columbine. Note that this is not even a complete list of the distortions in just that particular "documentary".
...because there are no NV30s yet. It was confirmed in an NVDA conference call yesterday that NV30 has not taped out yet.
All of these previews are just PR leaks to distract from the Radeon 9700 launch. Assuming NV30 tapes out today, Nvidia will be very very hard pressed to get a card in stores by Christmas Day. They have already missed the Xmas season.
Having said that, the NV30 will be quite amazing, and (from what we know of it) should best the also-amazing Radeon 9700 by quite a bit. To be more specific: it should be better for non-realtime hardware rendering of scenes that are currently rendered in software--like those Exluna pics that were shipped out in their PR--because it has more flexible shaders (we dunno if they're faster too, but this is also likely). Yes, it will be able to render those images, in "near-realtime", though certainly not actual realtime. It should offer better texel fillrate, especially in multitexturing situations, because it has an 8x2 pipeline organization instead of 8x1 like the Radeon, and because as a.13um card it *should* achieve higher clock rates. Performance in bandwidth-bound situations depends on whether it uses 128-bit or 256-bit DDR-II; if the former, then it will have ~20% less bandwidth than the 256-bit DDR Radeon 9700, if the latter, it will have a hell of a lot more. AA/aniso performance depends both on that bandwidth question and on the particulars of the AA/aniso hardware. The Radeon's is really really good (which is why its lead over Ti4600 becomes so dramatic in AA/aniso situations), but NV30s could be that good too.
But Nvidia is desperately late with the card, and by the time they get it out ATi may have a successor to the Radeon 9700 (perhaps.13um and DDR-II) very close at hand. This is the first time in a long time that Nvidia has screwed up big time like this (in fairness, it seems more the fault of their fab partner TSMC), and it comes just as ATi is releasing a truly excellent product. Again, NV30 will still be an awesome card when its released, despite the delay, but leaking info about it now is just a way to string people along on a wait which will be longer than most realize.
And these "previews" are nothing more than rehashes of Nvidia PR pdf's; they are vague not because sharkyextreme performed any difficult investigation, but because they are simply regurgitating teaser PR for a card which doesn't even exist yet.
2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.
This was done on purpose. Current (and next-generation) GPU shader hardware is not Turing complete, so it'd be quite silly for Cg to be. The problem is that while most extensions to Cg can be added with a vendor-specific profile, extensions which would make the language more general purpose (like pointers, full flow control, etc.) are apparently considered changes to the language design and only NVidia can add them. This isn't a problem now, but it would be if another vendor came out with a more general purpose shader implementation first. (Technically it may be possible to make Cg Turing complete through the extensions NVidia has made available, but probably not in a very friendly way.)
3. The compiled bytecode is giving a security mask that disables it's use on chips that do not carry a compliment decoder (To keep competetors away?).
Well, supposedly anyone can write a compiler/interpreter for Cg bytecode to target and optimize for their hardware just like NVidia can. (Of course they would need to introduce new functionality to the language through extensions, but the point is any standard Cg bytecode should execute on any DX8+ GPU with a compiler.) Indeed, this is one of (perhaps the only) huge plus to Cg: because it can be interpreted at runtime, rather than just compiled to shader assembly at compile time, new GPUs can (assuming they have an optimizing compiler) optimize existing shader code. This will be nice, for example, in allowing the same shader bytecode to run optimized on DX8 parts (few shader instructions allowed per pass), upcoming DX9 parts (many but not unlimited instructions per pass), and probably future parts with unlimited program length shaders.
Yes, it does require the other vendors to write their own backend for Cg, but NVidia has supposedly released enough for them to do that with no disadvantages. The question is whether they will want to, given that doing so would support a language that NVidia retains control over (as opposed to MS-controlled DX and by-committee OpenGL).
6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).
Presumably this can be done via an extension, although it might get ugly to retain backwards compatability.
7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.
What about inlining shader assembly in Cg? And beyond that, what sort of inlining would you want?
Umm this question has been answered already considering there are some chips that are doing trillions of calculations a second and still we haven't been able to simulate the human brain. The problem is not really processing power. It's HOW things are processed combined with latency, bandwidth, database speed and things like that coming all together to provide what is "like" a brain.
Sort of. First off, we don't have "chips" that are capable of trillions of calculations a second; the fastest microprocessors around are capable of only a couple billion instructions per second, and it would be very charitible to say that these really count as "calculations" in any usable sort of way (particularly when it comes to AI-like workloads). Our fastest supercomputers are capable of multiple trillions of FP ops per second, but even disregarding programming complexity there are tremendous latency and topology shortcomings compared to a human brain.
Sure, modern computers have a large advantage (roughly 1 million fold) in cycle time, but they are completely overmatched in every other category of computational resources. While a modern superscalar CPU might have roughly 6-10 functional units (not all of which can operate in parallel, I might add), a human brain has on the order of 100 billion neurons. Although the analogy is not exact, synaptic connections function as a form of low-latency, high-bandwidth, adaptive-topology memory; we have 100 trillion of those, easily besting the size of any DRAM array and reaching levels of the very largest (very high-latency) disk array databases. And while this may be an unfair comparison, as conventional computers are not designed to efficiently run neural nets, the brain can (theoretically) perform around 100 trillion neuron updates per second, compared to maybe 10 million per second on a computer (not to mention that the properties of the artificial neural nets run on computers are far simpler and probably computationally inferior to those of real neurons).
Now, because our access to the brain only occurs at a very high level, we can't harness the underlying power to, for example, perform trillions of arithmetic additions per second, the way we can (well, billions) with a computer. But if something like a neural net (or even something more computer-friendly like dynamically updated decision trees or Bayesian belief networks) is necessary for the sort of adaptive, complex behavior we might expect before we claim "human-like" AI, we still have a long, long way to go even on a purely computational level.
Yes, as you said, much of this has more to do with "latency, bandwidth and database speed," but I think it's misleading to act like these restrictions are seperate from the design of current microprocessors. Latency and bandwidth within a CPU approach or beat the levels seen in the brain, but it is completely inherent in current methods of designing and manufacturing chips that they cannot scale up to anything near the size or power of the brain, and thus are doomed (for the forseeable future) to be hooked together in ways which cannot compete with the computational power of the brain. Yes, we can approach the total processing power of the brain using a "bag of chips" approach to building a supercomputer, but we are nowhere near getting that processing power in a truly unified system.
but processing power this question has been answered already and that answer is no and it hasn't had any ramifications on AI.
Now that's just untrue. Increases in processing power have had huge ramifications on AI, in the sense of getting real work done. AI techniques control bad guys in video games, allow real-time speech recognition, place and route circuits in chip design, schedule elevators in office buildings, jobs in factories, and rocket payloads, prove new mathematical theorems, assist doctors with diagnosis, and enable computers to be world champions in nearly every board game people play (except go). AI is everywhere these days, and the dramatic shift in its use from research to the real world is all to do with increasing processing power. And as processing power continues to increase, we'll see AI more and more.
Of course, if you mean that processing power hasn't yet allowed us to create human-like AI, you're quite right, for both the reasons discussed above and because we lack a sufficient understanding of how we might efficiently program human-like behavior in many arenas. But considering very few researchers in the AI community are really focusing on imitating the brain but rather on solving currently feasible problems, increases in computational power have meant a huge amount to the success of AI.
I'd be interested to your response to this comment by John Carmack to the effect that "production frames will be rendered on PC graphics cards before the end of next year. It will be for TV first, but it will show up in film eventually."
Do you agree with John that the next year or so will see hardware cards with the power and flexibility (and software tools) necessary to replace software rendering farms for many tasks? If so, do you know what companies/tools he's talking about when he says, "I had originally estimated that it would take a few years for the tools to mature to the point that they would actually be used in production work, but some companies have done some very smart things..."? If not, why not, and when (if ever) do you think hardware will be ready to take over?
What will happen will be this - eventually we will run out of oil... rather - the cost of getting more oil out of the earth will outweigh the value of the barrel of oil you could extract. I hope fervently for this day, since while everyone equates this with disaster, this will solve the vast majority of our problems.
Don't hold your breath. Just like with food and mineral resources, advances in oil "harvesting" technology continue to outpace advances in oil consumption. Indeed, the size of the world's known oil reserves--that is, the amount of oil that we know about and can extract at below-market cost--has never dropped; they continue to increase every single day, and don't show signs of stopping.
This will stop the pollution that makes me wheeze.
Oil doesn't really cause that. In particular, with modern technology, oil can be burned with quite low levels of air pollution (besides CO2). In the US, city air quality has rapidly increased in the past 40 years, and continues to do so, due to the availability of cleaner technology and the Clean Air Act pushing its use. (Similar developments in the rest of the Western world.)
Of course this doesn't mean it's ok for Bush and his cronies to try to open more loopholes in the Clean Air Act, or that air quality shouldn't be improved further. Or that America's tremendous oil usage isn't a problem: beyond the issue of CO2 production and global warming, there's the tiny issue of those hundreds of millions of Arabs whose anger and despair at being trapped under backward, corrupt, sexist, autocratic regimes has been diverted--by those same regimes--into fundamentalist hatred of America, Israel, the West, democracy, liberalism, etc., all while the US props up those same regimes because we're scared that if we don't they'll cut off our oil. And beyond the fact that they pollute and contribute to global warming out of proportion with their numbers, and increase our dependence on oil (see last sentence), SUVs are extraordinarily dangerous to the other cars on the road (as well as pedestrians, bicyclists, etc.).
However, while all these negatives to continued usage of oil will help a bit, they aren't going to rise to any sort of crisis level that will do much to lower demand for oil. At best, what they'll do is spur on a little extra effort towards developing replacement methods of generating energy, which will in turn catch on once their cost drops below that of oil. Again, this isn't going to happen because the price of oil will suddenly shoot up--if anything, it will continue to drift down as it always has (inflation adjusted)--but because they will get much cheaper as the technology gets worked out.
And this will probably happen pretty soon. Indeed, wind power is apparently the cheapest way to generate electricity for increasing swaths of the world. Solar power is getting there. And fuel cells will do so eventually, too, and without any geographical restrictions.
You are right, in that I cannot correct you in any way, but you have to admit... x86 is backward compatible with the 8086*... That may (!) not matter any more but they have done a f##king good job... Credit where it's due and all that... Don't you think?
No doubt. If it wasn't clear from my post: the fact that AMD and Intel can get almost equivalent single-CPU SPEC performance (and SPEC is oriented toward workstation/server/HPC workloads!) to the top 64-bit CPUs, despite maintaining backwards compatability with a much uglier ISA and costing ~50x less, is a huge credit to their engineering teams. As well as pretty strong proof that the fitness of your ISA is much less important than the manufacturing process you use and the engineering resources you have.
And second, while it of course no longer matters than the P4/Athlon are backwards compatible with the 8086, it mattered hugely that the 286 was, and that the 386 was compatible with the 286, and so on. Tremendously. The immense size of the x86 backwards compatible market has meant that Intel and AMD sell their CPUs in volumes large enough to make owning their own fabs (and keeping them on the cutting edge of process tech) worthwhile...which in turn is what has kept x86 performance so competitive (along with other effects from selling into such a huge market).
I bet that it could cane IA64 in the specInt but the real test would be floating point and to do IEEE754 properly you need 64 bit otherwise you end up emulating it
x86 processors have had 64-bit floating point registers (actually 80-bit) for as long as they have done native floating point. x86 does not have 64-bit integer registers; this has nothing to do with floating point.
The reason x86 has traditionally sucked at floating point is because the x87 floating point ISA only allows for a stack of 8 fp registers, instead of a flat set of 32 registers like most RISC architectures. This has been worked around to some degree in current x86 processors through the use of a flat virtual register set and good compilers, although there is only so much a compiler can do when it is limited to 8 target registers. Nowadays the continued leadership in SPECfp by 64-bit RISC chips is mostly due to higher memory bandwidth and particularly large L2/L3 caches which help a great deal with certain SPECfp subtests.
While not quite as high as its world-beating SPECint scores, the P4's SPECfp scores are still damn good, and would be even better if Intel would officially support PC1066 RDRAM (the current scores on spec.org are PC800 only). Put another way, they will be even better when Intel releases their dual-channel DDR chipset in a few months.
That said, EV7 will clearly have the SPECfp score to beat for quite some time. (Probably SPECint as well.) And Itanium2's SPECfp scores are reported to vault it well ahead of the also impressive Power4. But, again, this is all to do with higher DRAM bandwidth and larger caches, not with any inherent limitations of x86 for performing double-precision fp.
At the moment, only the new 1.0GHz Alpha EV68 chips are faster then the current P4 processors, and the Itanium and Athlon are right up there as well. The rather substatial lead in FP performance that the Alpha used to have has virtually disapeared these days when compared to x86 chips. The very fastest EV67 chips are slower then the fastest x86 chips (note: I'm using Spec CFP2000 for comparison here, if you know of any FP benchmarks that run on both platforms I'd like to hear about them).
As for the future, Alpha's time on this planet is very limited. EV7 is still supposed to come out, and I've heard from reliable sources that it should post some very impressive scores for floating point due to it's HUGE memory bandwidth. However Intel's Itanium 2 is also supposed to post some rather impressive scores (they're talking about 1300-1350 in Spec CFP2000, which would put it ahead of the current champion Power4 processors from IBM). AMD's Hammer won't be any slouch either, as it's on-chip memory controller should boost it's score quite nicely.
This is a good summary, except that ignorant slashdotters reading this might not realize how far ahead P4, Alpha, Power4 and Athlon are in front of all other CPU architectures (i.e. PA-RISC, US III, Itanium1, MIPS, and most especially G4*) in single-CPU SPEC performance. Just to be clear: Alpha's performance is still at or near the top.
* no, there's no official G4 SPEC entry (because Apple is too chicken), but c't benchmarked it and boy does it suck. SPECint performance on par with a 933 MHz PIII, and SPECfp on par with a 500 MHz one.
Second, you probably haven't seen the leaked slide of SPEC scores for the 1250 MHz EV68 (they should be official at spec.org real soon now), which put it almost precisely equal to 1.3 GHz Power4 SPEC scores, despite not having the dubious advantage of 128MB L2 cache (under normal operation the Power4 cache is shared amongst 4 or 8 cores, but for SPEC one core gets it all).
Third, EV7 will have a substantial lead in SPECfp upon release (and might briefly take SPECint as well), although there's no doubt that Power4 and P4 will continue to improve, and Itanium2 on SPECfp and Hammer on SPECint will also be contenders.
But the most shocking part of all this is that, unlike Athlon/Hammer, P4, Itanium and Power4, Alpha is achieving all this performance on someone else's standard fab process (rather than tweaking the process to fit the chip design, which is a huge huge help; compare performance of those architectures where the designer owns the fab--P4, Athlon, Power4, Itanium--to those where it doesn't--PA, MIPS, SPARC). And, unlike current Athlons, Hammer, P4s since January, and Power4, it's an old.18um process. Alpha still gives more performance with fewer engineering resources than any other chip, and EV7 will only widen the gap.
Like it or not, Alpha is dead. It's been sold many times and basically salavaged for scrap (Intel now owns most of the old Alpha technology). You're mentioning Titanic is actually quite approriate, because that was the last gasp for Alpha. If you look at new movie production, they're moving to x86, just like all the rest of the world. MIPS might have a future in the embedded space, where it's currently second to ARM. Alpha technology might have a bit of a future in Intel's IA-64 (though I'm skeptical as to how well they'll be able to integrate the pure-RISC Alpha technology into the VLIW IA-64 technology), but as a product on it's own, stick a fork in it.
Again, you're correct. But the death of Alpha is entirely to do with marketing and zero to do with performance. Before Power4, Alpha was the clear single-CPU performance leader in the 64-bit market, and if the Alpha team had gotten more resources and support from Compaq, Alpha's performance lead would still be huge.
That said, all of this seems slightly academic considering that for the past year and the forseeable future, the SPECint leader has been and will be a commodity x86 chip costing ~$600 (against 64-bit competition costing 100x that per CPU). The P4 seems to have taken on the Alpha mantle: world-beating SPEC performance with a high-clocked small-die chip utilizing innovative microarchitectural features and excellent circuit-level design. That it has done so despite being hobbled with the x86 ISA is even more impressive.
Slashdot Mirror
maybe the GeForce4 MX (and not GeForce2) was included on the minimum requirements list because it "kind of" supports Pixel Shader 1.1 (which GeForce2 lacks). I say "kind of" because the GF4 MX's T&L unit requires help from the CPU to process vertex shaders (think Winmodems).
Check your article again: that's Vertex Shaders 1.1, not Pixel Shaders.
What does surprise me is no special support for the R100 (Radeon 7xxx) series, which supported PS 1.0, and could do 3 textures per pass.
That's not my recollection, nor does the chart at Beyond3D agree with you. R1x0 seems to support fixed-function environment-mapped bump-mapping only, which is not flexible enough to implement the D3 lighting algorithm.
which path would perform better on a low end card capable of using both the NV1x path and the ARB path, such as say a GF3 Ti200
The ARB path should be faster; they both render at the same graphical level, but it takes fewer passes.
Is the Geforce 4 MX supported?
Yes. Presumably the Chronicle reporter either didn't understand or didn't want to confuse his readers by explaining that the GF4 MX has less advanced functionality than the "lower-numbered" GF3.
I know that origionally Carmak wanted to require programable shaders, is that still the case, or did he relent and support the fixed function pipline that the Geforce 4 MX line inherited from the Geforce 2?
The Doom 3 engine does not and was never conceived of as requiring general-purpose programable fragment shaders. From the beginning Carmack targeted it at the "register-combiner" fragment pipeline of the GeForce 1 (NV1x) family, which allows for restricted combinations of pixel operations but not the programmability of even the very simple PS 1.0-1.3 style shader languages introduced in DX8. (So it's something of a halfway point between the DX7- style fixed-function pixel pipeline and the DX8+ style programmable pipeline. The NV1x register-combiner pipeline did not have an analogue in the Radeon 7x00 series (R1x0) and was not exposed in DX7, so ironically Doom 3--written in OpenGL of course, so using Nvidia's proprietary extensions is allowed--will be one of the first and only games to use the technology.)
Except for some minor effects in the ARB2 (PS 2.0+ level functionality) path, Doom 3 will not be exercising any fragment level functionality that can't be done with register combiners; the only difference is the number of passes required per fragment (5 or more for NV1x in common situations; 2 or 3 for NV2x; and 1 for NV3x+ and R2x0+).
So, leaving performance--and possibly memory size limitations--out of it, Doom 3 is perfectly compatible with any NV1x card, all the way down to the GeForce 1 SDR. Of course this is like saying that you can run Windows XP on a 386; it doesn't address whether the thing is playable or not. Last I heard, id intended on including at least some GF4 MX cards on the minimum requirements list, which would indicate that a GF2 or GF2-Ultra would be even more playable (which is to say not very).
First off, I'd question your premise. Mozilla's technical achievements are impressive but not unique among high-profile OSS projects, and its marketshare is still badly lagging. Look at Apache, Linux, Perl, MySQL, KDE, Gnome. Mozilla is far from the only tremendous OSS success story.
Having said that, a few thoughts on what made Mozilla more likely to achieve success than a typical OSS project:
Finally, it's worth pointing out that as recently as a couple years ago, the Mozilla project was generally regarded as a failure. Certainly the organization and management of the project have improved tremendously since the early days, but I think the main reason the tenure of the Mozilla Foundation has been so much more successful than the Netscape/AOL days is simply that they inherited a nearly-mature product and proceeded to spend the last year polishing the hell out of it. A huge amount of the architectural heavy-lifting that has allowed Firefox to be such a great program was done three, four years ago, but it wasn't until maybe Moz Suite 1.0 two years ago that you even had and end-user product that could stand up to IE 6.
Meaning that I wouldn't dispair for other OSS projects that still trail their MS analogues. A solid technical design--which most of them have--means the opportunity for the sort of rapid improvement and polish Mozilla has received in the past couple years. Once the user base begins to move in, usability bugs follow, and from there, perhaps, things begin to snowball. (I'm looking at you, OpenOffice...)
Again, two problems with that:
1) The resulting crop was 95-98% Roundup-resistant canola. That could not have happened from the random reuse of seeds from a conventional canola field that happened to have some cross-pollination from the neighbors.
2) He wasn't found liable for damages!
The court found it likely that he specifically saved the seeds from a small area of his previous crops that proved extremely resistant to Roundup. >95% of his crop the next year was found to be Roundup-resistant. That's pretty unlikely to have been the result of him planting seeds from all parts of his land (previously planted with conventional canoloa) equally.
Nonetheless, he did not use Roundup and thereby take advantage of the GM seeds' properties, thus the court assessed no damages for his actions. They did rule that Monsanto can patent a genetic modification. That's the only real precedent of the case and the only real issue anyone can argue with IMO. Assuming you grant the patent, the fact that a hypothetical farmer who purposely harvested wind-blown GM seeds and took advantage of their properties without paying the patent owner would be liable for infringement seems unremarkable to me.
Their seed ended up on his land through no fault of his, yet they claim they have a right to be paid license fees or to force him to spend his time and money removing corn derived from their migrating seed.
This version of events was determined to be false by the trial court, and that decision was upheld by the Supreme Court. Instead they found that he had saved seed that he knew was Monsanto-patented, (genetically modified to resist Roundup herbicide) and planted it without paying them a license fee.
No damages were assessed, however, because the court found that he did not accrue any extra profit as a result of using the genetically modified canola seed as opposed to regular canola. The reason being that he didn't take advantage of the invention because he didn't use Roundup and therefore had no way of making extra profit based on the patented bits.
(Also, for what it's worth, the case concerned canola, not corn.)
Basically, the only way you can view the Schmeiser decision as unfairly pro-Monsanto is if you believe that genetic modifications should be inherently unpatentable. (Which is not necessarily a silly position--I'm not sure I don't think that.)
Or if you are ignorant of the true facts of the case.
I think it's safe to assume that a large chunk of the remaining .71B is IBM iSeries nee AS/400 and that there are some other minor issues like a few remaining dribs of proprietary file and print NOS and so on.
Ah--OS/400 (or whatever they call it these days). That's what I was missing.
With that in place the numbers make much more sense.
There's a much more detailed summary of the Gartner report up at com.com. The overall numbers are thus:
Total WW Q1 server revenue: $11.81 billion, +9.3% quarter-on-quarter*
That breaks down into:
Windows: $4.13 billion, +19.5%
Proprietary Unix: $4.02 billion, -2%
Mainframe: $1.7 billion, +12%
Linux: $1.02 billion, +57.3%
That leaves $.94 billion unaccounted for; I was thinking this chunk could be VMS and NSK revenues, but that makes it difficult to fit HP's 32.5% share of x86 revenues into the $.94 billion left over when you subtract it plus HP's $1.17 billion in proprietary Unix sales from HP's $3.07 billion total sales. (And that's ignoring HP's Q1 IA64 sales, which were very substantial.)
Of course all these questions are surely answered in the report itself, but I'm not gonna pay 95 bucks to find out.
*How do I know the figures in the com.com article are QoQ and not YoY? Because the Gartner summary (linked above) puts overall YoY revenue growth at 24.1%, not the 9.3% reported in the article. Which makes both the 57.3% Linux growth and the 12.5% Sun decline even more stunning.
What's wrong with just saying, "We fixed an exploit discovered by someone at some company in this component of the operating system." ? Need bugfixes also give information on exactly how to reproduce the bug?
They might as well. Anyone halfway competent can just decompile the patch and see exactly what's being fixed. In fact, this is generally how exploits are written even when the vendor does release detailed information about the bug.
One thing people don't seem to realize is that Deep Junior was a hell of a lot slower than Deep Blue, even though the Deep Blue match was over 5 years ago. That's because Junior was running on "ordinary" commodity hardware (8-way Xeon I think?) while Blue was a collection of hundreds of custom ASICs that do nothing but calculate chess moves. End result: Blue could search and evaluate ~200 million positions per second, while Junior as configured in this match "only" did ~3 million.
Nonetheless, Junior was almost certainly the better player. For one thing, the terms of the Deep Blue match were heavily tilted against Kasparov: he didn't get a chance to play against Deep Blue or even examine any games Deep Blue played before the match. For another, strategies of "anti-computer" chess are far more developed today than in 1997, when they barely existed (after all, the only way to build a world-class chess playing computer in 1997 was to build a supercomputer out of custom hardware). Third, Kasparov screwed up much more seriously in the 1997 match--one game he accepted a draw when he in fact had a provable win, apparently because he trusted the computer's evaluation of the position, and on several occasions he made terrible blunders.
Indeed indications are that even the normal Junior program on a decent PC plays the Kasparov-Blue games better than Blue did (except for a couple especially "brilliant" moves on Blue's part).
Not only is Junior (marginally) the best computer program available today, it is by a good measure the "most human-like". That is, it is still makes its share of "non-human" moves (although far fewer than Deep Blue), and still has no clue how to analyze certain positions, but its evaluation function has a much better understanding of position and is thus more willing to initiate complex piece exchanges than the other major programs. This showed up several times during the match, in two outstanding moves in particular (which netted come-from-behind draws for Junior in games 4 and 5).
Kasparov, by taking Junior out of its opening book, was able to exit the opening phase with the initiative in every single game. But in every game except for 1 and 6, Junior managed to draw even. In games 2 and 3, it was by virtue of outstanding tactical defense, which should have forced two draws (except that Kasparov screwed up the end of game 3 and lost). In game 5 it was with a shocking bishop sacrifice counterattack (extremely uncomputer-like) which nullified Kasparov's last turn as white (which is an advantage).
Perhaps game 4 is the best synopsis of the state of Junior's play. Kasparov played the opening perfectly according to plan, and ended up in a classic anti-computer position. Normally you can then just wait for the computer to screw up and then rip it apart. But while Junior did make a couple useless non-human moves, for the most part it played extremely well. Kasparov kept waiting to have an opportunity (perhaps too long), until finally Junior broke open the position by initiating an excellent multi-piece exchange. Kasparov had to settle for a draw.
OTOH, Junior had no idea what was going on in the endgame. Kasparov had a provable draw after move 47, but Junior, having no idea how to evaluate the position (no computer program does), thought it was winning. It played on until move 61 before the embarrassed programmers overruled the program and took the draw.
Overall, it seems that computers still have a ways to go before they can pass the Grandmaster Turing test. And it seems Kasparov really did just chicken out by accepting the draw in game 6. But the fact remains that Kasparov played quite well (for the most part) and simply couldn't convert his advantage in any game after the first. Meanwhile, while it still made a few computer-like moves that stuck out like sore thumbs, for the most part Junior played very solid chess with occasional strong speculative moves that would be aggressive even for a human.
Ok, I get you now. That article isn't a definitive debunking, but rather a quick article (it originally appeared in the Sunday Times of London, BTW, which might explain the lack of hyperlinks for instance) summarizing the debunking Moore has already recieved.
If you're really interested, I would suggest you start by looking up the works by Dan Lyons and Ben Fritz that Sullivan refers to; I would imagine they'll contain the detail you're looking for...
But I need something hard, something more than "he's wrong," and "that's obviously absurd." Once I have that about Chomsky and/or Moore, I'll have to defer the assessment that they're distorting things. In other words, innocent until proven guilty.
I'm not sure what more you're looking for. All the points brought up in the article are pretty damning IMO, but if you want proof that Moore is consciously distorting things, look again at the bits about the bank and the Bush TV ad. Remember, Bowling For Columbine is (supposedly) a documentary. Everything in it is supposed to be simply a recording of real events.
Anyone watching the movie is clearly left believing that they hand out guns at that bank and that Bush mentioned Willie Horton in that campaign ad. Both are lies. Moore had to deliberately insert these lies into his film--in the first case, by staging a fictional scene at the bank, in the second, by altering a real Bush ad. In neither case is the audience given any clue that what they saw was not actual documentary footage.
Let me add that I happen to sympathize with the points Moore is making here, before the distortions he adds in: I think it's creepy that a bank is offering a voucher for a gun (to be picked up at a gun store after a background check) as a promotion; and I think Bush I's ads on the Mass. prison furlough issue were sensationalist and meant to tap into irrational and often racist fears. But I don't think anyone can claim the changes Moore makes don't dramatically distort the actual facts and arguments at issue. And you certainly can't claim the distortions aren't deliberate.
Provide examples of Chomsky or Moore being selective in their facts. By American standards I'm fairly far to the right of both of them (I'm pro-gun, for example) but my differences with them are in their interpretation of the facts. To their credit I've found both of them to be quite reliable and unselective when it comes to the actual reporting.
Provide something more than your say-so.
Here's Andrew Sullivan's quick article debunking Bowling For Columbine. Note that this is not even a complete list of the distortions in just that particular "documentary".
...because there are no NV30s yet. It was confirmed in an NVDA conference call yesterday that NV30 has not taped out yet.
.13um card it *should* achieve higher clock rates. Performance in bandwidth-bound situations depends on whether it uses 128-bit or 256-bit DDR-II; if the former, then it will have ~20% less bandwidth than the 256-bit DDR Radeon 9700, if the latter, it will have a hell of a lot more. AA/aniso performance depends both on that bandwidth question and on the particulars of the AA/aniso hardware. The Radeon's is really really good (which is why its lead over Ti4600 becomes so dramatic in AA/aniso situations), but NV30s could be that good too.
.13um and DDR-II) very close at hand. This is the first time in a long time that Nvidia has screwed up big time like this (in fairness, it seems more the fault of their fab partner TSMC), and it comes just as ATi is releasing a truly excellent product. Again, NV30 will still be an awesome card when its released, despite the delay, but leaking info about it now is just a way to string people along on a wait which will be longer than most realize.
All of these previews are just PR leaks to distract from the Radeon 9700 launch. Assuming NV30 tapes out today, Nvidia will be very very hard pressed to get a card in stores by Christmas Day. They have already missed the Xmas season.
Having said that, the NV30 will be quite amazing, and (from what we know of it) should best the also-amazing Radeon 9700 by quite a bit. To be more specific: it should be better for non-realtime hardware rendering of scenes that are currently rendered in software--like those Exluna pics that were shipped out in their PR--because it has more flexible shaders (we dunno if they're faster too, but this is also likely). Yes, it will be able to render those images, in "near-realtime", though certainly not actual realtime. It should offer better texel fillrate, especially in multitexturing situations, because it has an 8x2 pipeline organization instead of 8x1 like the Radeon, and because as a
But Nvidia is desperately late with the card, and by the time they get it out ATi may have a successor to the Radeon 9700 (perhaps
And these "previews" are nothing more than rehashes of Nvidia PR pdf's; they are vague not because sharkyextreme performed any difficult investigation, but because they are simply regurgitating teaser PR for a card which doesn't even exist yet.
2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.
This was done on purpose. Current (and next-generation) GPU shader hardware is not Turing complete, so it'd be quite silly for Cg to be. The problem is that while most extensions to Cg can be added with a vendor-specific profile, extensions which would make the language more general purpose (like pointers, full flow control, etc.) are apparently considered changes to the language design and only NVidia can add them. This isn't a problem now, but it would be if another vendor came out with a more general purpose shader implementation first. (Technically it may be possible to make Cg Turing complete through the extensions NVidia has made available, but probably not in a very friendly way.)
3. The compiled bytecode is giving a security mask that disables it's use on chips that do not carry a compliment decoder (To keep competetors away?).
Well, supposedly anyone can write a compiler/interpreter for Cg bytecode to target and optimize for their hardware just like NVidia can. (Of course they would need to introduce new functionality to the language through extensions, but the point is any standard Cg bytecode should execute on any DX8+ GPU with a compiler.) Indeed, this is one of (perhaps the only) huge plus to Cg: because it can be interpreted at runtime, rather than just compiled to shader assembly at compile time, new GPUs can (assuming they have an optimizing compiler) optimize existing shader code. This will be nice, for example, in allowing the same shader bytecode to run optimized on DX8 parts (few shader instructions allowed per pass), upcoming DX9 parts (many but not unlimited instructions per pass), and probably future parts with unlimited program length shaders.
Yes, it does require the other vendors to write their own backend for Cg, but NVidia has supposedly released enough for them to do that with no disadvantages. The question is whether they will want to, given that doing so would support a language that NVidia retains control over (as opposed to MS-controlled DX and by-committee OpenGL).
6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).
Presumably this can be done via an extension, although it might get ugly to retain backwards compatability.
7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.
What about inlining shader assembly in Cg? And beyond that, what sort of inlining would you want?
Umm this question has been answered already considering there are some chips that are doing trillions of calculations a second and still we haven't been able to simulate the human brain. The problem is not really processing power. It's HOW things are processed combined with latency, bandwidth, database speed and things like that coming all together to provide what is "like" a brain.
Sort of. First off, we don't have "chips" that are capable of trillions of calculations a second; the fastest microprocessors around are capable of only a couple billion instructions per second, and it would be very charitible to say that these really count as "calculations" in any usable sort of way (particularly when it comes to AI-like workloads). Our fastest supercomputers are capable of multiple trillions of FP ops per second, but even disregarding programming complexity there are tremendous latency and topology shortcomings compared to a human brain.
Sure, modern computers have a large advantage (roughly 1 million fold) in cycle time, but they are completely overmatched in every other category of computational resources. While a modern superscalar CPU might have roughly 6-10 functional units (not all of which can operate in parallel, I might add), a human brain has on the order of 100 billion neurons. Although the analogy is not exact, synaptic connections function as a form of low-latency, high-bandwidth, adaptive-topology memory; we have 100 trillion of those, easily besting the size of any DRAM array and reaching levels of the very largest (very high-latency) disk array databases. And while this may be an unfair comparison, as conventional computers are not designed to efficiently run neural nets, the brain can (theoretically) perform around 100 trillion neuron updates per second, compared to maybe 10 million per second on a computer (not to mention that the properties of the artificial neural nets run on computers are far simpler and probably computationally inferior to those of real neurons).
Now, because our access to the brain only occurs at a very high level, we can't harness the underlying power to, for example, perform trillions of arithmetic additions per second, the way we can (well, billions) with a computer. But if something like a neural net (or even something more computer-friendly like dynamically updated decision trees or Bayesian belief networks) is necessary for the sort of adaptive, complex behavior we might expect before we claim "human-like" AI, we still have a long, long way to go even on a purely computational level.
Yes, as you said, much of this has more to do with "latency, bandwidth and database speed," but I think it's misleading to act like these restrictions are seperate from the design of current microprocessors. Latency and bandwidth within a CPU approach or beat the levels seen in the brain, but it is completely inherent in current methods of designing and manufacturing chips that they cannot scale up to anything near the size or power of the brain, and thus are doomed (for the forseeable future) to be hooked together in ways which cannot compete with the computational power of the brain. Yes, we can approach the total processing power of the brain using a "bag of chips" approach to building a supercomputer, but we are nowhere near getting that processing power in a truly unified system.
but processing power this question has been answered already and that answer is no and it hasn't had any ramifications on AI.
Now that's just untrue. Increases in processing power have had huge ramifications on AI, in the sense of getting real work done. AI techniques control bad guys in video games, allow real-time speech recognition, place and route circuits in chip design, schedule elevators in office buildings, jobs in factories, and rocket payloads, prove new mathematical theorems, assist doctors with diagnosis, and enable computers to be world champions in nearly every board game people play (except go). AI is everywhere these days, and the dramatic shift in its use from research to the real world is all to do with increasing processing power. And as processing power continues to increase, we'll see AI more and more.
Of course, if you mean that processing power hasn't yet allowed us to create human-like AI, you're quite right, for both the reasons discussed above and because we lack a sufficient understanding of how we might efficiently program human-like behavior in many arenas. But considering very few researchers in the AI community are really focusing on imitating the brain but rather on solving currently feasible problems, increases in computational power have meant a huge amount to the success of AI.
I'd be interested to your response to this comment by John Carmack to the effect that "production frames will be rendered on PC graphics cards before the end of next year. It will be for TV first, but it will show up in film eventually."
Do you agree with John that the next year or so will see hardware cards with the power and flexibility (and software tools) necessary to replace software rendering farms for many tasks? If so, do you know what companies/tools he's talking about when he says, "I had originally estimated that it would take a few years for the tools to mature to the point that they would actually be used in production work, but some companies have done some very smart things..."? If not, why not, and when (if ever) do you think hardware will be ready to take over?
What will happen will be this - eventually we will run out of oil... rather - the cost of getting more oil out of the earth will outweigh the value of the barrel of oil you could extract. I hope fervently for this day, since while everyone equates this with disaster, this will solve the vast majority of our problems.
Don't hold your breath. Just like with food and mineral resources, advances in oil "harvesting" technology continue to outpace advances in oil consumption. Indeed, the size of the world's known oil reserves--that is, the amount of oil that we know about and can extract at below-market cost--has never dropped; they continue to increase every single day, and don't show signs of stopping.
This will stop the pollution that makes me wheeze.
Oil doesn't really cause that. In particular, with modern technology, oil can be burned with quite low levels of air pollution (besides CO2). In the US, city air quality has rapidly increased in the past 40 years, and continues to do so, due to the availability of cleaner technology and the Clean Air Act pushing its use. (Similar developments in the rest of the Western world.)
Of course this doesn't mean it's ok for Bush and his cronies to try to open more loopholes in the Clean Air Act, or that air quality shouldn't be improved further. Or that America's tremendous oil usage isn't a problem: beyond the issue of CO2 production and global warming, there's the tiny issue of those hundreds of millions of Arabs whose anger and despair at being trapped under backward, corrupt, sexist, autocratic regimes has been diverted--by those same regimes--into fundamentalist hatred of America, Israel, the West, democracy, liberalism, etc., all while the US props up those same regimes because we're scared that if we don't they'll cut off our oil. And beyond the fact that they pollute and contribute to global warming out of proportion with their numbers, and increase our dependence on oil (see last sentence), SUVs are extraordinarily dangerous to the other cars on the road (as well as pedestrians, bicyclists, etc.).
However, while all these negatives to continued usage of oil will help a bit, they aren't going to rise to any sort of crisis level that will do much to lower demand for oil. At best, what they'll do is spur on a little extra effort towards developing replacement methods of generating energy, which will in turn catch on once their cost drops below that of oil. Again, this isn't going to happen because the price of oil will suddenly shoot up--if anything, it will continue to drift down as it always has (inflation adjusted)--but because they will get much cheaper as the technology gets worked out.
And this will probably happen pretty soon. Indeed, wind power is apparently the cheapest way to generate electricity for increasing swaths of the world. Solar power is getting there. And fuel cells will do so eventually, too, and without any geographical restrictions.
Peter Norvig on the benefits of the Microsoft Powerpoint Autocontent Wizard.
You are right, in that I cannot correct you in any way, but you have to admit... x86 is backward compatible with the 8086*... That may (!) not matter any more but they have done a f##king good job... Credit where it's due and all that... Don't you think?
No doubt. If it wasn't clear from my post: the fact that AMD and Intel can get almost equivalent single-CPU SPEC performance (and SPEC is oriented toward workstation/server/HPC workloads!) to the top 64-bit CPUs, despite maintaining backwards compatability with a much uglier ISA and costing ~50x less, is a huge credit to their engineering teams. As well as pretty strong proof that the fitness of your ISA is much less important than the manufacturing process you use and the engineering resources you have.
And second, while it of course no longer matters than the P4/Athlon are backwards compatible with the 8086, it mattered hugely that the 286 was, and that the 386 was compatible with the 286, and so on. Tremendously. The immense size of the x86 backwards compatible market has meant that Intel and AMD sell their CPUs in volumes large enough to make owning their own fabs (and keeping them on the cutting edge of process tech) worthwhile...which in turn is what has kept x86 performance so competitive (along with other effects from selling into such a huge market).
I bet that it could cane IA64 in the specInt but the real test would be floating point and to do IEEE754 properly you need 64 bit otherwise you end up emulating it
x86 processors have had 64-bit floating point registers (actually 80-bit) for as long as they have done native floating point. x86 does not have 64-bit integer registers; this has nothing to do with floating point.
The reason x86 has traditionally sucked at floating point is because the x87 floating point ISA only allows for a stack of 8 fp registers, instead of a flat set of 32 registers like most RISC architectures. This has been worked around to some degree in current x86 processors through the use of a flat virtual register set and good compilers, although there is only so much a compiler can do when it is limited to 8 target registers. Nowadays the continued leadership in SPECfp by 64-bit RISC chips is mostly due to higher memory bandwidth and particularly large L2/L3 caches which help a great deal with certain SPECfp subtests.
While not quite as high as its world-beating SPECint scores, the P4's SPECfp scores are still damn good, and would be even better if Intel would officially support PC1066 RDRAM (the current scores on spec.org are PC800 only). Put another way, they will be even better when Intel releases their dual-channel DDR chipset in a few months.
That said, EV7 will clearly have the SPECfp score to beat for quite some time. (Probably SPECint as well.) And Itanium2's SPECfp scores are reported to vault it well ahead of the also impressive Power4. But, again, this is all to do with higher DRAM bandwidth and larger caches, not with any inherent limitations of x86 for performing double-precision fp.
Theres not a single good java app for peer to peer, name one.
Err...Limewire??
At the moment, only the new 1.0GHz Alpha EV68 chips are faster then the current P4 processors, and the Itanium and Athlon are right up there as well. The rather substatial lead in FP performance that the Alpha used to have has virtually disapeared these days when compared to x86 chips. The very fastest EV67 chips are slower then the fastest x86 chips (note: I'm using Spec CFP2000 for comparison here, if you know of any FP benchmarks that run on both platforms I'd like to hear about them).
.18um process. Alpha still gives more performance with fewer engineering resources than any other chip, and EV7 will only widen the gap.
As for the future, Alpha's time on this planet is very limited. EV7 is still supposed to come out, and I've heard from reliable sources that it should post some very impressive scores for floating point due to it's HUGE memory bandwidth. However Intel's Itanium 2 is also supposed to post some rather impressive scores (they're talking about 1300-1350 in Spec CFP2000, which would put it ahead of the current champion Power4 processors from IBM). AMD's Hammer won't be any slouch either, as it's on-chip memory controller should boost it's score quite nicely.
This is a good summary, except that ignorant slashdotters reading this might not realize how far ahead P4, Alpha, Power4 and Athlon are in front of all other CPU architectures (i.e. PA-RISC, US III, Itanium1, MIPS, and most especially G4*) in single-CPU SPEC performance. Just to be clear: Alpha's performance is still at or near the top.
* no, there's no official G4 SPEC entry (because Apple is too chicken), but c't benchmarked it and boy does it suck. SPECint performance on par with a 933 MHz PIII, and SPECfp on par with a 500 MHz one.
Second, you probably haven't seen the leaked slide of SPEC scores for the 1250 MHz EV68 (they should be official at spec.org real soon now), which put it almost precisely equal to 1.3 GHz Power4 SPEC scores, despite not having the dubious advantage of 128MB L2 cache (under normal operation the Power4 cache is shared amongst 4 or 8 cores, but for SPEC one core gets it all).
Third, EV7 will have a substantial lead in SPECfp upon release (and might briefly take SPECint as well), although there's no doubt that Power4 and P4 will continue to improve, and Itanium2 on SPECfp and Hammer on SPECint will also be contenders.
But the most shocking part of all this is that, unlike Athlon/Hammer, P4, Itanium and Power4, Alpha is achieving all this performance on someone else's standard fab process (rather than tweaking the process to fit the chip design, which is a huge huge help; compare performance of those architectures where the designer owns the fab--P4, Athlon, Power4, Itanium--to those where it doesn't--PA, MIPS, SPARC). And, unlike current Athlons, Hammer, P4s since January, and Power4, it's an old
Like it or not, Alpha is dead. It's been sold many times and basically salavaged for scrap (Intel now owns most of the old Alpha technology). You're mentioning Titanic is actually quite approriate, because that was the last gasp for Alpha. If you look at new movie production, they're moving to x86, just like all the rest of the world. MIPS might have a future in the embedded space, where it's currently second to ARM. Alpha technology might have a bit of a future in Intel's IA-64 (though I'm skeptical as to how well they'll be able to integrate the pure-RISC Alpha technology into the VLIW IA-64 technology), but as a product on it's own, stick a fork in it.
Again, you're correct. But the death of Alpha is entirely to do with marketing and zero to do with performance. Before Power4, Alpha was the clear single-CPU performance leader in the 64-bit market, and if the Alpha team had gotten more resources and support from Compaq, Alpha's performance lead would still be huge.
That said, all of this seems slightly academic considering that for the past year and the forseeable future, the SPECint leader has been and will be a commodity x86 chip costing ~$600 (against 64-bit competition costing 100x that per CPU). The P4 seems to have taken on the Alpha mantle: world-beating SPEC performance with a high-clocked small-die chip utilizing innovative microarchitectural features and excellent circuit-level design. That it has done so despite being hobbled with the x86 ISA is even more impressive.