I downloaded it. Switches to full screen, then back to a window. Mouse doesn't work. Let's see...
BTW, does anyone else have the following inside ut2004demo (Postal2 ?!)
if [ -x "${UT2004DEMO_DATA_PATH}/ut2004-bin" ] then
cd "${UT2004DEMO_DATA_PATH}/"
exec "./ut2004-bin" $* fi echo "Couldn't run Postal2 Demo (ut2004-bin). Is UT2004DEMO_DATA_PATH set?"
I highly recommend Victor Pelevin's "Omon Ra" as the true account of the Soviet space program (actually, I read it on the same day as the story about sending people to Mars was on/. and couldn't believe the coincedence)
All I can say - competition is good. If Watcom is a decent compiler and will be able to compile kernel and Linux distro I am very glad. Most likely gcc team look critically what is good and what is bad and improve things were needed.
I wonder what makes you think so? I once tried to squeeze max performance of a program that had to run on 8 cpu sparc box (each @750Mhz) with 16G mem. (is it "toy" machine or not? read on) The program was nothing fancy: binary search in an array of 64bit packed structs of the total size ~2GB (so we could run 8 processes simultaneously in 16G), plus some postprocessing.
First observation: 64bit mode was twice faster than 32bit one (you sort of expect that).
Second observation: gcc with "-m64 -O3" produced code that was 2% slower than the best I could get from Workshop5 compiler and was 5% faster from what I could get from Workshop7 (or whatever is the latest). I'm not sparc expert, but I read all their recommendation on the web, man pages and played with "advanced" options, like prefetch, etc. Actually, 2-5% may be a measurement errors, as I didn't repeat tests many times (though I compared results)
Third: even the fastest fastest code was 3 times slower than performance of P4@2.8Ghz on the same inputs, so dual P4 with HT enabled would likely to provide me with the same raw performance. I wish I could test Opterons in 64 bit mode!
Of course, I can believe that there are some applications where workshop's cc is significantly better, but I never encoutered them.
GCC is an excellent compiler. I was surprised why it didn't beat SUN's CC. In my experience, gcc frequently generates code which is at least as good or slightly better than vendor's compiler (at least for DEC, SPARC and Intel platforms). There are special cases, say OpenMP, SSE2, ect, when vendor's compiler does a better job (and gcc currently doesn't support openmp), but in most cases I can easily believe that gcc will be the best. In addition, knowing that a certain version of gcc compiled 8000 Debian packages for 10 different platforms and didn't failed (or if failed, a bug was submitted) is a good indicator that you can trust this compiler. Add to this that compiler gets better with each release and I think it will soon be what Linux is for UNIX - making the rest obsolete.
Running benchmarks on a laptop is at least strange. Benching simple loops is telling, but telling wxactly what? That java is good for empty loops? A much more interesting comparison would be to see how commonly used idioms scale/perform in different languages. For example, say I extensively use maps, how expensive is map in Java, C#, Perl, etc? Can I insert 200M elements? what is the average time of insertion, etc.
In one of the projects we were bounded to use a 8-way Sparc 750Mhz with 16G of mem. First of all, it was noticeably slower than a dual P4 that I used for development, but the most amazing thing was how unfriendly the environment was. Solaris 8 (I think it was 8, not 7) is hyped as a 64bit OS, but let see: -/usr/bin/perl, shell, gzip, etc. - no support for files >2G - tar (not GNU tar) - died somewhere after putting 27G on tape - awk (not gawk) - can't accept > 512 fields, a feature I constantly need. - regexp() - segfaulted deep in libc when parsing lines of length >40K both in 32 and 64 bit mode (no solution, in the end I managed to split the lines and merge the results) - you cannot fopen() more than 256 files simultaneously!!! (FILE has "char" for fd : looks simply ridiculous on a box with 16G)
Overall, I lost *a lot* of time fighting bugs and problems that my Debian distro solved many many years ago. I must say I was glad when benchmarks showed that gcc produced slightly faster code for my program than the hyped workshop's cc with all optimizations on (it fits the whole picture very nicely). I'm also not convinced SUN's hardware is any better than IBM's or DeLL's Pentium boxes: my experience is the opposite, but that's a different story.
HT is not completly transparent. For example, MTRR registers are not per virt. processor abd need more care. So you need to modify SMP kernel to (correctly) support HT. At least that's my impression from reading newsgroups.
I tested HT on dual Xeon and my experience is VERY positive. My opinion is that 20% speed improvement is very conservative: my experience shows that code written with HT in mind (see Intel's develop. guide), gets 50% speed-up (compiled with icc). Many other standard tools I use daily (like BLAST) show significant improvement too. In fact, for my applications, to reach 2*2.8 Xeons I need something like 8*750Mhz Ultra3 CPUs or 4*667 EV67:) This is quite impressive for me, if cost is taken into the picture!
In general, I think HT is a very clever idea allowing much better use of CPU. I hope they'll come up with 4* and more. This is also an interesting challenge for M$: now, when in 6 months SMP is on every desktop, all kernel internals suddenly need to be SMP safe (including third party buggy drivers): looking back at the long way Linux evolved to the current state and multiplying on their rate of innovation, it's not going to be trivial (good for Linux, of course).
Slashdot Mirror
got it, export LD_ASSUME_KERNEL=2.2.5 solved the problem
I downloaded it. Switches to full screen, then back to a window. Mouse doesn't work. Let's see...
BTW, does anyone else have the following inside ut2004demo (Postal2 ?!)
if [ -x "${UT2004DEMO_DATA_PATH}/ut2004-bin" ]
then
cd "${UT2004DEMO_DATA_PATH}/"
exec "./ut2004-bin" $*
fi
echo "Couldn't run Postal2 Demo (ut2004-bin). Is UT2004DEMO_DATA_PATH set?"
exit 1
I highly recommend Victor Pelevin's "Omon Ra" as the true account of the Soviet space program (actually, I read it on the same day as the story about sending people to Mars was on /. and couldn't believe the coincedence)
All I can say - competition is good. If Watcom is a decent compiler and will be able to compile kernel and Linux distro I am very glad. Most likely gcc team look critically what is good and what is bad and improve things were needed.
I wonder what makes you think so? I once tried to squeeze max performance of a program that had to run on 8 cpu sparc box (each @750Mhz) with 16G mem. (is it "toy" machine or not? read on) The program was nothing fancy: binary search in an array of 64bit packed structs of the total size ~2GB (so we could run 8 processes simultaneously in 16G), plus some postprocessing.
First observation: 64bit mode was twice faster than 32bit one (you sort of expect that).
Second observation: gcc with "-m64 -O3" produced code that was 2% slower than the best I could get from Workshop5 compiler and was 5% faster from what I could get from Workshop7 (or whatever is the latest). I'm not sparc expert, but I read all their recommendation on the web, man pages and played with "advanced" options, like prefetch, etc. Actually, 2-5% may be a measurement errors, as I didn't repeat tests many times (though I compared results)
Third: even the fastest fastest code was 3 times slower than performance of P4@2.8Ghz on the same inputs, so dual P4 with HT enabled would likely to provide me with the same raw performance. I wish I could test Opterons in 64 bit mode!
Of course, I can believe that there are some applications where workshop's cc is significantly better, but I never encoutered them.
GCC is an excellent compiler. I was surprised why it didn't beat SUN's CC. In my experience, gcc frequently generates code which is at least as good or slightly better than vendor's compiler (at least for DEC, SPARC and Intel platforms). There are special cases, say OpenMP, SSE2, ect, when vendor's compiler does a better job (and gcc currently doesn't support openmp), but in most cases I can easily believe that gcc will be the best. In addition, knowing that a certain version of gcc compiled 8000 Debian packages for 10 different platforms and didn't failed (or if failed, a bug was submitted) is a good indicator that you can trust this compiler. Add to this that compiler gets better with each release and I think it will soon be what Linux is for UNIX - making the rest obsolete.
Running benchmarks on a laptop is at least strange. Benching simple loops is telling, but telling wxactly what? That java is good for empty loops? A much more interesting comparison would be to see how commonly used idioms scale/perform in different languages. For example, say I extensively use maps, how expensive is map in Java, C#, Perl, etc? Can I insert 200M elements? what is the average time of insertion, etc.
In one of the projects we were bounded to use a 8-way Sparc 750Mhz with 16G of mem. First of all, it was noticeably slower than a dual P4 that I used for development, but the most amazing thing was how unfriendly the environment was. Solaris 8 (I think it was 8, not 7) is hyped as a 64bit OS, but let see: /usr/bin/perl, shell, gzip, etc. - no support for files >2G
-
- tar (not GNU tar) - died somewhere after putting 27G on tape
- awk (not gawk) - can't accept > 512 fields, a feature I constantly need.
- regexp() - segfaulted deep in libc when parsing lines of length >40K both in 32 and 64 bit mode (no solution, in the end I managed to split the lines and merge the results)
- you cannot fopen() more than 256 files simultaneously!!! (FILE has "char" for fd : looks simply ridiculous on a box with 16G)
Overall, I lost *a lot* of time fighting bugs and problems that my Debian distro solved many many years ago. I must say I was glad when benchmarks showed that gcc produced slightly faster code for my program than the hyped workshop's cc with all optimizations on (it fits the whole picture very nicely). I'm also not convinced SUN's hardware is any better than IBM's or DeLL's Pentium boxes: my experience is the opposite, but that's a different story.
HT is not completly transparent. For example, MTRR registers are not per virt. processor abd need more care. So you need to modify SMP kernel to (correctly) support HT. At least that's my impression from reading newsgroups.
I tested HT on dual Xeon and my experience is VERY positive. My opinion is that 20% speed improvement is very conservative: my experience shows that code written with HT in mind (see Intel's develop. guide), gets 50% speed-up (compiled with icc). Many other standard tools I use daily (like BLAST) show significant improvement too. In fact, for my applications, to reach 2*2.8 Xeons I need something like 8*750Mhz Ultra3 CPUs or 4*667 EV67 :) This is quite impressive for me, if cost is taken into the picture!
In general, I think HT is a very clever idea allowing much better use of CPU. I hope they'll come up with 4* and more. This is also an interesting challenge for M$: now, when in 6 months SMP is on every desktop, all kernel internals suddenly need to be SMP safe (including third party buggy drivers): looking back at the long way Linux evolved to the current state and multiplying on their rate of innovation, it's not going to be trivial (good for Linux, of course).