Performance question

Mar 21 04:22 UTC 2007

Presuming identical hardware and a platform-independent language (that
is sadly not explicitly parallelizable without modification to the
interpreter itself), does anyone know how performance stacks up for
running a batch job on Linux vs OBSD vs FBSD vs Solaris 10 vs Cygwin?
Specifically, I will be running iterations of large, nasty
network-simulations using ns2, which uses a derivative of Object-TCL to
describe the network (and which does not provide a facility to
parallelize the task), and have a machine that should be sufficiently
butch to handle the load. I intend to create the simulation and leave it
crunching over-night, but does anyone know how performance changes as a
function of the number of nodes and rate of traffic generated? Are the
constraining factors for these simulations something that can be
compensated for by choosing an optimal operating environment? I've run
much smaller, simpler simulations on a time-sharing Solaris server
(E3500) and on my laptop (AMD semperon, Cygwin under WP-Pro), and even
with the more performant machine on which to run the simulation
(mirrored 10kRPM U320 drives, dual core AMD processor, 4 GBytes RAM), I
am not optimistic about the speed of running the simulation, and being
able to iteratively tweak large simulations (probably around 1M nodes,
many linked to more than one other node) in any sane amount of time. If
the simulator were parallelizable, I would rent time on a cluster (or,
rather, try and barter to get someone to rent time on my behalf if the
price were out of my range). 

Thanks and sorry for the rambling question

response 2 of 5:

Mar 21 17:54 UTC 2007

I realize I had a badly formulated and incomplete question. Part of the
problem is that I do not know what the chokepoints are for this
software, and searching via Google and a couple of other resources show
lots of information about using ns2 to find chokepoints in networks, but
those overwhelm the results, keeping anything with information about
chokepoints in the simulation software from showing up. From what I know
about the underlying system, there will be a large amount of disk
access, though it will all be to a pair of files, so I presume on a
fresh install of the OS, these files should be fairly contiguous, taking
out the overhead from seeking. Additionally, there will be a lot of
treads spawned for creating the topology, with the actual running of the
simulation being run in-order. I know memory consumption will also be
huge (my understanding is that it keeps the entire topology in memory,
along with a route-map for each node that performs packet switching
duties, at the very least in the beginning). In short, I guess this will
be slow in every way except for use of the network (since the simulation
runs entirely on one machine). 

Thanks for forcing me to think about the question in a more sane way. 

response 4 of 5:

Mar 22 09:18 UTC 2007

Sounds like memory will be huge.  Did I gather correctly that there will
be a thread for each node?  If things haven't changed since I last knew
the Sun should be way faster at the context switches involved in all
those threads.  I'd look at the real clock time for context switches for
each of your candidate systems both normal loading and in the
pathological case where number of contexts greatly exceeds the number of
hardware context frames.

I'd also be interrested in the amount of work done on any one thread
before switching to another WRT memory locality and cache hit rates. 
Specifics of the cache hardware and cache clearing on context switches
may play a big part.

There's a good chance that hardware will play as much role as OS.