Page 1 of 1

A multi thread compiler.

Posted: Fri Sep 30, 2005 1:29 am
by Isaac
I'm buying an AMD 64 4000 dual core chip. It will be overclocked to 2.6ghz. I need this for my 3d renderings but i would like take advantage of my dual core setup when i complie cpp code. Know any cpp compilers that can use an mpc

Posted: Fri Sep 30, 2005 1:29 pm
by DCrazy
What OS are you going to be running?

Posted: Fri Sep 30, 2005 2:06 pm
by Iceman
Visual C++ version 6 can be hacked to do so. There is a hack for VCSpawn.exe that will enable it to do multi-threaded compilation. I don't remember where I got it from so either google it or PM me for it.

Posted: Fri Sep 30, 2005 5:26 pm
by fliptw
Iceman wrote:Visual C++ version 6 can be hacked to do so. There is a hack for VCSpawn.exe that will enable it to do multi-threaded compilation. I don't remember where I got it from so either google it or PM me for it.
Multi-threading as in compling one object on multiple processors, or just compiling multiple objects on mutliple procs?

Posted: Fri Sep 30, 2005 6:59 pm
by DCrazy
Multithreading != Multiple Processors (almost but not quite). VC++'s COM threading model might prevent it from running on multiple processors (I'm pretty sure that's the MFC default, and VC++ <= 6 is an MFC app) regardless of whether it can run multithreaded.

Besides, wouldn't compiling the same object file in multiple threads be infeasible (constantly having to put symbol trees, etc. in spinlocks)? I can see multiple objects on multiple processors causing deadlock as well, but there would be ways around that. The conflicts would be far less frequent than compiling the same object file over multiple processors.

Posted: Sat Oct 01, 2005 12:52 am
by Isaac
DCrazy wrote:What OS are you going to be running?
win xp pro 64

Posted: Sat Oct 01, 2005 12:54 am
by fliptw
My thinking also is that compilers would be one of the few things that would not benefit from multiple processors or multiple threads for an individual program, hence the odd way I phrased the question.

Because, the obvious benefit with SMP wrt to compiling is the ability to execute more than one compile instance and have the load shared between the processors.

And does Xp64 have a good set of drivers yet? I'd stick with Xp Pro personally for now.

Posted: Sat Oct 01, 2005 12:57 am
by Isaac
Iceman wrote:Visual C++ version 6 can be hacked to do so. There is a hack for VCSpawn.exe that will enable it to do multi-threaded compilation. I don't remember where I got it from so either google it or PM me for it.
I'd like to avoid Visual Cpp if i could, but i KNOW a hack isnt the answer to this problem. You know there are plenty of people who compile huge tasks everyday on opterons or cpu racks.... unless hacking your compiler is the norm in the computer programing world.

Posted: Sat Oct 01, 2005 1:01 am
by Isaac
DCrazy wrote:Multithreading != Multiple Processors (almost but not quite). VC++'s COM threading model might prevent it from running on multiple processors (I'm pretty sure that's the MFC default, and VC++ <= 6 is an MFC app) regardless of whether it can run multithreaded.

Besides, wouldn't compiling the same object file in multiple threads be infeasible (constantly having to put symbol trees, etc. in spinlocks)? I can see multiple objects on multiple processors causing deadlock as well, but there would be ways around that. The conflicts would be far less frequent than compiling the same object file over multiple processors.
oohhh aahhh

Posted: Sat Oct 01, 2005 9:00 am
by fliptw
you'd need a compile spawner(gnu make, nmake and the ilk) thats smart enough to spawn multiple instances of the compiler in order to take advantage of it.

VC pretty much does not do that by default. But you asked for multi-threaded compilers, which isn't the same thing.

Posted: Sat Oct 01, 2005 5:39 pm
by DCrazy
Well, Isaac, that's pretty much what I was saying. Same object file across multiple threads/processors gives no benefit. I just think that because of the dependencies that object files have on each others' compilation, you won't see much of a performance gain by compiling separately in a complex application.

Posted: Sat Oct 01, 2005 11:13 pm
by Isaac
DCrazy wrote:Well, Isaac, that's pretty much what I was saying. Same object file across multiple threads/processors gives no benefit. I just think that because of the dependencies that object files have on each others' compilation, you won't see much of a performance gain by compiling separately in a complex application.
It sounds like i should just compile the reguar way, right? It would be too hard to do this on windowsxp pro.

Posted: Sun Oct 02, 2005 4:37 am
by Sirius
Ain't gonna break anything if code takes a long time to compile. At least the pain isn't ongoing when it's done - and, not to mention, the project needs to be pretty big to make it noticeably slow anyway (and even then only on the first compile unless the dependency relationships resemble spaghetti).

Posted: Tue Oct 11, 2005 1:50 am
by SirWinner
Dual Processors are nice... But unless your Operating System and the programs that you are using are using BOTH processors... It isn't going to do you much good.

We had a network server many years ago that used Dual Processors and a Novell Netware Version that was optimized for Multiple Processors... It was a very very nice server environment.

:oops: