Re: Important question to all Euphoria users
Robert Craig wrote:
>
> Vincent wrote:
> > What happens to Euphoria's performance status, if we cannot participate in
> > the
> > concurrency revolution?
> >
> > New Found Glory's "All Down Hill From Here" keeps playing in my mind.
> >
> > <a
> > href="http://www.gotw.ca/publications/concurrency-ddj.htm">http://www.gotw.ca/publications/concurrency-ddj.htm</a>
>
> Thanks for the reference.
>
> As the author states:
> "A few rare classes of applications are naturally parallelizable,
> but most aren’t"
>
> 1. It is already possible, today, to take advantage of
> multiple threads (cores) in Euphoria. See the user contribution
> of Daniel Kluss that lets a Windows API call run as
> a separate thread.
It allows us to work with blocking I/O calls by changing them to
non-blocking for Windows (only). But I dont think it allows for
concurrent programming with multiple threads all executing
simultaneously, each running on a seperate core. Currently,
Linux and FreeBSD users cannot benefit much from this library.
> 2. Once we have the multitasking language design in place,
> we could extend it (someday) to allow for tasks that run
> on a separate core in a separate thread. You'd have to be
> careful about race conditions, locks etc.
Yes you mentioned that part of work will be done (multiple calling
stacks, data structures, some locking) when you finish implementing cooperative
tasking, that could help make thread-safety easier to implement. When you say
"someday", will that even be in our life time?
Intel and AMD are already planning quad-core processors by 2007. This
is when the need really starts kicking. Dual-core chips work well in
using one core for handling background processes, while the other for
handling the active program. With tri-cores and beyond, a great deal
of speed lies within concurrency. Currently, Euphoria only utilizes
one core, thus we will only benefit from increased L1 & L2 cache sizes
in these new CPUs. If you think that this problem can be ignored, you
have terribly mistaken.
http://www.xbitlabs.com/news/cpu/display/20050505142821.html
http://www.xbitlabs.com/news/cpu/display/20050425212220.html
> 3. Euphoria could automatically parallelize sequence operations,
> e.g. addition of two 1000-element sequences could be done by
> two cores (threads) that handle 500 elements each.
> (assuming that the overhead is not too high). Word-at-a-time
> languages (C, C++, etc.) can't do this.
Interesting... I'd like to see this in action.
> 4. Judging by your public and private messages, you are
> something of a "performance nut". Why is this? Can
> you name a Euphoria program that runs too slow on
> your 3GHz (or whatever) current machine? Then we can
> think about why it's too slow, and what might be done
> about it.
When Euphoria's loading time appears to slow down 15 to 20 times in
only one release, then hear the following release is expected to have
an *additional* performance penalty of 10 to 20+ percent on recursive
calls with interpreted single task applications, it worries me! Speed
is a very important to me, that is why I'm using Euphoria; simplicity
is too, that is why I'm not using C or ASM, though the thought has
crossed my mind several times.
On a 3 GHz system, you can expect almost any programming language to
appear to run fast, heck, even Liberty BASIC runs well on my 2.6 GHz P4 box! But
on a 450 MHz P2 box, it run like pure garbage. I look at bench marks, loading
time, etc. to determind what is fast and not. When you degrade Euphoria's speed,
it takes away that important performance aspect (even if it's mostly just loading
speed). Both this and simplicity are
key factors in determinding Euphoria's overall value as a language.
Euphoria is suppost to run on a 386 system, but it seems now we will
suffer greatly with poor loading speed on anything less than a 1 GHz Pentium III
or equivalent and plenty of RAM.
So how about them optimizations in the backend and translator for the
next release? 
. I'll see if I can squeeze a tiny bit more speed out
of the parser and scanner.
Anyone here can help making optimizations to the front-end, then maybe
we can figure out how fit them all into the official front-end that
links with the C one.
Regards,
Vincent
|
Not Categorized, Please Help
|
|
