On 2 February 2012 13:09, Marie E. Rognes <m...@simula.no> wrote: > > Thanks for starting to take care of this Johan! > > However, it does not completely resolve the issue for me: > > Building the most recent 1.0.x and trunk on my laptop, > by clearing the build directory, and running cmake.local > gave the following (rough) timings for the Python stage: > > 1.0.x (aka 'old'): ~3 min 21 s > trunk (aka 'new'): ~ 3 min 23 s > > These timings are for not doing anything else at the same > time except staring at the screen. >
Did you use 'make -jX'? I would expect building with one process to take about the same time, but I see is that I can now build the SWIG interface files in parallel. I haven't timed the difference. > The 'new' still uses so much memory that doing > anything else at the same time is very painful. > I see less < 1GB for each module, whereas before I think that it was more like > 2GB. Garth > -- > Marie > > > > On 02/01/2012 05:23 PM, Johan Hake wrote: >> >> Hello! >> >> I have now splitted the SWIG interface into 6 combined modules. >> >> common, io, mesh, function, fem, la >> >> The largest .cxx file generated now is 2MB (for la with all linear algebra >> backends installed), instead of 6MB. That is still pretty big and take >> some >> 1GB of memory during compilation. But the interface can now be generated >> in >> several threads, reducing compile time considerable. The runtime memory >> print, >> read from a simple top, is not much more than before (some 100MB), which >> is >> good. >> >> They new compiled modules all resides under: >> >> dolfin.cpp.foo >> >> All types and functions are now automatically included into: >> >> dolfin.cpp >> >> which means that most modules under site-packages/dolfin still works fine. >> There are now more types included from the compiled interface by default. >> If >> this is a problem we can change that. But now everything is automated. No >> handpicking done. >> >> The logic in the new SWIG interface is described in: >> >> dolfin/swig/README >> >> One thing to be aware of is that any reference to the compiled interface >> from >> another combined module have to be preluded with the name of the module. >> Example, in la/post.i we call dolfin_error, which is defined in common. >> Then >> we do: >> >> common.dolfin_error(...) >> >> instead of previous: >> >> dolfin_error(...) >> >> Have fun and let the bug reports come raining! >> >> Johan >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dolfin >> Post to : dolfin@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dolfin >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
