From: Derek G. <fri...@gm...> - 2009-10-27 13:45:42
|
On Oct 27, 2009, at 3:33 AM, Tim Kroeger wrote: > I see. Anyway, at least it should be possible to replace some of the > pointers with ints or short ints (or perhaps chars). I mean, one > could make the arrays one-dimensional and then manage an array of > offsets for the systems instead. Since _n_v_comp and _dof_ids are > private in DofObject, the necessary changes should be manageable. Do > you agree? Would such a change be welcome if I implemented it? This just feels like over optimization to me. We're talking about _Mega_ bytes here. I'm wary of making this more complicated / less understandable / slower to save MBs. But, it's not really my call either... > It would save some memory, but possible at the cost of time. I don't > know how often this information is accessed. If it is read in each > assembly, it could slow down things noticably. > > Still, there must be some other memory glutton in my application which > I have not found yet. Does anybody know how PETSc's memory > consumption behaves in 64-bit mode? Have you tried recompiling your application in 32-bit to make sure that's the problem? Even on a 64bit machine you can compile for a 32bit target and everything will run fine. Have you checked out older versions of your application and libMesh to make sure it wasn't some change that you were unaware of? I haven't noticed any large difference in memory usage in switching back and forth between 64bit and 32bit. On my mac I used to regularly build 32bit with gcc and 64bit with Intel and never saw a 30% difference in the memory usage of my application. I'm not saying it's not possible... but I do think you need to eliminate some variables before you drive yourself crazy chasing bytes... Derek |