On Tue, 2006-11-14 at 21:50 -0500, Gregory Maxwell wrote:
On 11/14/06, Carl Witty cwitty@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=python... 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