Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] Compiling ParticleCGT.cc on Intel Macs


Chronological Thread 
  • From: <thiago@cs.utah.edu>
  • To: James Bigler <bigler@cs.utah.edu>
  • Cc: manta@sci.utah.edu
  • Subject: Re: [MANTA] Compiling ParticleCGT.cc on Intel Macs
  • Date: Thu, 26 Jul 2007 14:40:00 -0700
  • Importance: Normal
In the future, could we implement a policy whereby individual projects are 
implemented outside of manta in a manta project (ask abe for details) or in a 
branch unitl the code is stable enough to be put in the trunck? I think that 
would benefit both sides since the new code can be written without worrying 
that manta might get broken for everyone else and the rest of the manta 
community doesn't have to deal with the bugs that come about when 
implementing a big project. My personal rule is to never commit any code into 
manta's trunk that I know isn't working (and it seems most others follow that 
as well.)
  
Thiago

-----Original Message-----

From:  James Bigler <bigler@cs.utah.edu>
Subj:  Re: [MANTA] Compiling ParticleCGT.cc on Intel Macs
Date:  Thu Jul 26, 2007 1:30 pm
Size:  2K
To:  
cc:  manta@sci.utah.edu

I don't really care what you do to make it better, but on my linux machine 
using 
GCC 4.0.2 it consumes just under 1 GB of memory each to compile this file and 
the pnrrd scene.

James

Carson Brownlee wrote:
> For now the templates can  be reduced in TrvMajor since there is no 
> implementation of the function for non common origin packets yet anyway 
> if that might help.  It seems to compile fine on my machine which is 
> odd, and I still don't understand why it would be much worse than 
> CGT.cc, as they are very similar files with the same templates.  If what 
> you say about GCC deciding to inline all the functions, if I broke it 
> into two functions wouldn't it just be identical?  Perhaps it would make 
> it a little cleaner anyway though.
> Carson
> 
> 
> On Jul 26, 2007, at 7:53 AM, James Bigler wrote:
> 
> I've seen it on linux.  That file consumes enormous amounts of memory 
> and time to compile.  This is usually due to templates inlining the 
> world into a single function.
> 
> GCC seems to be able to handle large source file as long as individual 
> functions don't get too large.
> 
> My guess is the use of the templated traverse and TrvMajor functions 
> that are causing problems.  TrvMajor is about 800 lines of code.  It is 
> included in traverse 8 times (6400 lines of code + plus other std 
> template stuff).
> 
> I suspect if you broke traverse and or TrvMajor into smaller pieces the 
> time and memory requirements to compile will go down.
> 
> I also seem to remember some time ago there was a GCC bug that caused 
> exponential growth of memory based on the number of variables in a 
> function, but I don't recall all the details.
> 
> James
> 
> Christiaan Paul Gribble wrote:
>> I've noticed the same thing on my Intel Mac, but I'm not sure why.  I 
>> can't say that I've noticed it under Linux, but I haven't checked lately.
>> C
>> On Jul 26, 2007, at 1:13 AM, Austin Robison wrote:
>>> So for some reason that I haven't been able to figure out in my 
>>> cursory searches, compiling ParticleCGT.cc on an Intel mac (tested on 
>>> both my laptop and Steve's machine) requires a huge (~2GB) amount of 
>>> memory and takes much longer to compile than other .cc files, 
>>> particularly on machines where this induces massive amounts of paging 
>>> death...  It seems to be just fine on the G5 I tested the compilation 
>>> on, and I haven't heard of any problems from anyone else who I assume 
>>> are using linux.
>>>
>>> Any ideas?
>>>
>>> ~Austin
> 






Archive powered by MHonArc 2.6.16.

Top of page