Manta Interactive Ray Tracer Development Mailing List

Text archives Help


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


Chronological Thread 
  • From: Carson Brownlee <brownlee@cs.utah.edu>
  • To: <thiago@cs.utah.edu>
  • Cc: manta@sci.utah.edu
  • Subject: Re: [MANTA] Compiling ParticleCGT.cc on Intel Macs
  • Date: Thu, 26 Jul 2007 16:13:03 -0600
In my defense this is exactly what I have been doing with other projects and I asked this same question before I added the code to Manta. The ParticleCGT code would have been added at one point or another though, and I probably wouldn't have even noticed the compile problem on my machine. Sorry for any inconvenience.
Carson


On Jul 26, 2007, at 3:40 PM, <thiago@cs.utah.edu> wrote:

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