I too have a personal view, but I also work for Sun, so I'll try to keep
the two separate. Everything below is personal!
There have been so many interesting projects discussed
on this alias, each with its own unique requirements and challenges, and
yet some commonality too. Indeed factoring out the commonality into an
API that meets many, but not all, needs seems to be a good thing to do.
Some of the comments I've observed are that people have been very
productive with Java3D, that people have been surprised with what they
could do with the API, that some have taken code from one environment
and deployed into another, much more capable one (eg caves), and that
there are additional features/enhancements people would like without
necessarily agreeing on what they are or how they're implemented. This
is healthy.
However some aspects of the discussion concern me. Firstly I think it is
important to make some separation between API and implementation.
Justin's comments about fundamental design flaws in the API may be true,
although the example quoted sounded more like a criticism of the
implementation. If the world is to be blessed with yet another API then
I hope its goals will include cross-platform availability, portability,
and upwards compatibility. That's why when I want to do something
visual, I generally look first of all to a standard Java API.
And then there is the debate about the level at which one should be able
to program. Working very closely at a hardware level is a vicious two-
edged sword. Yes, more performance may be able to be extracted, but the
downside is that the tweaking exercise has to be repeated for each
target hardware platform. I run the risk of drawing criticism, but an
analogy between programming in a high-level language and assembler may
be appropriate.
One of the things I battle with in my own work is performance, and
helping customers with issues such as parallelisation, code
optimization, and avoiding inhibitors to both serial and parallel
performance. There have been tricks advocated publicly about using
pools of preallocated objects, which I suspect are misguided, due to
the way garbage collection is typically implemented. An example is that
it is relatively cheap to collect young objects, and expensive to clean
them up once they've been promoted into an older generation. Having
per-thread allocation pools avoids the synchronisation required to
allocate an object. This shows up when you're running a multithreaded
app on many cpus. For the moment the typical desktop might have one,
maybe two cpus, possibly with hyperthreading. The future is likely to
feature many cores on a single die, with hardware support for many
threads per core. So we need programming models, APIs, designs, and
implementations that exploit hardware support for many threads.
Another issue that I feel is sometimes poorly addressed in the open-
source community, is stability and maintenance of upwards-compatibility.
My own philosophy is of a major.minor.release versioning, where "major"
means incompatible changes (so ship multiple versions of a library),
"minor" is where the API has changed in a compatible way, such as the
addition of new functions, and "release" being an improved
implementation that doesn't change the API at all. Indeed there is
linker support on Linux for versioned APIs, such that a program linked
on newer versions but only uses (requires) should work when run on an
older platform that nevertheless has the minimum requirement. Use of
versioning is not currently widespread. As for adhering to some
semblance of upwards compatibility, that's not been my experience.
If Java3D is made open-source, which many people have asked for and
for all I know may even get, then there are a number of remaining
challenges such as finding a viable way to reach agreement over how to
enhance the API and improve the implementation. I would hope though
that there would be general agreement on some basic philosophies:
maximise the portability and platform availability, resist hardware-
specific tweaks at an application level (push them into the Java3D
implementation such that it can adapt dynamically to the environment
its running in), continue to exploit multiple threads and take
advantage of modern JVM implementation.
Changing the topic completely, is a personal plea about the importance
and value of performance measurement, rather than guesswork about why
things perform the way they do. A moderately recent example is concerns
criticism of javax.vecmath API. To explore this I wrote some experiments
to do many many iterations of Henon maps, with three different
implementation or API styles. The results showed that you could actually
get very good results with each iteration made in a separate call to a
method since the JVM I was using would inline the code. This was infact
faster than a loop with the code placed inline due to what looks to me
like a bug in the instruction scheduling (taking 16 cycles instead of
12). The cost of the style:
<lots of details suppressed but available on request>
Henon3 h = new Henon3();
for (long t = 0; t < T; t++) {
h = h.IterR();
}
I measured to be dominated by the costs of memory activity due to
additional load/stores, not strictly object creation or garbage
collection. Code profiling, and use of hardware performance counters,
can help us focus on where problems really lie.
Richard.
--
============================================================================
,-_|\ Richard Smith - SE Melbourne
/ \ Sun Microsystems Australia Phone : +61 3 9869 6200
[EMAIL PROTECTED] Direct : +61 3 9869 6224
\_,-._/ 476 St Kilda Road Fax : +61 3 9869 6290
v Melbourne Vic 3004 Australia
===========================================================================
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
