engineer needs advice

Get a dualie athlonmp board, then run 2x 1.2athlon mp's, if you can find one which overclocks overclock them both to 1.4(they all will go there without trouble) that setup will OWN everything else in the world.

~Matisaro~
"Friends don't let friends buy Pentiums"
~Tbird1.3@1.55~

*cough*bullshit*cough*
I truly find it hard to believe that a single processor is going to beat duals in an SMP enabled program. My lovely PIII 700 isn't as fast as our dual PII 350s are in file management and serving...

----------------------
Independant thought is good.
It won't hurt for long.

Juin, thats the most ignorant and utter bs statement I have ever heard you make.

~Matisaro~
"Friends don't let friends buy Pentiums"
~Tbird1.3@1.55~

LoL, juin...that was just bad.

~Matisaro~
"Friends don't let friends buy Pentiums"
~Tbird1.3@1.55~

If you are really interested in fast code, I would suggest that you <i><b>not</b></i> rely completely on gcc 3.0.x.

1) gcc 3.0.x is still, IMHO, beta quality. There's a whole hell of a lot of source code out there that it either won't compile or miscompiles. glibc 2.2.4 will supposedly actually refuse to be compiled with gcc 3 because of all the bugs and incompatibility.

2) even though gcc 3 is supposed to produce faster code, it actually turns out to produce slower code for a lot of things--especially the kernel. When I last opened my inbox to the flood from linux-kernel@vger.kernel.org, gcc 3's production of slow code was an ongoing issue.

gcc 3 is supposed to have much better java support, but for performance code, I personally would go with c or c++ anyways.

If you plan to use gcc with glibc 2.2.2 or higher, I'd advise that you use gcc 2.95.3 and get your hands on <A HREF="http://ftp://ftp.linuxfromscratch.org/cvs/gcc-2.95.3-2.patch.bz2" target="_new">the gcc "weak symbols" patch</A>. With this patch, you can actually compile a "proper" glibc (and a lot of other "proper" things) with 2.95.3.

With some fancy dancing, you can have both gcc 2.95.3 and gcc 3.0.1 on the same system if you want to experiment with both of them. I can give you some fairly simple instructions if you want to do this. And of course, you could always give Intel's compiler a shot, though I don't know if you can run Intel's compiler and gcc at the same time.

In any case, back to your original question. I'd go with dual Athlon MP 1.2's. They tend to mop the floor with P4 Xeons, even on P4 optimized code like Photoshop.

And on to other matters...

Juin, that was the most idiotic BS post I've ever seen! If you actually had some credible links (i.e. benchmarks) to back up that claim, I'd have a bit more respect for it. I doubt you've actually seen the Northwood in action, I <i>seriously</i> doubt it will reach 3.5GHz before 2003, and you spout this Intel marchitecture crap like it's gospel? Shame on j00!

Kelledin

"/join #hackerz. See the Web. DoS interesting people."

(Northwood == not released) ==> (Northwood==0MIPS+0FLOPS at 0MHz)

Thus, clock-for-clock performance of Northwood is 0/0.

By principles of calculus, 0/0 is an undefined quantity--it could be anything. However, the result can be refined by knowing the series upon which the numbers are based.

It is a given that CPU performance is derived from technical innovation on the manufacturer's part, so we establish a series of values for the coefficient of innovation. Now if we examine the series of mistakes that Intel has made, beginning with <i>i</i>=(release_of_buggy_Pentium) to <i>i</i>=(way_too_late_release_of_Northwood) we realize every element <i>S</i>(<i>i</i> )of the series is equal to 0, where each element <i>S</i>(<i>i</i> ) is Intel's coefficient of innovation at instance <i>i</i>. Thus Sigma (sorry, I don't have the keymaps for Greek letters) converges on 0. So the clock-for-clock performance--and in fact, the total performance of Northwood--is currently equal to 0.

Wait, you don't need calculus to figure that out...

Kelledin

"/join #hackerz. See the Web. DoS interesting people."

P.S. the above is a joke at Intel's expense. If you can't take a joke that isn't even at your expense, I suggest you go hump a tree or something. The tree probably cares for your opinion slightly more than I do.

If you're Raystonn, on the other hand...well, sorry, I couldn't resist. The full moon was calling.

Thanks for useful advice Kelledin, that really seems to hard to come by

I've never used gcc 3.0.x on my system, upon hearing what other people have said along your lines. By the time I finalize project details, I hope that 3.x.y will be out with problems fixed. Are performance issues of gcc 3.0.x fundemantal that proably won't be fixed in coming 3.x.y (at least for sufficiently small values of x,y) versions ? I heard that best compiler for athlon optimizations is gcc (the langugae will be C++ unless I someone convinces me that bothering to rewrite libs in C or fortran really worth the effort)is that correct? is there some "amd compiler" like the intel one?

My interest in intel's compiler was that it could produce efficient sse2 code, not merely p4 optimized code. Obviously I will use windows version (is linux version released yet?), if I use it at all. Considering the latest 2ghz p4 benchmarks on this site, if divx encoding is an accurate example of memory bus hungry+fp dominated processing, 2*1.4Ghz athlons would be slower than a single 2ghz p4, even if I could use both processors to full extend. What leads you to think that photoshop is a better example of such processing than divx encoding? (no offense)

The task is basically NN training, in case anyone is interested... opps, just realised, are there hyperbolic functions in SSE2 instruction set?

Not sure about the best Athlon-centric compiler. There was an Athlon GCC project going on at <A HREF="http://www.athlonlinux.org/" target="_new">http://www.athlonlinux.org/</A> some time ago, but it seems to have stalled--and the patches left don't seem to patch into gcc 2.95.3 all that well =/. I suppose you could go back to 2.95.2 or the like, just don't run glibc-2.2.2+ with it!

One interesting thing I've heard (not actually confirmed yet) is that gcc 3.0.1 can actually produce Athlon-optimized code (by using gcc -mcpu=athlon -march=athlon). Whether 3.x.y will be fixed (to 2.95.3 quality, at least) anytime soon is anyone's guess...really, the best you can do is install both versions and run your own benchmarks/tests tailored for your scenario.

As for the Intel compiler, it's reported that the Athlon actually gains quite a bit of performance (around 20-30%!) when code is compiled with Intel's compiler--so it's probably worth looking into, even if you don't get a P4. Last I heard, it was available as a beta, but you had to sign up for it.

Kelledin

"/join #hackerz. See the Web. DoS interesting people."