engineer needs advice

[Guest]

I'm planning to buy a new system to replace my good old athlon 500. I want to replace it with another athlon as I admire its perfomance and I dislike intel a lot. This is my thesis year, and I'll be doing a lot of number crunching for my thesis, which would take perhaps some 2000hrs on my athlon 500 (a very rough estimate.) I'll be doing that with my own code. That leaves me in a difficult position, on one hand SSE2 is damn fast, and 64 bit precision is quite enough for me, on the other hand I definetly don't want to buy an intel unless I really have to. The task at hand can be multi threaded and it tortures memory bandwidth as much as fpu. What would you suggest, an mp athlon board, an nforce (I can wait a few more months) or a P4? Thanks in advance.

Note: Although I'm not tight on budget, and it might even prove to be cheaper, a multi pc solution is out of question.

 

[Matisaro]

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~

 

[juin]

a single northwood will be as faster in SMP apps that a dual t-bird mp.

 

[74merc]

*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.

 

[Guest]

Additional info : I won't (well..can't..) hand optimize, the whole processor specific optimisations will be what the compiler (probably gcc3.x for athlon, and intel's compiler for p4) can manage. So it is not a battle between pure cpus, but cpu+compiler+chipset+memory combinations. Please consider that too.

 

[Matisaro]

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~

 

[juin]

It true that it a bit over push

 

[Matisaro]

LoL, juin...that was just bad.

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

 

[mbetea]

i'm sorry to ask but i have to know, juin, do you type what you have to say and use that translator on yahoo?

CPUs are like testicles, every computer should have 2!

 

[Kelledin]

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! :tongue:

Kelledin

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

 

[khha4113]

a single northwood will be as faster in SMP apps that a dual t-bird mp.

Where is the <b><font color=red>Northwood</b></font color=red>???
And <b>PROOF</b>???

Good or Bad have no meaning at all, depends on what your point of view is.

 

[Kelledin]

(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. :tongue:

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

 

[Guest]

Juin quiet up now your being rude.

Juin you been a bad boy goto your room

 

[Guest]

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?

 

[Matisaro]

Nusuth, check out hardocp's reviews of the p4 vs athlon, toms benchmark results come off as a tad bit screwy. PS: divx encoding is more cpu intensive than bandwidth intensive.

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

 

[Kelledin]

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."