Yeah, maybe my initial assumptions were poor (specific to the Quadroo/PC performance). I was trying to make some points about the importance of I/O performance to the original poster, and perhaps got a little out of my element in discussing state-o-the-art PC equipment. I confess I just got the system last Thursday, and haven't tweeked it or ran any 'formal' comparisons yet, it's just an overall feel.
It is amazing how software has managed to soak up a 100x speedup in CPU performance...;-)
There is a wide range in I/O performance, and I'm sure your machine would benefit from a level 0 RAID array with 15,000 RPM drives on a SCSI-3 controller.;-) Unfortunately, that is still a fairly expensive (factory) option, though you could do it yourself under $1000 (dual 36 GB IBM drives would be under $600, plus $200-$400 for controller). Might well be worth it.
Unfortunately, we have a TechOps group that gives us these machines, and if you check MCAD company stock prices, you'll see that our managers are in no mood to spend extra money on replacement equipment. I agree that nVidia should supply a fix pretty quickly, given that this is software and not hardware related.
One thing I'd try is downloading the latest drivers directly off NVIDIA's site, if you haven't already.
Me too. Better yet, I wish that more CAD companies in general would get a clue and port to Linux; PTC is too little too late. I'll whisper to you that at least one of the big MCAD companies experimented with a Linux port, but abandoned it for shortsighted management reasons. A Opteron/Linux/(Catia/I-deas/Unigraphics) combi would be pretty suhweet.
I'm sure it'll happen at some point, because Linux is simply better at a fundamental level (not designed by marketer/lawyers).
That's one reason I like NVIDIA - it has provided great (although binary only) drivers for Linux for some time, for all it's cards. Also, NVIDIA is widely recognized as having some of the best OpenGL drivers available, both on Linux and Windows.
By the way, on AMD/Opteron I wish I had the resources to start a new computer company ala Dell. I'd bet it'd be possible to strike up a relationship with AMD (special discounts) to launch an AMD-only brand to take on the "Intel Inside" campaign. I think the Hammers will be good enough that unless Dell adopts them as well (quite possible) there will be a giant market opportunity there.
If Dell adopts Hammer, I hope I'm holding a lot of AMD stock.;-)
Anyway, thanks for pointing these things out, and thanks for not flaming me to death a-la the typical Slashbot;-).
I just got the sense that something might be misconfigured. It also sounds like you could use more RAM.
It's a 2GB machine. HP Cad workstation, HP factory memory.
RDRAM? Is it a Xeon system? One point might be that you could go dual Xeon as well...
Is it maxxed out on RAM? I think some P4 setups can go to at least 3 GB.
Quadro Pro card, very similar specs to the 4, someone down the hall _has_ a Quadro4, they don't touch the Visualize cards.
What is the amount of on-card RAM in each case?
I must say I'd be somewhat surprised to learn that the Quadros can't beat pretty much any older technology (forgetting about exotic features like greater than 32 bit color or lots of hardware overlay planes).
Admittedly, I might have been wrong about the price of the card--I think still that the Quadro4s top out at ~$1k, which is still pretty low in the card arena.
Prices have been dropping like rocks in many PC areas. For instance, CPUs used to top out at over $1000, but now its less than half that.
It's crap in any case, IMHO. nVidia needs to stick to Quake.
Lots of people feel otherwise. Lets see how NV30 (and related professional products) do. That is supposed to be a greater than 2x speedup over GeForce 4 products.
Incidentally, there are gigantic known field problems with the whole Quadro line.
Quadro 2 or 4?
There's a problem with memory access (>1 GB models) that causes huge problems in high end CAD packages.
I'm surprised if NVIDIA couldn't address this quickly.
Most people don't really get it when I say "high end mcad". We're talking Ford engine blocks, Toyota trannies, etc. BFMs. This isn't designing little floor plans with AutoCAD 2000.
Yes. I hope that Hammer/Opteron kills Intel in this market. NVIDIA will be right there as well.:-)
Of course, for most people, we're close to that point where chip-speed stops mattering... (maybe 1-2 more cycles of Moore's Law ought to do it.) How many people think about the speed of their computer while surfing, emailing, word-processing, or any such thing?
Yes, because the rate of software innovation has slowed so.
However, a paradigm shift will come (other than Quake that is;) and suddenly we'll need all the extra performance. Natural speech recognition, for instance, might be such a shift. Ironically, the last demo I saw was on a G4 Powerbook, but it looks to me as though the voice dictation product are finally getting usable for most people, with a *fast enough machine*.
I'd love (as I've stated in previous posts) for Apple to support at least the new x86-64 chips from AMD. That would differentiate them from everyday 32 bit systems, and provide world class performance to boot. Plus, Apple would have a new "64 bit" ad campaign.
Cool, eh?;-)
(I know, I know, it's a cliche, but cliches are cliches because they're _true_.)
Except, of course, when they're wrong.;-)
I'm reminded of an old statement out of IBM (paraphrased): "The worldwide market for computers is around ten machines."
My main PC until last week was a 550Mhz P3 Xeon, with a SCSI subsystem and a Visualize FX graphics card. Now, the lease being up on my old system, I have a 2 Ghz P4 with an IDE drive and a $300 nVidia card. GIVE ME BACK MY OLD PC. Disk swapping alone is killing me; with the disk work shifted to the processor, I'm doing so much foot tapping it's just silly.
Wow, where to start...
First, how much memory do you have in the box? Doing CAD work you should load the boat, 1 GB minimum. Disk swapping should be eliminated.
Your 2 GHz. P4 should be at least 3x faster than the 550 P3. What memory type does it use?
Personally, I favor AMD CPUs in general, but I do know some CAD packages don't officially support AMD.
Don't get me started on the video card. Even regular GUI rendering is slower, much less 20k surface geometry.
Did it occur to you to use a professional graphics card for your professional app? The consumer drivers/cards don't accelerate things like antialiased line drawing. Swap out your current card for a Quadro4, you'll be glad you did. (I don't know why you're getting slow screen redraws with the consumer card though, my Athlon with a GeForce 3 is lightning fast).
In short, you still have to have a bit of a clue in order to get optimum system performance.
I can neither confirm nor deny that I'm smoking anything.;-)
I'm working on a Torque project, on Linux, as we speak. The engine has had Linux support pretty much from the start.
Er, I read this, which clearly says "Linux server, Linux client under development". Sorry if I got it wrong, I was just going by the website. Its good to hear that the Linux client is further along than that!:-)
"database busy, please try back in a few minutes.
do not hit refresh it will only complicate the problem, thanks GG"
Looks like lots of Slashdotters are signing up...I will be as soon as I get the chance!
What a great looking product for such a low price! I agree with GG that this should lead to some real innovation (for a change) and will also let some new game development stars emerge who wouldn't have had the budget otherwise. AWESOME!
Also, Slashfolk, don't miss the fact that this engine uses open technologies (OpenGL/OpenAL), is already available on Windows and Mac, and a Linux client is in the works.
Too cool, I can't wait to get them my $100 so I can start playing... =)
(BTW on the id issue - give it a rest. I suspect id prefers to not have the support hassles this would entail...id is making plenty of money already!)
notice that they also asked that research not be put under GPL-like licenses, under the assumption that government-funded research should be resold afterwards... personally, i don't appreciate giving money to the government, in the form of taxes, and then having to buy back from them what they discovered thanks to my money...
I don't think that's the correct interpretation.
I hate to find myself defending Microsoft and it's allies, but I think the main problem they have is that GPL'd software can't be commercially sold or incorporated in commercial software.
I have to agree that the best license for software developed on the public nickel should be something like: "This software may be freely used by any (American citizen? / one?) for any legal purpose. There is no warranty whatever."
Don't get me wrong. I think 64 bit is likely to be at least as important a step as 32 bit was c. 20 years ago, however I don't expect more than a small niche for such systems until resource allocation is re-thought.
Don't forget that the 64-bit data will be coming from a wide memory bus, so there is essentially no extra overhead for getting 64 bits at a time. For many data structures (for instance an array of 32 bit integers) there is no additional overhead.
However, your basic point is right, just as it was for a doubly linked list of shorts on a 32-bit architecture. Larger pointers, and some level of data bloat (ints will now be 64 bits, for instance) are to be expected.
So, it is not so much that "resource reallocation must be rethought", it is simply that many applications don't yet need 64-bit power. The immediate adopters will be areas like scientific processing/visualization, CAD/CAM/CAE and large databases (this is the enterprise server role AMD is hoping Opteron nails). CAD users have been hard up against current addressing limits, and will welcome the ability to handle larger models. A little extra bloat is in the noise, especially since the whole point is to address massive amounts of RAM. The SUSE implementation allows 512 GB of virtual address space per process, for instance. Hammer's SMP capabilties and scalable memory architecture are just more icing on the cake.
"Normal" users can buy Hammer systems and run 32-bit software/OSes just fine (faster than any P4), then upgrade to 64 bits when they need it. People will find ways to use all that power, natural speech interfaces come to mind. Games will probably push the 4 GB barrier sooner than you'd think as well.
By the way, the claim is that 64-bit code for the Hammer will run 30% faster than the equivalent 32-bit code. This is due to x86-64 having more general purpose registers among other things.
I think that x86-64 is a brilliant move on the part of AMD, and if Hammer performs as advertised AMD will take major marketshare and profits from Intel. I can't wait to get my hands on a system, myself.:-)
I mean, come on people, it's apples and oranges here. Two similar tools for two VERY different purposes. Rendering 80 FPS at 1600x1200 makes good games, but I doubt there will ever be a day when film frames are rendered in real-time. There's just no reason to!
Reason 1: To play games with film-quality graphics (or near enough as makes no difference).
Reason 2: Great looking real-time architectural walkthroughs, CAD renderings and so on.
Reason 3: To render 100 or more times as many frames per unit time in the film render farm.
All of those reasons seem pretty compelling to me!
I suspect you'll be changing your tune when you see what the R300 and NV30 can do...:-)
The only problem with this idea is that StarOffice-- as anybody who has actually tried to use it in a business setting knows-- isn't "just as good as" or "a suitable replacement for" MS Office.
How so? I'm working with a small company right now that's already committed to switching all new computer users to Star Office. They are open to desktop Linux on some desktops as well. This is a technical company, and the CEO (PhD. physicist) was quite impressed when he imported a Word document and all the formulas came through flawlessly.
They figure they'll have one workstation with Office for document export, when HTML or PDF isn't sufficient.
Microsoft pricing has finally gotten far enough out of sync with small business budgets, that I think you'll see quite a few switching. Sun made a smart move charging a nominal price, now businesses are starting to see Star Office as a serious product.
The RIAA has anounced that it's website is under attack by hackers. "It appears that a large group of anarchists from a site called 'Slashdot' are attempting to overload our massive dual-386 webserver by repeatedly accessing our site. We have notified the FBI and will prosecute to the fullest extent of the law, using the DMCA, Patriot Act and whatever other legislation we can push through a clueless Congress."
I vote for high-performance Java, personally (with further extensions for better performance like lightweight objects [no inheritance but very little overhead for things like complex numbers], immortal [static] objects and a good generics implementation). I'd also like to see a very flexible and extensible operator overloading functionality, as well as the ability to use Unicode in Java source as an optional extension, for both variables and operators.
Also don't forget that gcc 3.x now includes a Java front end...perfect for extending into numerical Java. It's especially appropriate since it is a traditional "ahead of time" compiler permitting full optimization.
IBM has already provided matrix libraries written in Java with about 80% of the performance of fully optimized FORTRAN. Another interesting library is the Colt Library. It is also possible, using JNI and DirectIO, to use legacy libraries efficiently from Java where appropriate.
The focal point for numerical Java is Java Grande.
BTW, I was sorry to miss the Java 3 discussion yesterday, but this post summarizes my desires in that area. Quite a bit different from those of the article's author (what a whiner that guy was!).
At any rate, FORTRAN is still alive and kicking, and will be for another hundred years I'm sure...;-)
I hope new development is mostly being done in Java in the not too distant future, though!
wasn't there a report out recently that claimed something like 15,000 cancer deaths were probably caused by above ground nuke tests worldwide? (i seem to vaguely recall something along those lines)
Even if that is so, we'd still need a major nuclear war to equal the cancer caused by smoking (not to mention alcohol, pollution, natural radiation and fatty foods).
No, we really don't need to introduce more causes of cancer into the environment, BUT let's keep things in perspective. 15,000 deaths over 30+ years is miniscule in terms of global cancer death rates.
Damage to the ozone layer (as well as worsening pollution in general, some from fossil fuel power generation) will kill orders of magnitude more.
However your post does serve as an excellant example of the mindless fear mongering that that antinuclear people use in place of facts.
Also people seem to be forgetting the dozens of above-ground nuclear weapons tests we had right here in the good ol' US of A, complete with fallout. Not that I'm advocating such things, but we have survived without major consequences.
But all are (or will be used) in embedded system design anyway, so that's where my train of thought was leading. The Hammer mainly has 'momentum' going for it. Just about everything else is against it.
They are years (possibly decades) away from widespread use as embedded processors. Given their capability and memory sizes, again it will be far less than 1% programmed in assembler. Mostly likely Java will be the dominant embedded language by then.
I don't have time to rehash this entire argument, but I will touch on one point:
This is the crux of the problem for AMD's hammer. The hammer will be forced to use a much larger transistor count than its RISC competitors. The higher transistor count results in several problems: It's far more complex and expensive to design. It takes a more complicated and expensive process to fab. The die is larger, which results in a slower processor. And it uses more power.
Hammer has a substantially smaller die than P4, it's main competitor. Itanic, er Itanium, not only has a large die, but is priced with extreme margins. It's an easy target for Hammer. There is the issue of OEM support, but if Hammer meets spec it will be in high demand.
More the opposite; except for pathological cases, C code runs a few hundred percent slower than assembler.
Why don't you go to the Usenet group comp.compilers and state that "Except for pathological cases, C code runs a few hundred percent slower than assembler".
If desktop computers accounted for more than a tiny fraction of the whole computer market, I might actually care about that statement. Fortunately, the vast majority of computers are embedded systems, and a substantial portion of embedded code is pure asm.
Er, wait a sec. This discussion was about Hammer, vis a vis Itanium, SPARC, etc. Remember?
None of them are aimed at the embedded market.
No, that's the software designers point of view. The hardware designers point of view is to maintain the performance of software written by overworked programmers who don't have the time to do it right.
Don't worry. Even with the widespread use of high level languages, computers can do far more now than a few years ago - or are you claiming you could run Quake 3 on a 386, if it were written in assembly?;-)
First off, C code does execute several times slower than assembler. On the order of 5-10x is typical. Compilers really aren't that wonderful.
Except for pathological cases, C code will run a few percent slower than hand-tuned assembler - if that. As I said, out to lunch...
First, almost all programmers can (thankfully) ignore the underlying instruction set and program in a higher level language - therefore it is irrelevant. x86-64 is actually quite an improvement over IA32 regardless.
Oooh! A higher level language!!!
So is BASIC! And you can get it for any platform and your code will run.
Whoopee! It's still dog slow and takes up more resources than is necessary to get the job done. Even compiled (C) code usually runs several times slower and requires more memory than assembler.
You've just proven you have no practical knowledge of software development. Far less than 1% of desktop/workstation/server software is programmed in assembler. Perhaps the inner loop of some game engines might be, but I doubt even that in most cases.
One of the main points of developing faster processors with large amounts of memory was to enable the use of more programmer-friendly languages. It is simply not worth the cost to develop systems of any size in assembly.
Finally, if you think C code "usually" runs several times slower than assembler, you're just plain out to lunch.
Second, if an instruction set is sufficiently efficient to allow the processor to be the fastest microprocessor in the world,
First, an instruction set has little to do with the speed of the processor. The whole CISC vs. RISC thing has more than shown that. An instruction set has more to do with the difficulty and/or complexity of the processor's design. The CISC instruction set requires more (electrical) power, and more transistors to do the same job.
The instruction set (and associated issues like register count) certainly does have an effect on speed. Next!
Second, it's to be the fastest in the world? By what method is this measured? Clock speed? Size of the pipeline? Number of pipelines? Clocks per (integer, float, or instruction)?
I'll settle for SPEC2000 benchmarks. You know, real world codes optimized to the hilt for the target processor.
The first Hammer is supposed to debut at a PR 3400, and the first Opteron with a PR 4000. Multiply the current Athlon SPEC scores by the ratios of the PR numbers...that should give you a good idea of what's to come.
The hammer isn't even meant to compete with workstation processors in terms of speed. I'll take a SPARC or Itanium any day.
You are absolutely incorrect. First off, Athlon MP and Xeon are already workstation solutions, albeit 32-bit.
Secondly, the Opteron versions of Hammer (with dual memory controllers, more than 2-way capability and large cache) are squarely aimed at high-end workstation and server applications, up to at least 8-way. Do some homework and you'll see this to be the case. Dell recently announced that it's skipping Itanium 2, and evaluating Hammer/Opteron.
(It's a sad thing that so many seem to forget that the Itanium is an HP design, the successor to its PA-RISC, and that newer versions of the Itanium will include many of the Alpha's technologies).
It is a dual HP + Intel design, and so far it has been a collosal dud by anyone's measure. With poor backwards compatibility and anemic performance, it is very vulnerable to Hammer, if AMD can pull it off. So far Hammer is looking great! Working silicon has been demoed, and things look on track for a 4Q release of the first Athlon-64 (desktop Hammer). Opteron will follow 1Q 2003.
(BTW, it'll be interesting to see how Intel spins the low clock speeds of Itanium. THAT will require some chutzpah! I hope AMD nails Intel on that score.)
Sorry I didn't reply sooner, I was away from the keyboard most of yesterday.
The sooner we kill the x86 architecture, the better. It was ancient 15 years ago. Humanity gave up horses and slaves in favor of automobiles and machinery. We can give up the old x86 architecture for something better. Maintaining it is inhumane.
This is a silly argument, for two reasons.
First, almost all programmers can (thankfully) ignore the underlying instruction set and program in a higher level language - therefore it is irrelevant. x86-64 is actually quite an improvement over IA32 regardless.
Second, if an instruction set is sufficiently efficient to allow the processor to be the fastest microprocessor in the world, it can't be so bad - can it? If my information is correct, Hammer and Opteron will debut with absolutely world-class performance. This isn't so surprising, given that many ex-Alpha engineers are working on it.
Backwards compatibility is simply a nice bonus, which will be crucial in Hammer attaining critcal mass quickly.
That's not Java, that's "java like object code for version 1.1.4 (or whatever) of the Microsoft VM". Java - as a write once, run anywhere language - is dead.
Nobody who knows anything cares about the Microsoft JVM. It is a perversion of justice that they will ship it with Windows XP rather than a modern implementation. Anything that uses modern Java will point the user at the right place to download it. The JRE isn't much of a download, and seldom requires an upgrade.
My investment in Java revolves around the platform going forward. The language is evolving minimally, while providing backward compatiblity. It seems to me that (especially when using mostly base language features) an investment in coding Java will pay off for many years. I expect the major VMs and gcj to be 99.9% compatible going forward (that may or may not include Swing, see below).
You want to debate further? OK, can you lay your hands on one of those java-like cell phone applications, because I'd like to try running it on my PC under a variety of browsers and appletviewer. Want to bet that it'll work? Bet your career?
Why would I want to run an app set up for a (crummy) cell phone screen on my PC? Right now it is perfectly reasonable to differentiate between those devices.
I could certainly write a lot of Java code that would run either on the PC or on the cell phone, though. Let's say an interest calculation object, for instance...
I'm primarily interested in Java applications, in conjunction with Java Web Start. I'm also open to the idea of SWT, which has already been used with gcj (as well as the vendor-supplied VMs). If Swing founders, SWT will take up the slack, IMO. Eclipse looks like a nice IDE, though I haven't done much with it yet.
Slashdot Mirror
It is amazing how software has managed to soak up a 100x speedup in CPU performance... ;-)
There is a wide range in I/O performance, and I'm sure your machine would benefit from a level 0 RAID array with 15,000 RPM drives on a SCSI-3 controller. ;-) Unfortunately, that is still a fairly expensive (factory) option, though you could do it yourself under $1000 (dual 36 GB IBM drives would be under $600, plus $200-$400 for controller). Might well be worth it.
Unfortunately, we have a TechOps group that gives us these machines, and if you check MCAD company stock prices, you'll see that our managers are in no mood to spend extra money on replacement equipment. I agree that nVidia should supply a fix pretty quickly, given that this is software and not hardware related.
One thing I'd try is downloading the latest drivers directly off NVIDIA's site, if you haven't already.
Me too. Better yet, I wish that more CAD companies in general would get a clue and port to Linux; PTC is too little too late. I'll whisper to you that at least one of the big MCAD companies experimented with a Linux port, but abandoned it for shortsighted management reasons. A Opteron/Linux/(Catia/I-deas/Unigraphics) combi would be pretty suhweet.
I'm sure it'll happen at some point, because Linux is simply better at a fundamental level (not designed by marketer/lawyers).
That's one reason I like NVIDIA - it has provided great (although binary only) drivers for Linux for some time, for all it's cards. Also, NVIDIA is widely recognized as having some of the best OpenGL drivers available, both on Linux and Windows.
By the way, on AMD/Opteron I wish I had the resources to start a new computer company ala Dell. I'd bet it'd be possible to strike up a relationship with AMD (special discounts) to launch an AMD-only brand to take on the "Intel Inside" campaign. I think the Hammers will be good enough that unless Dell adopts them as well (quite possible) there will be a giant market opportunity there.
If Dell adopts Hammer, I hope I'm holding a lot of AMD stock. ;-)
Anyway, thanks for pointing these things out, and thanks for not flaming me to death a-la the typical Slashbot ;-).
I just got the sense that something might be misconfigured. It also sounds like you could use more RAM.
Enough rambling for now...have a good day!
RDRAM? Is it a Xeon system? One point might be that you could go dual Xeon as well...
Is it maxxed out on RAM? I think some P4 setups can go to at least 3 GB.
Quadro Pro card, very similar specs to the 4, someone down the hall _has_ a Quadro4, they don't touch the Visualize cards.
What is the amount of on-card RAM in each case?
I must say I'd be somewhat surprised to learn that the Quadros can't beat pretty much any older technology (forgetting about exotic features like greater than 32 bit color or lots of hardware overlay planes).
Check out some recent Quadro awards.
Admittedly, I might have been wrong about the price of the card--I think still that the Quadro4s top out at ~$1k, which is still pretty low in the card arena.
Prices have been dropping like rocks in many PC areas. For instance, CPUs used to top out at over $1000, but now its less than half that.
It's crap in any case, IMHO. nVidia needs to stick to Quake.
Lots of people feel otherwise. Lets see how NV30 (and related professional products) do. That is supposed to be a greater than 2x speedup over GeForce 4 products.
Incidentally, there are gigantic known field problems with the whole Quadro line.
Quadro 2 or 4?
There's a problem with memory access (>1 GB models) that causes huge problems in high end CAD packages.
I'm surprised if NVIDIA couldn't address this quickly.
Most people don't really get it when I say "high end mcad". We're talking Ford engine blocks, Toyota trannies, etc. BFMs. This isn't designing little floor plans with AutoCAD 2000.
Yes. I hope that Hammer/Opteron kills Intel in this market. NVIDIA will be right there as well. :-)
Yes, because the rate of software innovation has slowed so.
However, a paradigm shift will come (other than Quake that is;) and suddenly we'll need all the extra performance. Natural speech recognition, for instance, might be such a shift. Ironically, the last demo I saw was on a G4 Powerbook, but it looks to me as though the voice dictation product are finally getting usable for most people, with a *fast enough machine*.
I'd love (as I've stated in previous posts) for Apple to support at least the new x86-64 chips from AMD. That would differentiate them from everyday 32 bit systems, and provide world class performance to boot. Plus, Apple would have a new "64 bit" ad campaign.
Cool, eh? ;-)
(I know, I know, it's a cliche, but cliches are cliches because they're _true_.)
Except, of course, when they're wrong. ;-)
I'm reminded of an old statement out of IBM (paraphrased): "The worldwide market for computers is around ten machines."
Wow, where to start...
First, how much memory do you have in the box? Doing CAD work you should load the boat, 1 GB minimum. Disk swapping should be eliminated.
Your 2 GHz. P4 should be at least 3x faster than the 550 P3. What memory type does it use?
Personally, I favor AMD CPUs in general, but I do know some CAD packages don't officially support AMD.
Don't get me started on the video card. Even regular GUI rendering is slower, much less 20k surface geometry.
Did it occur to you to use a professional graphics card for your professional app? The consumer drivers/cards don't accelerate things like antialiased line drawing. Swap out your current card for a Quadro4, you'll be glad you did. (I don't know why you're getting slow screen redraws with the consumer card though, my Athlon with a GeForce 3 is lightning fast).
In short, you still have to have a bit of a clue in order to get optimum system performance.
Yeah, just like KDE is the future of the Linux desktop... ;-)
Remember, having a selection is a good thing...and native Linux games will work better than Wine ports.
Personally, I'm more interested in games based on the Torque engine, Q3/Doom3 engines etc.
I can neither confirm nor deny that I'm smoking anything. ;-)
I'm working on a Torque project, on Linux, as we speak. The engine has had Linux support pretty much from the start.
Er, I read this, which clearly says "Linux server, Linux client under development". Sorry if I got it wrong, I was just going by the website. Its good to hear that the Linux client is further along than that! :-)
Do the various tools work under Linux as well?
Looks like lots of Slashdotters are signing up...I will be as soon as I get the chance!
What a great looking product for such a low price! I agree with GG that this should lead to some real innovation (for a change) and will also let some new game development stars emerge who wouldn't have had the budget otherwise. AWESOME!
Also, Slashfolk, don't miss the fact that this engine uses open technologies (OpenGL/OpenAL), is already available on Windows and Mac, and a Linux client is in the works.
Too cool, I can't wait to get them my $100 so I can start playing... =)
(BTW on the id issue - give it a rest. I suspect id prefers to not have the support hassles this would entail...id is making plenty of money already!)
I don't think that's the correct interpretation.
I hate to find myself defending Microsoft and it's allies, but I think the main problem they have is that GPL'd software can't be commercially sold or incorporated in commercial software.
I have to agree that the best license for software developed on the public nickel should be something like: "This software may be freely used by any (American citizen? / one?) for any legal purpose. There is no warranty whatever."
Don't forget that the 64-bit data will be coming from a wide memory bus, so there is essentially no extra overhead for getting 64 bits at a time. For many data structures (for instance an array of 32 bit integers) there is no additional overhead.
However, your basic point is right, just as it was for a doubly linked list of shorts on a 32-bit architecture. Larger pointers, and some level of data bloat (ints will now be 64 bits, for instance) are to be expected.
So, it is not so much that "resource reallocation must be rethought", it is simply that many applications don't yet need 64-bit power. The immediate adopters will be areas like scientific processing/visualization, CAD/CAM/CAE and large databases (this is the enterprise server role AMD is hoping Opteron nails). CAD users have been hard up against current addressing limits, and will welcome the ability to handle larger models. A little extra bloat is in the noise, especially since the whole point is to address massive amounts of RAM. The SUSE implementation allows 512 GB of virtual address space per process, for instance. Hammer's SMP capabilties and scalable memory architecture are just more icing on the cake.
"Normal" users can buy Hammer systems and run 32-bit software/OSes just fine (faster than any P4), then upgrade to 64 bits when they need it. People will find ways to use all that power, natural speech interfaces come to mind. Games will probably push the 4 GB barrier sooner than you'd think as well.
By the way, the claim is that 64-bit code for the Hammer will run 30% faster than the equivalent 32-bit code. This is due to x86-64 having more general purpose registers among other things.
I think that x86-64 is a brilliant move on the part of AMD, and if Hammer performs as advertised AMD will take major marketshare and profits from Intel. I can't wait to get my hands on a system, myself. :-)
Reason 1: To play games with film-quality graphics (or near enough as makes no difference).
Reason 2: Great looking real-time architectural walkthroughs, CAD renderings and so on.
Reason 3: To render 100 or more times as many frames per unit time in the film render farm.
All of those reasons seem pretty compelling to me!
I suspect you'll be changing your tune when you see what the R300 and NV30 can do... :-)
How so? I'm working with a small company right now that's already committed to switching all new computer users to Star Office. They are open to desktop Linux on some desktops as well. This is a technical company, and the CEO (PhD. physicist) was quite impressed when he imported a Word document and all the formulas came through flawlessly.
They figure they'll have one workstation with Office for document export, when HTML or PDF isn't sufficient.
Microsoft pricing has finally gotten far enough out of sync with small business budgets, that I think you'll see quite a few switching. Sun made a smart move charging a nominal price, now businesses are starting to see Star Office as a serious product.
[This was satire, ICYDU.]
I vote for high-performance Java, personally (with further extensions for better performance like lightweight objects [no inheritance but very little overhead for things like complex numbers], immortal [static] objects and a good generics implementation). I'd also like to see a very flexible and extensible operator overloading functionality, as well as the ability to use Unicode in Java source as an optional extension, for both variables and operators.
Also don't forget that gcc 3.x now includes a Java front end...perfect for extending into numerical Java. It's especially appropriate since it is a traditional "ahead of time" compiler permitting full optimization.
IBM has already provided matrix libraries written in Java with about 80% of the performance of fully optimized FORTRAN. Another interesting library is the Colt Library. It is also possible, using JNI and DirectIO, to use legacy libraries efficiently from Java where appropriate.
The focal point for numerical Java is Java Grande.
BTW, I was sorry to miss the Java 3 discussion yesterday, but this post summarizes my desires in that area. Quite a bit different from those of the article's author (what a whiner that guy was!).
At any rate, FORTRAN is still alive and kicking, and will be for another hundred years I'm sure... ;-)
I hope new development is mostly being done in Java in the not too distant future, though!
Make that "since November 2001"...sorry it was a brain cramp. ;-)
It's been final since September 2001.
Even if that is so, we'd still need a major nuclear war to equal the cancer caused by smoking (not to mention alcohol, pollution, natural radiation and fatty foods).
No, we really don't need to introduce more causes of cancer into the environment, BUT let's keep things in perspective. 15,000 deaths over 30+ years is miniscule in terms of global cancer death rates.
Damage to the ozone layer (as well as worsening pollution in general, some from fossil fuel power generation) will kill orders of magnitude more.
Also people seem to be forgetting the dozens of above-ground nuclear weapons tests we had right here in the good ol' US of A, complete with fallout. Not that I'm advocating such things, but we have survived without major consequences.
They are years (possibly decades) away from widespread use as embedded processors. Given their capability and memory sizes, again it will be far less than 1% programmed in assembler. Mostly likely Java will be the dominant embedded language by then.
I don't have time to rehash this entire argument, but I will touch on one point:
This is the crux of the problem for AMD's hammer. The hammer will be forced to use a much larger transistor count than its RISC competitors. The higher transistor count results in several problems: It's far more complex and expensive to design. It takes a more complicated and expensive process to fab. The die is larger, which results in a slower processor. And it uses more power.
Hammer has a substantially smaller die than P4, it's main competitor. Itanic, er Itanium, not only has a large die, but is priced with extreme margins. It's an easy target for Hammer. There is the issue of OEM support, but if Hammer meets spec it will be in high demand.
More the opposite; except for pathological cases, C code runs a few hundred percent slower than assembler.
Why don't you go to the Usenet group comp.compilers and state that "Except for pathological cases, C code runs a few hundred percent slower than assembler".
The resulting blood bath should be amusing. ;-)
Let me know if you do it, I want to watch...
Er, wait a sec. This discussion was about Hammer, vis a vis Itanium, SPARC, etc. Remember?
None of them are aimed at the embedded market.
No, that's the software designers point of view. The hardware designers point of view is to maintain the performance of software written by overworked programmers who don't have the time to do it right.
Don't worry. Even with the widespread use of high level languages, computers can do far more now than a few years ago - or are you claiming you could run Quake 3 on a 386, if it were written in assembly? ;-)
First off, C code does execute several times slower than assembler. On the order of 5-10x is typical. Compilers really aren't that wonderful.
Except for pathological cases, C code will run a few percent slower than hand-tuned assembler - if that. As I said, out to lunch...
What, Linux is suddenly going to use Palladium and also start doing MS-style "security patches"?
I think not. ;-)
Oooh! A higher level language!!!
So is BASIC! And you can get it for any platform and your code will run.
Whoopee! It's still dog slow and takes up more resources than is necessary to get the job done. Even compiled (C) code usually runs several times slower and requires more memory than assembler.
You've just proven you have no practical knowledge of software development. Far less than 1% of desktop/workstation/server software is programmed in assembler. Perhaps the inner loop of some game engines might be, but I doubt even that in most cases.
One of the main points of developing faster processors with large amounts of memory was to enable the use of more programmer-friendly languages. It is simply not worth the cost to develop systems of any size in assembly.
Finally, if you think C code "usually" runs several times slower than assembler, you're just plain out to lunch.
Second, if an instruction set is sufficiently efficient to allow the processor to be the fastest microprocessor in the world,
First, an instruction set has little to do with the speed of the processor. The whole CISC vs. RISC thing has more than shown that. An instruction set has more to do with the difficulty and/or complexity of the processor's design. The CISC instruction set requires more (electrical) power, and more transistors to do the same job.
The instruction set (and associated issues like register count) certainly does have an effect on speed. Next!
Second, it's to be the fastest in the world? By what method is this measured? Clock speed? Size of the pipeline? Number of pipelines? Clocks per (integer, float, or instruction)?
I'll settle for SPEC2000 benchmarks. You know, real world codes optimized to the hilt for the target processor.
The first Hammer is supposed to debut at a PR 3400, and the first Opteron with a PR 4000. Multiply the current Athlon SPEC scores by the ratios of the PR numbers...that should give you a good idea of what's to come.
The hammer isn't even meant to compete with workstation processors in terms of speed. I'll take a SPARC or Itanium any day.
You are absolutely incorrect. First off, Athlon MP and Xeon are already workstation solutions, albeit 32-bit.
Secondly, the Opteron versions of Hammer (with dual memory controllers, more than 2-way capability and large cache) are squarely aimed at high-end workstation and server applications, up to at least 8-way. Do some homework and you'll see this to be the case. Dell recently announced that it's skipping Itanium 2, and evaluating Hammer/Opteron.
(It's a sad thing that so many seem to forget that the Itanium is an HP design, the successor to its PA-RISC, and that newer versions of the Itanium will include many of the Alpha's technologies).
It is a dual HP + Intel design, and so far it has been a collosal dud by anyone's measure. With poor backwards compatibility and anemic performance, it is very vulnerable to Hammer, if AMD can pull it off. So far Hammer is looking great! Working silicon has been demoed, and things look on track for a 4Q release of the first Athlon-64 (desktop Hammer). Opteron will follow 1Q 2003.
(BTW, it'll be interesting to see how Intel spins the low clock speeds of Itanium. THAT will require some chutzpah! I hope AMD nails Intel on that score.)
The sooner we kill the x86 architecture, the better. It was ancient 15 years ago. Humanity gave up horses and slaves in favor of automobiles and machinery. We can give up the old x86 architecture for something better. Maintaining it is inhumane.
This is a silly argument, for two reasons.
First, almost all programmers can (thankfully) ignore the underlying instruction set and program in a higher level language - therefore it is irrelevant. x86-64 is actually quite an improvement over IA32 regardless.
Second, if an instruction set is sufficiently efficient to allow the processor to be the fastest microprocessor in the world, it can't be so bad - can it? If my information is correct, Hammer and Opteron will debut with absolutely world-class performance. This isn't so surprising, given that many ex-Alpha engineers are working on it.
Backwards compatibility is simply a nice bonus, which will be crucial in Hammer attaining critcal mass quickly.
Time to pick up some AMD stock!!! =)
Alpha is brilliant, too bad it didn't receive the development and marketing dollars it deserved. Compaq should be ashamed.
Thank goodness AMD is here to take up the slack with Hammer! =)
"Linux is our flagship technology going forward! Quick, let's cancel it on our sexiest products!"
What a great way to torpedo enthusiasm in the techie community... :-p
Time for someone to set up a petition page...
Nobody who knows anything cares about the Microsoft JVM. It is a perversion of justice that they will ship it with Windows XP rather than a modern implementation. Anything that uses modern Java will point the user at the right place to download it. The JRE isn't much of a download, and seldom requires an upgrade.
My investment in Java revolves around the platform going forward. The language is evolving minimally, while providing backward compatiblity. It seems to me that (especially when using mostly base language features) an investment in coding Java will pay off for many years. I expect the major VMs and gcj to be 99.9% compatible going forward (that may or may not include Swing, see below).
You want to debate further? OK, can you lay your hands on one of those java-like cell phone applications, because I'd like to try running it on my PC under a variety of browsers and appletviewer. Want to bet that it'll work? Bet your career?
Why would I want to run an app set up for a (crummy) cell phone screen on my PC? Right now it is perfectly reasonable to differentiate between those devices.
I could certainly write a lot of Java code that would run either on the PC or on the cell phone, though. Let's say an interest calculation object, for instance...
I'm primarily interested in Java applications, in conjunction with Java Web Start. I'm also open to the idea of SWT, which has already been used with gcj (as well as the vendor-supplied VMs). If Swing founders, SWT will take up the slack, IMO. Eclipse looks like a nice IDE, though I haven't done much with it yet.