From: "Ian Greenway" <[EMAIL PROTECTED]>
>
> Lars Svoldgaard wrote:
>
> > Amiga is so efficient because it's so slow. There's not a lot of
> > horsepower available, so the programmers have to optimize the software
> > to make it run at an acceptable speed. An amiga just isn't fast enough
> > to run Java at an acceptable pace, plus not many users have the amount
> > of ram required.
>
> I don't quite follow that reasoning. Amiga hardware is slow by today's
> standards, I agree. Amiga software is often optimised to compensate,
> but you cannot compensate for the difference between 500MHz and 50MHz
> by twiddling with the code. The whole architecture of the OS is far
> slicker than many others. And yes, before 100 people point it out,
> some of that it because it doesn't have many of the newer features
> People therefore write programs that do not contain the slowest
> features, or arrange that the majority of usage is channelled through
> the faster systems. Change the algorithm rather than optimise the
> code. As the Amiga falls further behind this becomes more and more
> difficult to achieve, but by no means impossible in relation to a Java
> engine.
The resons the Amiga`s OS is so efficient include:
1. Amiga's messages between tasks send pointers to the memory of the
sending task, rather than a stream of byte values to be copied by the
receiving task into its own memory. This is only possible because
Amiga does not have hardware memory protection (which is in all
other ways a bad thing, for example it makes what would cause the
crashing of one task into the crashing of the whole system).
2. Amiga does not do resource tracking. That is why if you get a GURU
you can't remove the offending task from the system, since the
system doesn't "know" what resources belong to the offending talk.
The above won't do for JAVA, if it it to be used by WWW browsers, for
the following reason. When JAVA runs an applet, it creates for the
applet a thing known as a "sandbox" (based on the notion that a sand
box is a safe place for children to play, where they can't do any
harm). The sandbox contains a block of memory, and access to the
mouse and keyboard as input devices, and the screen and sound system
as output devices. Memory outside the sandbox memory cannot be
read from or written to by the applet. There is also limited access to
the ISP via various internet protocols such as HTTP.
This creates a secure situation, since it is thought to be impossible to
spread viruses through applets run by properly conforming JVMs.
JAVA itself requires resource tracking, so even though the Amiga OS
does not have it, JAVA must. Also, a little thought will also
show that Amiga's inter-task messaging system won't do, because it
doesn't properly forbid access to memory ourside the sandbox.
By the time code is written to do these things, it all starts getting bogged
down.
JAVA is now extended by a system of allowing access to files via a
system of certificates, whereby the computer running the JVM can
store up certificates, and can check (somehow I don't know the details)
that the HTML page is really owned by the trusted owner who holds
the certificate. V is not very good at running a similar system for
JavaScript.
I believe I will be able, given enough time, (and that's a big if) to write
a
CSS2 system for the Amiga that is fast and compact. It seems to me that
to do so, the CSS2 and HTML must be integrated into one thing, rather
than having CSS2 as a plug-in to an HTML viewer. Then, HTTP,
SHTTP, MIME types, &c interfaces would be plug-ins to them. It's all
very messy since all of the standards keep evolving all the time.
But I don't have the skill to write a JAVA implementation. That would
indeed be ambitious. It is not writing that JVM that is the problem - I
could
*maybe* do that, and in some limited sense it has been done for the Amiga
already.You would need specialist knowledge of many different areas of
expertise.
The problem really is the standard set of methods, &c that have to be
provided, it would be like writing the Amiga OS all over using JVM
"Machine code" instead of 68000 assembly language. Let's just say it could
not be completed on a rainy afternoon.
> Most people want Java because of the internet sites that use it.
> Features (many would say pointless) to enhance the look and feel of
> the site. Buttons, menus, tickertape strips... How much processing
> power do you think this takes? A JVM is effectively a special kind of
> emulator. Much of the slowdown is related to the arbitrary IO system
> it implements to allow it to display in windows, browsers, etc.
The above are a stupid abuse of JAVA - things such as this should be
done by JavaScript.
> David Gerber has written us a shockwave system, which does require a
> lot of continuous heavy processing. I recall him pointing out that
> there is a significant speed loss due to the way it interfaces with
> the browser. But it does work and it does run on a 68K Amiga. I can
> quite well imagine similar naysaying occuring before he created that.
> A Java applet which only occasionally renders a menu or button will be
> far less obviously slow, and also less critical in it's speed anyway.
David Gerber is a dead-set legend for doing this. Shockwave is a much
better way of doing many things than JAVA. Your point here is correct.
> But I digress. My point is to say that just because even on PC's
> JVM's are regarded as a bit too slow to be useful, this does not
> instantly mean it is impossible to make a useable Amiga version. If
> optimisations such as you describe and which exist between the
> effective performance of, say, V versus Netscape, can be transferred
> to a suitable JVM then things will run along nicely. If you want to
> use it for less frivolous tasks than internet prettiness, then yes, I
> agree the speed is unlikely to be adequate. The majority of people
> jumping around wanting it, though, are simply wanting their favourite
> websites to work properly.
The best way to make a JVM fast would be to make a hardware plug-in
so you could have a "JAM" (Java Actual Machine). A JAM run by an
Amiga would be faster than a JVM run by a PC.
>Then there's the situation of actually writing an interpreter, but
>that's another story alltogether...
No it's not the interpreter it's all the routines (methods of whatever) that
is
the problem. The window's routines have been written as elegantly as
possible, and they take up millions of lines of intricate and hard to debug
source code.
> And there you do indeed put your finger on the sore. It may well be
> possible to write one, but who is going to do so? IIRC there is a JVM
> available for Amiga, a direct port of some open source code or
> something similar. What it doesn't yet provide, of course, is the
> browser interface. Maybe some genius will create one, maybe someone
> else will code a new system from scratch. I must concede though, that
> I can't see it happening in a sensible timescale. :(
It could not be done except for a group of especially capable profesional
programmers spending a couple of years full time, in my opinion :((
_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
