Hi Richard,
I agree with your points on the whole. I think when people were asking Sun to
open-source Java3D they meant literally "make the source freely available" and not
necessarily "open-source the Java3D process". I think on the whole people want to
have the security of having the source freely available so if Sun is not responsive
enough they can make their own patches but on the long run they will rely upon Sun to
drive the actual development.
I actually had a quick question regarding your final point: When does Java
inline function bodies? There has been surprisingly little discussion of this topic
and I
find it of great interest. Very often I find myself reluctant to refactor a large
function into
smaller ones (exclusively on Java) because I was always under the impression
function inlining did not occur.
Thanks,
Gili
On Thu, 21 Aug 2003 19:04:42 +1000, Richard Smith - Systems Engineer - Melbourne
wrote:
>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".
===========================================================================
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".
