[Ns-developers] icc and "patched" waf
gjcarneiro at gmail.com
Thu Jan 22 09:42:47 PST 2009
2009/1/22 Timo Bingmann <timo.bingmann at student.kit.edu>
> On Thursday 22 January 2009 14:03:36 Mathieu Lacage wrote:
> > hi timo,
> > I won't comment on the waf problems but, if you are trying to get the
> > most out of ns-3, the biggest impact you can have on the performance is
> > to build a static binary: if you build all of the ns-3 object files
> > without the -fPIC option and link them all in your script, you will get
> > a fairly big boost in speed: when I did this by hand on a couple of
> > examples, I got up to 40% runtime improvements. If you want to know how
> > I did this, I just ran ./waf -v > output and then, wrote a couple of sed
> > scripts to modify the output and feed this to a shell script.
You know it shouldn't be too hard for me to add a configuration switch to
ns-3 to compile everything statically. Do you think this would be useful
feature to have in ns-3?
Although I must say I have serious reservations about your 40% speedup. It
must be a very constrained scenario to reach that level of slowdown. Or
else we have to revisit this whole idea of building NS-3 as a shared library
> > Ideally, there would be a way to get non-dynamic libraries from our waf
> > scripts but, I did not want to bother gustavo with this too much and I
> > was not motivated enough to try to do it myself.
> > I hope this helps,
> > Mathieu
> Okay thanks for the hint, I'll try that out. I'm not into the speed testing
> phase yet. It was just some "let's try this out" morning-wake-up-coding.
> Some initial profiling also showed that most time was spend in the cairo
> int128 library for time calculations.
Heh, that is surely very scenario dependent. About year ago, when I was
doing OLSR simulations with hundreds of nodes, the routing table computation
plus MPR compupation, inside OLSR agent, took over 75% of time. Nowadays,
most simulations using WifiNetDevice will show that WifiPhy to take a lot of
time as well. I have not encountered performance problems in Time in a
while. Maybe int128 is a bottleneck due to specifics of your hardware? I
usually run on 64 bit systems, but I bet 32 bit systems are slower to run
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers