On Tue, 2006-11-14 at 21:50 -0500, Gregory Maxwell wrote:
On 11/14/06, Carl Witty <cwitty(a)newtonlabs.com>
wrote:>
"... we can provide (audited) java classes
for anything performance
critical..."
Really? Including fluid dynamics simulators, rigid-body kinematics with
collision detection, Game of Life simulators, and chess-playing
programs? These are just a few possibilities for (the
performance-critical part of) educational applets that I came up with
off the top of my head; I'm sure there are many more.
Um. I promise that Game of Life will not be a problem. I've coded a
game of life simulation in freeking qbasic on a 286 which was faster
than the screen refresh rate.
Using what size grid? Would it have been that fast on Paul Rendell's
Game of Life Turing Machine (1714 x 1647 cells)? What if you want to
run much faster than the screen refresh rate ("what will this pattern
look like after a million generations")?
Fluid dynamics, rigid-body kinematics, and chess...
I'm not sure if
you are more confused by how slow 'not performance critical' is or if
you have totally unrealistic expectations about what is needed to
educate people. People not only learned but conducted serious science
with software in these fields on the computers of a decade ago, even
with interpreted languages far slower than what we'd use today... I
wouldn't expect a modern interpreted language to be any slower...
I contend that the performance requirements for serious science are far
less than the performance requirements for an educational applet. A
scientist will be willing to spend a lot of time carefully designing
small experiments that will test a hypothesis, and then spend a week
running the experiment; if an applet takes more than a minute to set up
an experiment and get results, you'll lose a lot of viewers (a couple of
seconds is a much more desirable time).
I guess partly it depends on the goals for these applets. Do we want to
reach only people who are "captive" (studying this material for a
course, or intensely curious about the material) or do we also want to
try to "grab" people who are only mildly curious?
Perhaps my particular examples were poorly chosen, but I'm having a hard
time believing that there are no examples where a
more-than-an-order-of-magnitude improvement in speed would make a
significant difference in the educational impact of an applet.
When I played with jython before it was about half the
speed of
cpython (without psyco) on the same code, with a simmlar difference
compared to raw java.
I'm having a hard time parsing your sentence, but I think you're saying
that cpython is about as fast as raw Java? That's going to depend
heavily on your workload. I realize it's a bad idea to draw conclusions
from a small set of flawed benchmarks, but I'm going to try anyway
(attempting to be conservative). Looking at
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=pytho…
indicates to me that Python is comparable in speed with Java when most of the time is
spent doing things that Python has C libraries for (regular expression matching, hash
tables, arbitrary precision arithmetic), but that Python is much slower than Java (more
than an order of magnitude) at doing things like fluid dynamics, where the inner loop has
a lot of floating-point math and is not sped up by libraries.
Moreover, I hope you realize that the limiting factor
for any of this
will be authoring the code. If a poor security model or editing model
keeps us from tapping into the public at large we will not do well.
Definitely true!
The JVM-based
interpreter may still be the right thing to do, but people
need to be aware that there are whole realms of creative educational
possibilities that are far less feasible with that approach.
I don't understand your argument.
Java classes + an available interpreter can not be slower than java
classes alone.
If you require that Java code be heavily audited, and that interpreted
code only needs to be lightly audited, and if your supply of people
willing and capable of doing heavy auditing is limited, then you'll end
up with slower code than if you allow lightly audited Java code.
How does a
Java applet go about asking for more privileges? Is that
something we can easily audit to avoid (for instance, by checking .class
files to make sure they only use standard Java classes and methods that
are in a whitelist, not to include reflection)?
It's not easy to audit if we're working with bytecode, ... if we're
working with sourcecode thats another matter.
In the specific case of auditing that only classes and methods from a
whitelist are used, I still think that the easiest method is to write an
automated tool that examines the .class file. Other kinds of auditing,
of course, are totally infeasible on the bytecode, and require source
code.
If the
embedded-in-JVM interpreters let you interact with Java, then you
will probably be able to write scripts that ask for more privileges; and
that can't be fixed by outlawing reflection, since the interpreter has
to use reflection. For this reason, compiled Java may actually be
easier to secure than an interpreter.
You control what methods they can access by what you choose to expose,
and you don't like the interpreter otherwise much with the VM. This
is why jython is currently a non-starter (and in general, python has
been difficult to lock down).
I would think that most JVM-based interpreters would use reflection to
allow access to arbitrary Java classes and methods; this would normally
be considered an advantage, and would be a big selling point ("allows
seamless integration with Java!") for the interpreter.
Can we write
our own security manager, ensure that all calls to
uploaded .class files are "wrapped" by our security manager, and
implement our own restrictive security policy that way?
You have to have signed code to hook in as a security manager.. but
lets assume we could:
This would do nothing to stop mistery meat code from displaying
penises every second tuesday. The only way to handle that is to keep
size down, readability up, and always work with source.
True. But that has nothing to do with whether we allow raw Java or
whether we require some sort of interpreter.
In any case, it's pointless to debate what loft
applications we'd
exclude with a particular implementation when none of these pieces of
software currently exist.
As long as we're not setting policies now that will be difficult to
change later...
Carl Witty