Indeed, the freedom in variable typing is a true luxury -- I must confess
that I prefer writing lingo over C, but I find the slowness of lingo a bit
extreme though.
I ported the fractal thingie over to c++ using mfc and mfc's SetPixel.
I even made it a bit more interesting by using 32 bit colors.
Now it really gets fun --
On my crummy old P266 it gave me these results:
-lingo: +-20 minutes
-C++: 3 to 4 seconds
Thats like 400 times faster.
Hopefully MM is planning to implement,like Brennan suggested, a "compiled
script" cast member, or something similar, for director 9 - I'm convinced
that being able to selectively compile objects would yield great results
without sacrificing the development speed that we are all so found of,
escpecially with the 3d and imaging features that are now present in
director. Since all imaging is quite a bit of a number-crunch, I'ts pretty
useless if it can't be done to a certain degree of speed.
I'm not a director veteran in any way, I only started using director in the
last month of the D7 lifespan - and it was kinda forced upon me through
circumstances - but I must say I really enjoy using it, and the director
community has proven to be (to me anyway) one that isn't retaining of
sharing knowledge, and helping other developers - where those could
sometimes get into serious trouble with projects that carry problems that
seem impossible to solve at that specific moment.
I hope director still has a long life ahead, even with the drawbacks - and
then again - every development tool has it's own set of them.
And assembler sucks !!! ;)
Chris.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Brennan Young
Sent: Thursday, July 05, 2001 11:21 PM
To: [EMAIL PROTECTED]
Subject: RE: <lingo-l> a faster way to draw than using setpixel ??
Kerry Thompson <[EMAIL PROTECTED]> wrote
> I don't understand why this isn't at the top of Macromedia's list of
> upgrades--there is no other single thing they could do to increase
> performance more, at least for Lingo-heavy apps.
>
> At the beginning of a project, the Powers That Be make a decision--do we
> need performance, or quick development time. If performance is the sine
qua
> non, they use C++. If they can put up with slower performance, they use
> Director.
>
> A Lingo compiler would put Director in the same class with C++ as far as
> performance, without sacrificing development time.
I can follow you on this, but I would hate to see the loss of the runtime
interpreter and (especially) the ability to evaluate strings. I don't use
'do' very often, but I use value() in almost every project. One of the
biggest problems implementing what you suggest is that Lingo is loosely
typed, whereas compiled languages are necessarily more tight about what
datatypes you use, which slows development down. Most compiled languages
require you to explicitly state the type when creating variables. (C even
requires you to do it twice. Zzzz).
How many Lingo programmers use the same variable to hold strings one minute,
integers the next, members the next? I don't believe that would be possible
with a compiled version. It's a genuine convenience to be able to switch
types like that, or for handlers to receieve parameters of different types.
The compilation cycle itself puts a few seconds between finishing editing
your code and seeing a result. One thing I love about Director is that,
barring syntax errors which prevent 'compilation' to bytecode, the 'play'
button is always ready to go, not to mention the freedom you get when
debugging.
What might be more useful would be an equivalent of the old 'CompileIt'
application that used to be available for Hypercard. You'd take a hypertalk
script - a function, say, run it through 'CompileIt' and get an XFCN out the
other end. (Something like an Xtra). The performance of these compiled
modules, while slower than something made carefully in C or (ha) assembler,
was far better than hypertalk alone, and of course, you had to be quite
strict about your types, but it was a good middle way.
The mandelbrot example is a typical situation where you would never find a
commercial Xtra to do that one job, but is just too slow to run in Lingo.
Rather than compiling *all* the Lingo in a project, it would be more useful
to isolate some hotspots (such as the number-crunching repeat loops),
convert them to strictly typed functions, and then compile them. It often
turns out that the hotspots tend to be those parts of a program which are
best suited to compilation. None of the datatypes in the mandelbrot example
are changing. There's no runtime evaluation of strings. It really ought to
be native compiled binaries.
It can be interesting to look at the way this issue has been treated in LISP
implementations. LISP, like Lingo, runs in an interpreter, is loosely typed,
and has a reputation for being slow. LISP is usually 'written in itself',
with only the lowest level routines constructed in assembler. Eventually,
someone realised that some of the essential functions made in LISP could be
compiled to native machine code. Now, any decent LISP implementation also
features a compiler, and the core routines are all compiled. (I believe the
compiler also caches the source of each compiled function, so you can always
go back and edit it). Once you've compiled a function, you can't, for
example, pass it by value, and all the types are 'set in stone', but it
retains the advantages of rapid development, with the option of high
performance where it's needed.
Example: Have a look at the platform game 'Abuse'. It's a LISP program, and
if you're smart, you can even get at the source code of the higher level
routines. All the pixel blitting and collision detection stuff is compiled
to binary, and it's certainly fast enough, but stuff like configuration of
the levels, and AI remains interpreted, because it makes good sense for them
to be so.
I'm convinced this is the way forward for Director.
--
_____________
Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
