Re: Important question to all Euphoria users
Al Getz wrote:
>
> Vincent wrote:
> >
> > 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.
> >
> > <a
> > href="http://www.xbitlabs.com/news/cpu/display/20050505142821.html">http://www.xbitlabs.com/news/cpu/display/20050505142821.html</a>
> > <a
> > href="http://www.xbitlabs.com/news/cpu/display/20050425212220.html">http://www.xbitlabs.com/news/cpu/display/20050425212220.html</a>
> >
> > > 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
>
> Hi Vincent,
>
>
> I've considered re-coding the front end myself to help increase speed
> when parsing, but there's an invisible 'wall' that you hit where no matter
> what you do you dont help the speed much, at least not without going
> to another technology such as C or ASM. I ran into this with my old
> Jpg decoder which was written entirely in Euphoria. There are just so
> many operations required to convert a Jpg to bitmap (and they have to be able
> to operate on the bit level) that Euphoria just isnt fast enough, no
> matter what you do. Maybe a translated program would help?
> This was one of the few times when Euphoria was too slow for the app
> (1 out of 100 programs)
> which makes me think the front end really should be written in C like
> it used to be done.
Hi Al,
I mean to gain another trivial 5-20% increase in parsing speed. This will
probably be very difficult, but I at least, will try my best to get some result.
I plan to release a structure library and minor updates to VEEU
and EVDL before I try though.
Robert has converted more than 10,000 lines of front-end code to Euphoria; there
is no way he will consider going back to a C based front-end, unless some dummy
were to pay him big bucks to do so.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
Regards,
Vincent
|
Not Categorized, Please Help
|
|
