>>> [EMAIL PROTECTED] 02/27/02 06:51PM >>>
> I dont think the Nt box did spread the load well; 58% per cpu is a
> balanced 116% of one part...I bet if you looked at the kmode portion of
> the load (show kernel times in taskman), that 16% would be file IO, not
> java.
Perhaps - but I'm still puzzled as to why both Sun boxes ran slower than our baseline
WinNT4 workstation - they had more physical RAM (1 GB and 2GB versus 512 MB), and a
450 MHz UltraSPARC should be faster in general than a 750 MHz Pentium III.
> By default ant single threads, javac is also single threaded. nobody has
> added any explicit support for synchronization in their tasks so going MP
> would be dangerous.
Which brings us to our next topic. The ant scripts we use are roughly based on the
antgump proposal; a master build scripts creates a java process that runs the ant
buildfile for each project. This java process is forked, so I'm guessing it would be
safe to run these builds in parallel. Two pitfalls:
Problem #1: Projects are dependent upon each other; building two projects in parallel
with one referring to the other in it's classpath would be bad.
Solution #1: We can set up a lib directory ${lib.dir} that contains the JARs produced
in the previous build, and put these in the classpath for the current build, thus
solving most project dependency problems.
Problem #2: Our various java process (theoretically running in parallel) won't be
writing to the exact same destination directory (because of packaging differences),
but they will all have the same destdir for their respective <javac> tasks (ie,
${classes.dir}). My understanding is that Ant automatically adds this directory to
the classpath. Would this directory be added before, or after any explicitly added
paths? If project dependencies were solved by using files from ${classes.dir} instead
of the stable JARs in ${lib.dir}, then we could run into problems.
Kyle
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
