VM fast enough?

[Luca Pisati]

Gilbert Baumann wrote:
> 
> Rainer Joswig <joswig@lavielle.com> writes:
> >
> > Would you think a VM would be fast enough?
> > Not for writing small gimmick applets, but for running
> > publishing systems, 3d renderers, doing sound synthesis,
> > CAD applications, multimedia environments, ...?
> Tough question.

For sure Lisp is probably not fast enough for 3D renderers.
Even if Nichimen's N-World 2D/3D animation software is
almost completely in Cl/CLOS, the renderer is in C++

Forget about emulating it, right now we pray for
faster hardware rendering ...

> > Those are all Lisp applications of today.
> Don't know, haven't seen Lisp in real life usage :-(

:)

> > Would it be fast? I mean fast enough? Or even really
> > fast? Without building a chip (-> SUN).
> > How to incorporate MPEG playback, QuickTime, PostScript
> > engine, JPEG de/compression, GZIP, TCP/IP, ...?
> 
> I think, stuff like MPEG playback, JPEG de/compression, GZIP would
> really suffer from an VM implementation. It is allready hard enaugh to
> write suitable fast Lisp code for decoding .png files using ACL and
> lots of declarations; This involves rfc1951 decompression, applying
> filters to the rows of image data and finally dither the image if
> necassary. But these are not things, I want to do all the day.

Even if I do not see the opportunity of writing a 3D renderer in Lisp
(since I still do not see any advantage in using Lisp), I must say
that we threw away a lot of C code we used in our previous versions
of our software simply because Lisp compiled code can be as fast as
C compiled code ...  Declarations are a problem, unless you do
encapsulate them in some form of specialized language (as we do).

What is actually really hurting us, is that type-propagation
information in the compiler is not first on the list of Lisp vendors.

> The VM idea is neat anyway. But the longer I think about it, the more
> difficult appears it to me to offer decent performance on the tasks
> mentioned above.
> 
> > Are there any VM implementations for Java that one
> > would consider fast? JIT compilation?
> 
> Why looking at Java? Want does the Java camp offer besides lots of
> hype and ugly syntax?
> 
> > - What should the Lisp OS do?
> Less paging, less crashing :-)

Less paging, I agree ! Less crashing .... I never experienced
them many (at least on Symbolics).

> > - What would be typical
> >   applications (a listener is barely enough)?
> 
> I think this question is somewhat bogus. By saying X is typical and Y
> is not, we would stamp Lisp as a special purpose language. Which
> applications will exist on the Lisp OS, will depend on the developers
> involved.
> 
> But I think Lisp could be strong on CAD. Take electronic CAD
> (Schematic + Autorouter), [a field I have some insight] there is a
> great demand for a solution. Most applications are of bad quality and
> what is more important: Interfaceing between the individual
> applications needs in-house implemented conversation tools. There are
> somewhat standard data formats, but there are screwed up most of the
> time. A one-address space Lisp OS would surly help here a lot. I have
> done much glueing work in this particular field. Also all applications
> have thier very own broken extension language. This could be a strong
> point for the Lisp OS -- all applications would be easily extentable
> or fixable by hooking in new code into the menus and by using the
> advice feature. [When the source is not available.]

I'm sorry, but advice is a paleolithic tool when you have CLOS
and MOP available.  Our user interface (CLOS/MOP) is so dynamic
that sometimes we find a menu that we never saw before :)

> > - Where to start?
> 
> We have CL-HTTP and I have my Lisp implemented web browser (80%
> finished, I'll make it available it as soon as I approach 90%). This
> could be starting point. Target the Web! Explain to the people why
> running CL-HTTP on Lisp OS is better than using a unix solution. It
> will, I know. Offer the people more powerful tools to design their
> pages. Why did I hit so many dead links on my todays web journey? --
> inferior tools.
> 
> > - What are the target platforms?
> 
> I think this depends on the platforms available to Lisp OS developers;
> but we should start on the Intel PC platform, because:
> 
> o They cost nearly nothing. You could get some i486 really cheap or
>   have one shut down, because Win95 is too slow on it. So you could
>   afford to have an Intel PC dedicated for the Lisp OS.
> 
> o Other platforms are just not affordable for students like me. Nearly
>   every student I know has a PC running under Linux. Since virtually
>   every machine at Uni is running unix, we enjoy having a unix at home
>   also.
> 
> The situation may be different in the academic environment.
> 
> Since running the Lisp OS forbids running another OS concurrently the
> platform does not really matter as long as it is cheap enaugh. The
> Lisp OS must only be good at TCP/IP communication.
> 
> > - What are the target users
> >   (there are not that much Lisp hackers nowadays)?
> 
> What was the original target of early Linux? It were hackers and as
> Linux got stable, people which got tired of Windows. I love Lisp. I
> love to try out new ideas, so Lisp is the right tool for me. And: The
> longer I browse thru' the old Symbolics manuals, the more I begin to
> hate unix and its primitive programming language C.
> 
> I think there are enaugh niches, where a dedicated machine running
> Lisp OS, could exist. In the academic environment may be enaugh
> projects, which would consider using the Lisp OS. And Lisp need'nt be
> the only language supported, there are enaugh people tired of C.
> 
> > Sorry for all those questions.
> 
> Thank you for all those questions -- They helped me to get my ideas
> about the Lisp OS a bit organized.
> 
> Gilbert.
> [Ebenfalls ein Hanseat]

--
Luca Pisati		       Voice:	 (310) 577-0518
Nichimen Graphics	       Fax:	 (310) 577-0577
12555 W. Jefferson #285        EMail:    pisati@nichimen.com
Los Angeles, CA 90066          Web:      http://www.nichimen.com