Compile time...I'm confused...

[ksignorini]

OK, well, just for fun I compiled BitchX side by side on the following two machines:

In the blue corner, a PM G4 733 with 640 MB RAM running OS X 10.2 (Jag).

In the red corner, an AMD K6-2 500 with 128 MB RAM running FreeBSD 4.6.2.

Well, I ran the configure script and the AMD won by about 20 seconds. No biggy, I thought. I mean, the configure scripts will check different things depending on what they find. Then I ran the make (compile).

In the red corner, the lowly AMD K6-2 500, it took all of 2 minutes and 53 seconds to compile. Pretty slow, but it's a 3 year processor technology for the PC.

In the blue corner, my "supercomputer," it took 4 minutes and 45 seconds!!!!!!

What the heck is going on here? I thought this was a supercomputer?! I thought that the C compiler was optimized to use my Altivec super-duper-cruncher-thingy!?

Why did it compile so darn slow? Am I the only one with a similar compile time?

p.s. Oh, and by the way, the FreeBSD box was running KDE 3.0 in high res at the time--probably the heaviest GUI there is for UNIX. I didn't check other running processes but I can tell ya, there ain't much running in the background of either right now besides the GUI and a couple Internet dameons launched from inetd.

Kent!

 

[ulrik]

welcome to the real world.

I am still laughing my ass off that my three year old Quad Xeon 500 SGI 540 is over 900% faster in render times (regardless which raytracer, Lightwave, Maya, C4D, the result is always more or less the same) than my current 1 Ghz G4.

It's so sad...but I stopped whining about this a long time ago...I just bought an SGI Onyx2

 

[alexrd]

Some other things that may be at play:

-Every spped advantage that OSX has, FreeBSD has it beat. It's a similar core, but without the microkernel overhead or the aqua stuff that mach alows. Try that same compile in a MS environment, I bet it'll be slower...

-Compiler optimization. If I'm not mistaken, AMD (and Intel, for that matter) put quite a bit of work into gcc, so that it both runs faster, and produces faster machine code. The apple supplied tools have gotten much better, but they've still got a ways to go (c'mon apple, how about some limited Altivec automation)

Just some thoughts....

-alex

 

[danzig]

Originally posted by ulrik
welcome to the real world.

I am still laughing my ass off that my three year old Quad Xeon 500 SGI 540 is over 900% faster in render times (regardless which raytracer, Lightwave, Maya, C4D, the result is always more or less the same) than my current 1 Ghz G4.

It's so sad...but I stopped whining about this a long time ago...I just bought an SGI Onyx2

ok, ulrik you have got an "old" machine but it's a quad processor and not so slow processor. Do you really think the fastest today processor (single-processor machine) can beat it?!
SGI machines are built to do that (rendering and so), so they are optimized for doing that, not, say...doing seti calculation (I'm just making an example).
It depends by the kind of data you have to deal with....c'mon is a veeery old "war"...

G4 are good processor and apple made a good work with its software, may be they are a bit new to unix side of the world....and on BSD side you know there are some flavor built with speed target, other with security and so on.

 

[ulrik]

Originally posted by danzig
ok, ulrik you have got an "old" machine but it's a quad processor and not so slow processor. Do you really think the fastest today processor (single-processor machine) can beat it?!
SGI machines are built to do that (rendering and so), so they are optimized for doing that, not, say...doing seti calculation (I'm just making an example).
It depends by the kind of data you have to deal with....c'mon is a veeery old "war"...

G4 are good processor and apple made a good work with its software, may be they are a bit new to unix side of the world....and on BSD side you know there are some flavor built with speed target, other with security and so on.

Sorry, but your facts are wrong. First, the XEON is just a pumped up P3 (the old XEON i mean), and sure it should be faster, but 900%??? Also, raytracing is pure number crunching, a VW540 isn't built towards raytracing any more than a G4 is.
When it comes to SETI, I should inform you that one of my 180 Mhz Onyx2 CPUs beats a 2.2 Ghz AMD, so yes, my Onyx2 is a number-cruncher (maybe that's why the SGI team is top-ten in the SETI list). Also, when you compile, there is nearly no overhead to the compiling process. And yes, my Quad XEON get's beaten by a single CPU 3.06 Ghz P4.

Fact is that the G4 isn't that fast, peroid. 2,2 Ghz AMDs are kicking the dual 1.25 Ghz G4s in EVERY Photoshop benchmark on the net! Recently, there Slashdot had some Photoshop and After Effects benchmarks, and the Dual 1.25 Ghz G4 was beaten by a single CPU 3.06 Ghz P4 Laptop in every single test.

I am using a G4 myself since it is a fine machine, but it is a slow processor, nothing else.

 

[danzig]

Originally posted by ulrik
Sorry, but your facts are wrong. First, the XEON is just a pumped up P3 (the old XEON i mean), and sure it should be faster, but 900%??? Also, raytracing is pure number crunching, a VW540 isn't built towards raytracing any more than a G4 is.
When it comes to SETI, I should inform you that one of my 180 Mhz Onyx2 CPUs beats a 2.2 Ghz AMD, so yes, my Onyx2 is a number-cruncher (maybe that's why the SGI team is top-ten in the SETI list). Also, when you compile, there is nearly no overhead to the compiling process. And yes, my Quad XEON get's beaten by a single CPU 3.06 Ghz P4.

yes you are right, I was only making an example about seti (and you are right..I kon sgi are big crunchers...fact is I was inetding some on my native tongue and was not so good in english...;-)

Fact is that the G4
isn't that fast, peroid. 2,2 Ghz AMDs are kicking the dual 1.25 Ghz G4s in EVERY Photoshop benchmark on the net! Recently, there Slashdot had some Photoshop and After Effects benchmarks, and the Dual 1.25 Ghz G4 was beaten by a single CPU 3.06 Ghz P4 Laptop in every single test.

I am using a G4 myself since it is a fine machine, but it is a slow processor, nothing else.

I'm sure this are fact...but I was stumbling when you have "compared" a quad processor with a single.

I had a g4 processor too and like you I can say it is not a magnificent processor (so..a good but not super processor...my duron 1000@1200 do things with more speed..but is another platform, OpenBSD)
So like other things...apple say they are winners....intel says the same thing...amd...and so on...the real thing is commerce.
I think the discussion will be better on operating system not on processor.

 

[ulrik]

Originally posted by danzig
I think the discussion will be better on operating system not on processor.

It depends. For most people, yes. Most people use the computer for tasks like writing documents, surfing the net, doing a little graphic work etc. For those people, an easy to use, stable operating system is more important than raw processing power.

Other people, for example people in the DV business, who spend eight hours a day inside After Effects, need the fastest processors they can get. They don't care wether their OS is more intuitive than another OS, they have one or two applications they use and they need these apps to be fast. Same goes for example for people in the 3d compositing business, where you have to produce several test renders a day, and where every minute is important.

People should base their decision on these facts when they purchase a system.

It is stupid to say that one system is better because it is faster than another system. It depends on the fact what you need.

 

[onan]

Much of the problem is that you're building binaries for different architectures. Binaries for risc instruction sets tend to be 70-100% larger than those for cisc instruction sets, and compile times are correspondingly longer.

And no, I don't believe that any version of gcc uses altivec for the compilation process, though Apple's version can create binaries which use it.

You may want to profile the build process a bit more, and see whether the cpu is even the significant bottleneck. It's not unusual for current cpus to be fast enough that they're more constrained by disk access when compiling. If the disks are approximately the same speed, and you're building a binary that's nearly 100% larger, that would pretty much explain your entire speed difference, without the cpu speed being relevant at all.

You could also test this further by cross-compiling the ppc binary version on the amd, or vice-versa.