| From: | Aaron Optimizer Digulla |
| Date: | 21 Aug 2000 at 13:19:53 |
| Subject: | Re: AMIOPEN: Amiga python |
Quoting Marc Culler <culler@math.uic.edu>:
> I think that python will make an ideal replacement for ARexx on the
> new Amiga. Python's object-oriented style is a good match for the
> object-based programming on the Amiga. Python allows easy importation
> of modules written in C. Using this facility it is straightforward to
> make virtually any C library accessible from python scripts. Such
> interfaces exist for graphics libraries (OpenGL/Mesa), scientific
> computation packages (LAPACK, FFTPACK), databases (PostgreSQL) and GUI
> toolkits (Tk). I believe that this importation facility can be easily
> adapted to allow easy importation of arebitrary Amiga class tools. I
> also believe that it will not be difficult to write an inter-process
> messaging module for python similar to the one that was added to REXX
> to create ARexx.
I second this :-) No matter if you love Perl, Java or C++; Python has
just a much better learning curve ! And that's the only thing that
counts about a builtin scripting language.
Of course, if Tao fixes the absolute-tool-name bug, we could use
any language which can be compiled into a tool as a scripting language.
Yummy :-)
> I have ported Python 1.6b1 to the new Amiga. I will post the port as
> soon as it passes the python test suite. At this point it fails only
> two tests. One of these failures is caused by a bug in the
> /lib/strftime tool, which I will report in a following message.
> The other failure, which has not been diagnosed yet, occurs in the
> new regular expression module written by Secret Labs AB.
Python doesn't fork() ? Cool...
> Two things were slightly disappointing to me about this port. First,
> my python.00 executable is 551388 bytes, versus 319980 for the
> stripped linux executable. (The linux executable is version 1.5, and
> the Amiga version is 1.6, but I am pretty sure that the VP executable
> will be somewhat larger than the linux native version of the same
> program.) I had hoped that VP code would turn out to be more compact
> than Intel machine language. Second is that the VP version is
> somewhat slower. My Amiga SDK benchmarks at 3360.77 pystones/second,
> while the host linux system benchmarks at 5076.14 pystones/second.
I noticed that, too. It seems that VP heavily depends on the tool
concept when it comes to memory footprints. If you cannot split
up something into several tools, it will need much more RAM. That's
a pity.
Are there plans to compress the tools on the fly ? That
would make creating them slower but with an optimized compressor
(like Juice), you can get compression ratios between 1.5 and 3.
Thus, loading becomes much faster because the CPU is several orders
faster then the HD and it can decompress faster than any HD can
deliver the data.
As for the benchmark: Please compare against Linux 1.6. The new python
has not been optimized as agressively as 1.5, yet. So some part of the
difference could come from this.
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html