On 2012-01-21 07:38, Dima Pasechnik wrote:
> perhaps it's also important to see how fast 'sage -b' goes after a large
> change. Currently it seems that as it runs scons, and not make, scons
> only uses one processor. (scons has a -j switch, but is does not seem to
> be used).
It uses scons for buil
On Jan 20, 2012 10:38 PM, "Dima Pasechnik" wrote:
>
> perhaps it's also important to see how fast 'sage -b' goes after a large
change. Currently it seems that as it runs scons, and not make, scons only
uses one processor. (scons has a -j switch, but is does not seem to be
used).
> It would be grea
perhaps it's also important to see how fast 'sage -b' goes after a large
change. Currently it seems that as it runs scons, and not make, scons only
uses one processor. (scons has a -j switch, but is does not seem to be
used).
It would be great to be able to do something like 'sage -b -j64', no?
On 2012-01-21 00:00, RegB wrote:
> Do you have a (good) idea of where diminishing returns cuts in ?
> I imagine the number of cores (threads) doesn't help much above a
> fairly small number due to sequential dependencies ?
I'm pretty sure I hit the diminishing returns already. ATLAS and R
(both in
Do you have a (good) idea of where diminishing returns cuts in ?
I imagine the number of cores (threads) doesn't help much above a
fairly small number due to sequential dependencies ?
More memory is always "nice to have" but does it really help HERE ?
Did you set the atlas_architecture environment
On 1/20/12 7:25 AM, Jeroen Demeyer wrote:
Some observations from building sage-4.8 on a very fast system (32
cores, 512G RAM) using "make -j64 -l32".
First of all, apply the patch from #12329 to prune many unneeded
dependencies of the Sage library (needs_review by the way...):
Total time for "m
