Ok, so I forgot which extensions were available where. Not the point, though: the point was that the G4 is slower (in floating-point calculations) than an equivalently clocked Athlon. With extensions, either CPU can be made to run certain applications faster.
One thing I didn't mention is that I was using the GNU GCC 3.1 compilers on both platforms. Maybe performance on the G4 will have improved with the newer GCC compilers, but I doubt it will be by that much...
Sitting on or near my desk are a 800MHz Athlon (running a Linux 2.4.x kernel), an 800MHz G4 Titanium (MacOSX 10.2.x), and a 1.8GHz P4 laptop (Linux 2.4.x). The Titanium was bought for me by my employer, since many of the people here use them, and I do application and hardware support, as well as Astrophysical research.
I have benchmarked my applications on these three platforms (and the best benchmarks are, of course, your own applications, aren't they?). The G4 is slower, by about 20%, than the 800MHz Athlon. Arguably, if my applications were made 'Altivec-aware' they'd run significantly faster on the G4, but if I were to use SSE2 extensions on the Athlon or P4, they'd run faster on those platforms, too.
Although I kinda like MacOSX (and abhorred MacOS9), and think Apple wins top marks for esthetics, their hardware is way too slow for a 20% improvement in processor speed to give them the boost they need.
The best move for Apple will probably be to go with the new IBM chips.
I'm an astrophysicist in a non-profit research institute. We have very few 'special' hardware requirements like the poster, and so are not as limited by what OS hardware vendors are willing to support, but I've come across similar situations.
When it comes to proprietary hardware with proprietary drivers on a limited number of (non-free) OSes, you're stuck. Everytime you talk to the vendor, or the support staff, you need to ask them about Linux (or BSD, or whatever) support. Be the bee in their bonnet that gets them thinking about supporting other operating systems. They don't necessarily have to GPL their software and drivers (I know, sacrilege!), but the ability to use your hardware on Linux means your one step closer to moving the lab over to Linux. Also, even if the data-acquisition is on, for example, Windows, that doesn't mean the data-analysis has to be on the same OS.... (Unless the data format is proprietary =8-( )
However, being a researcher, you should be used to the concept of peer-reviewed publications: nothing is published in established journals without having being scrutinized by other researchers in the same field. The same concept applies to OSS: open source software, at sometime in its public life, is viewed by enough people that bugs, cheats, etc., will probably be caught (things slip through, as they do in the scientific peer-review process, but the idea is sound). If you're doing research in the uncharted regions of physical science, you can't expect that someone would have written all of the software you need to get there and understand what you discover. This means that you, the researcher, are obligated to write the software. This software should be open sourced and peer-reviewed, saving your collegues and other researchers the same headache.
What is done in scientific research is often governed by the 'publish or perish' doctrine. But keep in mind that what you publish might not have to be scientific papers: if everyone in quantum computing labs around the world knows of or makes use of your software, you will have more exposure than publishing a few obscure papers.
Also, despite the fact that you might be analysing unique data, I would hazard to guess that large amounts of the mathematics and statistics you would be using are not unique. Save yourself time when writing your software and don't re-invent the wheel: use publicly available mathematical and statistical packages. There are enough out there that I'm not going to bother giving URLs...
I look forward to seeing your project (not in VB or C#) on sourceforge =;-)
(Oh, and when your Windows-bound collegues ask about using your software on their OS, you can say "Sorry, it's only supported on Linux." That'll make you feel better, trust me =8-)
Slashdot Mirror
Ok, so I forgot which extensions were available where. Not the point, though: the point was that the G4 is slower (in floating-point calculations) than an equivalently clocked Athlon. With extensions, either CPU can be made to run certain applications faster.
One thing I didn't mention is that I was using the GNU GCC 3.1 compilers on both platforms. Maybe performance on the G4 will have improved with the newer GCC compilers, but I doubt it will be by that much...
Sitting on or near my desk are a 800MHz Athlon (running a Linux 2.4.x kernel), an 800MHz G4 Titanium (MacOSX 10.2.x), and a 1.8GHz P4 laptop (Linux 2.4.x). The Titanium was bought for me by my employer, since many of the people here use them, and I do application and hardware support, as well as Astrophysical research.
I have benchmarked my applications on these three platforms (and the best benchmarks are, of course, your own applications, aren't they?). The G4 is slower, by about 20%, than the 800MHz Athlon. Arguably, if my applications were made 'Altivec-aware' they'd run significantly faster on the G4, but if I were to use SSE2 extensions on the Athlon or P4, they'd run faster on those platforms, too.
Although I kinda like MacOSX (and abhorred MacOS9), and think Apple wins top marks for esthetics, their hardware is way too slow for a 20% improvement in processor speed to give them the boost they need.
The best move for Apple will probably be to go with the new IBM chips.
My 0.02CDN.
I'm an astrophysicist in a non-profit research institute. We have very few 'special' hardware requirements like the poster, and so are not as limited by what OS hardware vendors are willing to support, but I've come across similar situations.
When it comes to proprietary hardware with proprietary drivers on a limited number of (non-free) OSes, you're stuck. Everytime you talk to the vendor, or the support staff, you need to ask them about Linux (or BSD, or whatever) support. Be the bee in their bonnet that gets them thinking about supporting other operating systems. They don't necessarily have to GPL their software and drivers (I know, sacrilege!), but the ability to use your hardware on Linux means your one step closer to moving the lab over to Linux. Also, even if the data-acquisition is on, for example, Windows, that doesn't mean the data-analysis has to be on the same OS.... (Unless the data format is proprietary =8-( )
However, being a researcher, you should be used to the concept of peer-reviewed publications: nothing is published in established journals without having being scrutinized by other researchers in the same field. The same concept applies to OSS: open source software, at sometime in its public life, is viewed by enough people that bugs, cheats, etc., will probably be caught (things slip through, as they do in the scientific peer-review process, but the idea is sound). If you're doing research in the uncharted regions of physical science, you can't expect that someone would have written all of the software you need to get there and understand what you discover. This means that you, the researcher, are obligated to write the software. This software should be open sourced and peer-reviewed, saving your collegues and other researchers the same headache. What is done in scientific research is often governed by the 'publish or perish' doctrine. But keep in mind that what you publish might not have to be scientific papers: if everyone in quantum computing labs around the world knows of or makes use of your software, you will have more exposure than publishing a few obscure papers.
Also, despite the fact that you might be analysing unique data, I would hazard to guess that large amounts of the mathematics and statistics you would be using are not unique. Save yourself time when writing your software and don't re-invent the wheel: use publicly available mathematical and statistical packages. There are enough out there that I'm not going to bother giving URLs...
I look forward to seeing your project (not in VB or C#) on sourceforge =;-)
(Oh, and when your Windows-bound collegues ask about using your software on their OS, you can say "Sorry, it's only supported on Linux." That'll make you feel better, trust me =8-)