Hi Dave,
I think you're making this more complicated then I intended my
comments to be... What I'm saying is that it is possible for Jess
statements to be internally translated to Java bytecodes, which then
become part of the Java application. They are then subject to
compilation by the JIT, just like the rest of Jess. I think you've
envisioning some kind of bytecode interpreter written in Java -- I was
proposing no such thing. That's the beauty of Java's dynamic nature -
it's easy for an application to self-modify in a safe, orderly, and
sensible way.
Another option, of course, is a precompilation step. Jess could have
its normal interactive mode, but then could also take the same scripts
and do some extra, but computationally intensive, translations to
executable Java .classes when you're ready for deployment. You could
then run these custom-built classes instead of sourcing a script.
I think [EMAIL PROTECTED] wrote:
> Hello-
>
> On Mon, 10 Jul 2000, friedman_hill ernest j wrote:
>
> >
> > Note that compilation of Java code is one option, but building strings
> > of bytecode from some internal representation is another, and this
> > latter is something I want to experiment with. Also look at the
> > jess.Accelerator interface and how it is used: I've got an
> > implementation (never released) which can speed up wordgame and zebra,
> > both math-intensive problems, by about a factor of two by turning all
> > the nested LISP math into Java code.
>
> The Accelerator and Test interfaces are geared toward optimizing LHS
> evaluation in the Rete network. I suppose I'm more concerned about RHS
> performance, and the ease of developing fast procedural exoskeletons upon
> rulebases.
>
> For example, writing a few loops iterating over multislots and performing
> other list manipulations can really bog things down when written in Jess.
> While a byte compiler could improve things dramatically, I would think the
> best performance enhancements would come from creating compiled static
> methods for long-lived deffunctions and lisp blocks on the RHS.
>
> Userfunctions are an adequate solution in the meantime, but I think there
> is plenty of room for improvement, especially in terms of ease of
> development. I would much enjoy writing everything as Jess scripts. It
> should also be noted that HotSpot and JITs will not be able to optimize a
> byte compiler nearly as well as the individual code blocks when separately
> compiled. This was my primary point against adding a byte compiler, since
> Java is already byte compiled!
>
> Perhaps once a byte compiler is written it will be a natural step to
> include HotSpot-like features within Jess? I'm intrigued by the notion of
> using one Rete engine to tweak how another is performing. With
> multiprocessing becoming more available, Rete has quite some potential
> ahead of it! Okay, I'm starting to daydream . . . .
>
> -Dave Barnett
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
