Re: Cryptographic Primitives

Andreas Raab writes:
 > J J wrote:
 > >> No. First, Exupery is not a JIT.
 > >
 > > I had been told it was.  In this list actually.
 >
 > Yeah, it's quite confusing actually. I found the statement that
 > "[Exupery is] a "JIT" for Squeak that doesn't compile just in time"
 > which (to me) makes no sense as "JIT" stands for "just in time" so how
 > could a JIT not compile just in time? ;-)

When Exupery is running in a background thread a user shouldn't
notice that it's not a "real" JIT. So calling it a JIT is fair.

It does not stop execution to compile like the VisualWorks VM does.
This means it must fall back to the interpreter if compiled code
doesn't exist. It can't compile "just" in time. It can compile just
afterwards though.


I'll write an up to date overview of what Exupery is, what it plans to
be, and what it does now soon. Either before or just after the next
release.

All that's left to do before releasing is implement the two primitives
#new and #@ then fix some bugs. The two primitives are required for
the largeExplorers benchmark.

Here's the current benchmarks.

  arithmaticLoopBenchmark 1395 compiled   91 ratio: 15.330
  bytecodeBenchmark       2132 compiled  456 ratio:  4.675
  sendBenchmark           1588 compiled  684 ratio:  2.322
  doLoopsBenchmark        1086 compiled  649 ratio:  1.673
  largeExplorers           337 compiled  366 ratio:  0.921
  compilerBenchmark        794 compiled  767 ratio:  1.035
  Cumulative Time         4241 compiled 1389 ratio   3.053

The most interesting benchmarks now are largeExplores (opening a very
large explorer) and compilerBenchmark (compiling a large method into
bytecodes). Both are real uses. Both use a profiler to choose methods
to compile then PIC based type feedback to inline primitives.

largeExplorers needs a faster #@. The interpreter inlines this into a
bytecode while Exupery is currently doing a full message send. Once
it's implemented as a compiled primitive it will then get inlined
automatically.

compilerBenchmark is spending 5% of it's time in compiled code and
support routines. That provides a 3.5% gain. Better profiling may help
by compiling more methods. I haven't looked at the profiler since the
last optimisation.  So would a little tuning, 1% of the time (out of
5% in compiled code) is spent building the new context during a
message send, most of that time could be saved.  It is however
producing a performance gain. Which is enough to make bug fixing the
priority again.

The list of things to do before a 1.0 is here:

 http://minnow.cc.gatech.edu/squeak/5793

Nothing on it is hard or risks destabilising things.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

Hi,

Excuse my inconvenience Bryce, but will be Exupery somedays able to compile
whole VM ?

I see that this is not the main direction of it now, but in near future it
can be huge help at least for SQUEAK NOS and also for Squeak 64 bit VM.
Maybe can be your work reused someway for slang ST to direct machine code
compilation...

What do you think about this idea ?

Thanks

Jan Barger
www.barnet.sk



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Saturday, October 07, 2006 1:26 AM
To: The general-purpose Squeak developers list;
[hidden email]
Subject: Re: Cryptographic Primitives

Andreas Raab writes:
 > J J wrote:
 > >> No. First, Exupery is not a JIT.
 > >
 > > I had been told it was.  In this list actually.
 >
 > Yeah, it's quite confusing actually. I found the statement that
 > "[Exupery is] a "JIT" for Squeak that doesn't compile just in time"
 > which (to me) makes no sense as "JIT" stands for "just in time" so how
 > could a JIT not compile just in time? ;-)

When Exupery is running in a background thread a user shouldn't
notice that it's not a "real" JIT. So calling it a JIT is fair.

It does not stop execution to compile like the VisualWorks VM does.
This means it must fall back to the interpreter if compiled code
doesn't exist. It can't compile "just" in time. It can compile just
afterwards though.


I'll write an up to date overview of what Exupery is, what it plans to
be, and what it does now soon. Either before or just after the next
release.

All that's left to do before releasing is implement the two primitives
#new and #@ then fix some bugs. The two primitives are required for
the largeExplorers benchmark.

Here's the current benchmarks.

  arithmaticLoopBenchmark 1395 compiled   91 ratio: 15.330
  bytecodeBenchmark       2132 compiled  456 ratio:  4.675
  sendBenchmark           1588 compiled  684 ratio:  2.322
  doLoopsBenchmark        1086 compiled  649 ratio:  1.673
  largeExplorers           337 compiled  366 ratio:  0.921
  compilerBenchmark        794 compiled  767 ratio:  1.035
  Cumulative Time         4241 compiled 1389 ratio   3.053

The most interesting benchmarks now are largeExplores (opening a very
large explorer) and compilerBenchmark (compiling a large method into
bytecodes). Both are real uses. Both use a profiler to choose methods
to compile then PIC based type feedback to inline primitives.

largeExplorers needs a faster #@. The interpreter inlines this into a
bytecode while Exupery is currently doing a full message send. Once
it's implemented as a compiled primitive it will then get inlined
automatically.

compilerBenchmark is spending 5% of it's time in compiled code and
support routines. That provides a 3.5% gain. Better profiling may help
by compiling more methods. I haven't looked at the profiler since the
last optimisation.  So would a little tuning, 1% of the time (out of
5% in compiled code) is spent building the new context during a
message send, most of that time could be saved.  It is however
producing a performance gain. Which is enough to make bug fixing the
priority again.

The list of things to do before a 1.0 is here:

 http://minnow.cc.gatech.edu/squeak/5793

Nothing on it is hard or risks destabilising things.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

tim Rowledge writes:
 > Actually I don't think JIT is a sensible description at all; it isn't  
 > accurate and it doesn't really indicate the advantages that Exupery  
 > could have. For example, no extra startup costs, easier extension/
 > maintenance/optimising because it is written in a sensible language,  
 > access to all of the reflexive capabilities of the system, trivial  
 > fallback  if the system is run on an unsupported platform  (it just  
 > doesn't do the compiles and leaves everything to the interpreter),  
 > potential for using a spoon-like inter-image communication system to  
 > allow the compiles to run in a different image/machine, and... well I  
 > could probably go on.

Well, most people only really understand the static compilation model
of C/C++, and the dynamic compilation model of VisualWorks and Java.
They call any form of dynamic compilation a JIT. Many so called JITs
compile in the background. I think IBM's Jalapino does background
thread compilation.

Exupery is in some ways closer to a Lisp compiler written in Lisp than
a Deutsch-Schiffman influenced JIT. So, you could say it's drawing on
a tradition that goes back to at least the '70s.

Help is always appreciated. Exupery is a test heavy project, this
should help people get up to speed. Tests are required for everything.

If anyone would like to help please join the Exupery mailing list
and ask.

  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

There's a list of things to do before 1.0 here:

  http://minnow.cc.gatech.edu/squeak/5793

If you're thinking of writing hundreds of primitives for speed then
helping out with Exupery is probably the best use of your time. If
you're thinking about writing tens of primitives then it's
debatable. If you're only thinking of writing a handful of primitives
the just write the primitive unless working on a compiler is it's own
reward.

Going back to crypto. From what I understand about SSL writing the
streaming cyphers as primitives should make sense for the next few
years. Writing public key primitives would require some serious
profiling first as they're only used once per session. But we all vote
with our time. Just don't get upset if in 5 years time you're
rewriting cyphers into Smalltalk from primitives for speed.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

barger writes:
 > Excuse my inconvenience Bryce, but will be Exupery somedays able to compile
 > whole VM ?

It would be possible. But then you'd end up with a system like CMU
Common Lisp. I'm not sure that would be more portable than our current
system with Slang compiling to C.

 > I see that this is not the main direction of it now, but in near future it
 > can be huge help at least for SQUEAK NOS and also for Squeak 64 bit VM.
 > Maybe can be your work reused someway for slang ST to direct machine code
 > compilation...

I think we've got a 64 bit VM now thank's to Ian and Dan's work. I
haven't yet tried compiling it myself but mean to in the next few
weeks.

 > What do you think about this idea ?

It's interesting, it really depends on your goals. There's nothing
that would stop you doing it.

I'd probably try to write the interpreter in Smalltalk then statically
compile it using Exupery into assembly then run the assembler through
gas. The only reason to use gas is to avoid dealing with linker
formats. For SqueakNOS compiling to machine code should be possible.
But you'd have to rewrite all the C in the interpreter you need into
Slang or preferably Smalltalk.

So, you'd end up with the object memory written in Slang then as much
of the interpreter as possible running as regularly compiled
Smalltalk. There is a bit to think about to lift the interpreter up
to "statically" compiled Smalltalk. But once it's done you should be
able to recompile bits of it live to evolve it without needing to
restart the image.

I'd suggest waiting a bit more before starting to use Exupery for
such a project. If enough people are interested in doing it it could
be done.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

Thanks for the answer, I will wait if Squeak NOS guys will move this or
other way, and i will try to study any Exupery approaches in future.

Jan


_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery