Couple of things about the 96 FPS in Quake 3 Arena:
1. It doesn't say what resolution it is running. 640x480? 1280x1024??
2. Quake 3 is a terribly old game, so getting 100 FPS in it isn't exactly good.
3. With a real graphics card & fast Mac the performance is far higher. Mac benchmarks,
4. And your comment that all games are CPU bound, is crap. Go find some benchmarks of FarCry, you'll soon see it is very much graphics card limited!
The 9200 is an ok card, don't get me wrong, but it is several generations behind the mainstream cards.
UT 200x isn't actually that hard on graphics - it is hard on CPU. So having a G5 will make a lot of difference.
If you think a 9200 is fine, try running Doom 3 on it!
Also I believe Tiger has some extra graphical stuff which require pixel shader 2.0, which the 9200 doesn't have either. It'll still run, but all of the important eye-candy won't.
Whilst I won't disagree that module compatability is a good thing... this is quite a deliberate move by Linus. After all, the the kernel comes with all the drivers anyway so why not use the driver that comes with the kernel?
It is also to discourage binary modules, as they impossible to debug if they cause the kernel to crash.
No, it doesn't resolve dependicies. I'll refuse to use any OS at home that doesn't have a ports system of some sorts as it just makes life so much easier.
And yes, you can compile them manually under Solaris no problem. Sun also supply them on a bonus CD. The problem is, they don't update them. Vuln in libpng? Update it yourself.:(
Portage is a superb tool. I'd really like to have a good ports system on normal Solaris, let alone OpenSolaris!
Erm, nope. emerge does not over-write any configuration files in/etc or anywhere else.
If he runs etc-update, then it will prompt him which files it is going to update. So at this point, it would be possible to blindly accept an update to/etc/fstab, although he would have had to accept it.
1) Even way back in solaris 2.5 (and probably before that, but that is when I started), you could just download the latest patch cluster, run 'install_cluster', and then reboot when you were done (if required... see below). That was it. No muss, no fuss... A new cluster was generated every 2 weeks for the lazy admin who wanted to stay up to date with patches yet not actually read the patch notes
I can't comment on smpatch, but I can comment on this. It is terrible.
Ok, sure, it does get all the patches applied. The problem is that it tries to re-apply patches that you've already got, on even on our fastest systems it still takes a long time for each patch to fail. On our desktop Ultra 5, it caused way too much trashing for each patch to fail. As least Redhat, Debian, etc etc only apply patches that are required.
I suppose the point is that Intel never really *wanted* to add them. AMD's sucess made them do it. Remember for a long time they even denied such a processor even existed, and that they never would make one. They wanted to push Itanium, which is now being relgated to high end number crunching only due to the this.
Anyway, as the other follow-up said. You'd be best off with AMD anyway, they're faster (2.4GHz Opteron is unmatched by any Xeon I've seen) and generate much less heat. Got a 4-way 2.4GHz Opteron box at work, and the heat out of the back is less than our dual processor Xeon boxes. The dual processor Opterons we've got run very cool.
You are simplifying things a bit, but in a round-about way it is true!
From Redhat's release notes for the update 2 to RHEL3.
Software IOTLB -- Intel® EM64T does not support an IOMMU in hardware while AMD64 processors do. This means that physical addresses above 4GB (32 bits) cannot reliably be the source or destination of DMA operations. Therefore, the Red Hat Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB at boot time. This is likely to result in lower performance for IO-intensive workloads for Intel® EM64T as compared to AMD64 processors.
Ah yes, the winter didn't work into the Germans favour that is for sure. Then again, those crazy Russians were just throwing men at the Germans and this man power was just always going to work in the long run. Also having some kick ass T-34 tanks which were the best available at the time helped, although I can't quite remember when they became available.
I think the channel mandidated the need for air superiority, otherwise we'd have been blitzkreig'd as well. Thankfully they never got it (yay for radar!) and we were just able to fend them off and eventually use ourselves as a base to invade France with help from the US, remaining French fighters, Canadians, etc.
Ultimately though, attacking Russia was really stupid. Given their size & man power, in the long run it was always going to be a losing fight.
1. Neither Germany nor Japan could attack contiental USA. 2. Germany & Japan did have other countries attacking their land however. 3. Germany & Japan had already been in war for 2 years before the USA got involved, which would have been a further drain on their resources. 4. Germany did it OVER LAND! Remember 25 miles of water was enough to save the UK, but when you can march straight back into the country that attacked you then you better win!
Then again, of course, Sun sell dual Opteron servers with RAID controllers. I'd be very surprised if Solaris didn't support them.
Try running Solaris x86 on desktop machines, you'll find the hardware support drops off very rapdily. Then again, this often isn't a problem as Solaris is used as a server OS. Like you said, soundcard support for Solaris isn't a problem!
Whilst that CD is good - it doesn't exactly get updated. What happens when a vulnerablity in libpng appears? I don't think you'll see Sun giving you one!
And what if you want something a bit more obsecure and it isn't on the CD? What if you want something that has been updated in the meantime?
IBM's dual-core POWER5 is just about the only thing out there that's even close to (a single-core) I2 in FP performance.
IBM's Power 5 is a lot more capable than the Itanium 2 in SpecFP - you are wrong! Sure, it is newer but it is #1 by a long way in SpecFP land. Here are the SPEC figures:
1900MHz POWER5 - 2702 peak, 2571 base.
1500MHz Itanium 2 - 2161 peak, 2161 base.
The Itanium 2 wins SpecInt, by 10 points tho. Of course, in SpecINT they both get trashed by x86 Xeon & Opterons.
The Itanium 2 isn't bad, but I think POWER is simply better (and doesn't have other issues like a shared bus for memory access).
MHz for MHz the x86 gets murdered by all the EPIC and MIPS/SPARC/Power RISC chips.
You're joking right? That is barely true. I suspect for integer performance, the Opteron is the strongest out of all of them. Look at the SpecINT scores, it is dominated by x86 at the top end (Xeons & Opterons) and they are way above everything else at all.
For FP, you're half right. The Itanium2 & POWER4/5 are more than a match for the Opteron and will beat it (especially the POWER5). SPARC & MIPS are waaaay slower. No-one uses them for raw MHz performance, more for a large number of CPU systems.
My REAL WORLD tests show the Opteron is 33% quicker MHz for MHz over Sun's UltraSPARC3/3i/3+ processors. That is a problem for them when the Opteron clocks so much faster too!
Linux, BSD, Windows - they're all junk! AmigaOS 4 is the way forward!!
Why don't you use 2.4 instead?
Re:I wrote linux...
on
Who Wrote Linux?
·
· Score: 2, Informative
The thing was, Fermat was always terrible at his proofs for the most part. I think it was basically "I've got a great proof for this" but he didn't write anything
In the end, some guy spent many years tracking it down and eventually proving Fermat was correct! He has to invent some new maths theories as well to do this. Was Fermat that good?!?
Here is a good book if you fancy finding out more....Amazon. I've read it a few years back, it is good!
We are comparing RH's enterprise only distro (in fact, the only thing they "officially" make these days) to SuSE's desktop distro - is it no surprising that RH's has more backported stuff as it has a 5 year lifespan???
1. It doesn't say what resolution it is running. 640x480? 1280x1024??
2. Quake 3 is a terribly old game, so getting 100 FPS in it isn't exactly good.
3. With a real graphics card & fast Mac the performance is far higher. Mac benchmarks,
4. And your comment that all games are CPU bound, is crap. Go find some benchmarks of FarCry, you'll soon see it is very much graphics card limited!
The 9200 is an ok card, don't get me wrong, but it is several generations behind the mainstream cards.
UT 200x isn't actually that hard on graphics - it is hard on CPU. So having a G5 will make a lot of difference.
If you think a 9200 is fine, try running Doom 3 on it!
Also I believe Tiger has some extra graphical stuff which require pixel shader 2.0, which the 9200 doesn't have either. It'll still run, but all of the important eye-candy won't.
Whilst I won't disagree that module compatability is a good thing... this is quite a deliberate move by Linus. After all, the the kernel comes with all the drivers anyway so why not use the driver that comes with the kernel?
It is also to discourage binary modules, as they impossible to debug if they cause the kernel to crash.
Nvidia does have FreeBSD drivers though.
OpenBSD isn't optimised for real performance either, more so security. So perhaps running blender would be better suited by FreeBSD.
But yes, it is x86 only.
No, it doesn't resolve dependicies. I'll refuse to use any OS at home that doesn't have a ports system of some sorts as it just makes life so much easier.
:(
And yes, you can compile them manually under Solaris no problem. Sun also supply them on a bonus CD. The problem is, they don't update them. Vuln in libpng? Update it yourself.
Portage is a superb tool. I'd really like to have a good ports system on normal Solaris, let alone OpenSolaris!
Erm, nope. emerge does not over-write any configuration files in /etc or anywhere else.
/etc/fstab, although he would have had to accept it.
If he runs etc-update, then it will prompt him which files it is going to update. So at this point, it would be possible to blindly accept an update to
emerge == safe.
etc-update == be careful!
I can't comment on smpatch, but I can comment on this. It is terrible.
Ok, sure, it does get all the patches applied. The problem is that it tries to re-apply patches that you've already got, on even on our fastest systems it still takes a long time for each patch to fail. On our desktop Ultra 5, it caused way too much trashing for each patch to fail. As least Redhat, Debian, etc etc only apply patches that are required.
I suppose the point is that Intel never really *wanted* to add them. AMD's sucess made them do it. Remember for a long time they even denied such a processor even existed, and that they never would make one. They wanted to push Itanium, which is now being relgated to high end number crunching only due to the this.
Anyway, as the other follow-up said. You'd be best off with AMD anyway, they're faster (2.4GHz Opteron is unmatched by any Xeon I've seen) and generate much less heat. Got a 4-way 2.4GHz Opteron box at work, and the heat out of the back is less than our dual processor Xeon boxes. The dual processor Opterons we've got run very cool.
From Redhat's release notes for the update 2 to RHEL3.
See for yourself:
Redhat.
He is the right, their drivers are that bad.
I've seen benchmarks for Doom 3 on Linux that show a 5900 beating an ATi x800XT..... there is NO WAY that should happen!
If you play games in Linux, Nvidia is the only option right now IMHO. I switched from ATi to Nvidia for this reason and I've never looked back.
Ah yes, the winter didn't work into the Germans favour that is for sure. Then again, those crazy Russians were just throwing men at the Germans and this man power was just always going to work in the long run. Also having some kick ass T-34 tanks which were the best available at the time helped, although I can't quite remember when they became available.
I think the channel mandidated the need for air superiority, otherwise we'd have been blitzkreig'd as well. Thankfully they never got it (yay for radar!) and we were just able to fend them off and eventually use ourselves as a base to invade France with help from the US, remaining French fighters, Canadians, etc.
Ultimately though, attacking Russia was really stupid. Given their size & man power, in the long run it was always going to be a losing fight.
I'm a Brit btw!
It isn't the same deal though. Thus:
1. Neither Germany nor Japan could attack contiental USA.
2. Germany & Japan did have other countries attacking their land however.
3. Germany & Japan had already been in war for 2 years before the USA got involved, which would have been a further drain on their resources.
4. Germany did it OVER LAND! Remember 25 miles of water was enough to save the UK, but when you can march straight back into the country that attacked you then you better win!
Then again, of course, Sun sell dual Opteron servers with RAID controllers. I'd be very surprised if Solaris didn't support them.
Try running Solaris x86 on desktop machines, you'll find the hardware support drops off very rapdily. Then again, this often isn't a problem as Solaris is used as a server OS. Like you said, soundcard support for Solaris isn't a problem!
Nope, I want ports.
Whilst that CD is good - it doesn't exactly get updated. What happens when a vulnerablity in libpng appears? I don't think you'll see Sun giving you one!
And what if you want something a bit more obsecure and it isn't on the CD? What if you want something that has been updated in the meantime?
1900MHz POWER5 - 2702 peak, 2571 base.
1500MHz Itanium 2 - 2161 peak, 2161 base.
The Itanium 2 wins SpecInt, by 10 points tho. Of course, in SpecINT they both get trashed by x86 Xeon & Opterons.
The Itanium 2 isn't bad, but I think POWER is simply better (and doesn't have other issues like a shared bus for memory access).
Not really, the Opteron core is better than the Athlon core. If you exclude the 64-bitness, you've still got:
1. SSE2.
2. On-board memory controller.
3. Higher IPC vs the Athlon.
4. Hyper-transport.
Remember, the Opteron is the next-gen core so it is a lot better anyway. Removing the 64-bit part is only one part, the rest is still excellent.
Of course, not as if Windows even has a 64-bit OS yet which is what matters for a lot of people (not me tho).
Aha, well I wasn't around in the ARPAnet days..... but my slashdot id is lower than yours! Nyr nyr! :)
Oooooh, nice of you to join us at last!
;)
5 digit UID?! Pah!
Pretty good, but not compared to to the other high end chips.
Itanium 2 & POWER 5 walk all over it. I suspect the Opteron will too quite easily, and it costs a lot less.
You're joking right? That is barely true. I suspect for integer performance, the Opteron is the strongest out of all of them. Look at the SpecINT scores, it is dominated by x86 at the top end (Xeons & Opterons) and they are way above everything else at all.
For FP, you're half right. The Itanium2 & POWER4/5 are more than a match for the Opteron and will beat it (especially the POWER5). SPARC & MIPS are waaaay slower. No-one uses them for raw MHz performance, more for a large number of CPU systems.
My REAL WORLD tests show the Opteron is 33% quicker MHz for MHz over Sun's UltraSPARC3/3i/3+ processors. That is a problem for them when the Opteron clocks so much faster too!
Linux, BSD, Windows - they're all junk! AmigaOS 4 is the way forward!!
Why don't you use 2.4 instead?
In the end, some guy spent many years tracking it down and eventually proving Fermat was correct! He has to invent some new maths theories as well to do this. Was Fermat that good?!?
Here is a good book if you fancy finding out more....Amazon. I've read it a few years back, it is good!
I'm surprised no-one has done this but.....
5. ????
6. Profit!
Care to explain that logic to me?!
We are comparing RH's enterprise only distro (in fact, the only thing they "officially" make these days) to SuSE's desktop distro - is it no surprising that RH's has more backported stuff as it has a 5 year lifespan???
See Redhat!
Care to tell me which ones of these features are also in the SuSE kernel?