1. Important question to all Euphoria users
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.
http://www.gotw.ca/publications/concurrency-ddj.htm
Regards,
Vincent
2. Re: Important question to all Euphoria users
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>
>
>
> Regards,
> Vincent
Hi there Vincent,
Very interesting article there. I didnt agree with everything, esp
that one point about having a second CPU core just to run adware..
i think if that was the case then something else is wrong or missing
on that system, but anyway, i found one point to be especially perfectly
exactly totally true:
QUOTE FROM ARTICLE (about oop):
OOP’s strengths in abstraction and dependency management made it a
necessity for achieving large-scale software development that is
economical, reliable, and repeatable.
END QUOTE FROM ARTICLE.
I'm pretty sure i'll quote that in my WinClass library documentation
too.
As to what/how/where/why Euphoria might support that in the future...
im sure if the need rises Rob will consider adding something to manage
separate cores, as he did with multitasking recently when a number of
people suddenly became interested.
Maybe he'd be nice enough to reply to this thread to shed some light
on this subject...
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
3. Re: Important question to all Euphoria users
Al Getz 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>
> >
> >
> > Regards,
> > Vincent
>
> Hi there Vincent,
>
> Very interesting article there. I didnt agree with everything, esp
> that one point about having a second CPU core just to run adware..
> i think if that was the case then something else is wrong or missing
> on that system, but anyway, i found one point to be especially perfectly
> exactly totally true:
Neither did I... but its the big picture that matters.
> QUOTE FROM ARTICLE (about oop):
> OOP’s strengths in abstraction and dependency management made it a
> necessity for achieving large-scale software development that is
> economical, reliable, and repeatable.
> END QUOTE FROM ARTICLE.
>
> I'm pretty sure i'll quote that in my WinClass library documentation
> too.
In my opinion, Euphoria is just to simple and flexible with sequences to ever
need the confusion of object oriented concepts. Of course we have some great OOP
libaries for those who want to do OOP in Euphoria.
> As to what/how/where/why Euphoria might support that in the future...
> im sure if the need rises Rob will consider adding something to manage
> separate cores, as he did with multitasking recently when a number of
> people suddenly became interested.
> Maybe he'd be nice enough to reply to this thread to shed some light
> on this subject...
That is the problem... cooperative tasking is not going to help with this
situation. The only way we effectively utilize multi-core processors, is by
developing multi-threaded software. The only way we can do that is if
thread-safety was implemented.
This is where Rob's point comes in. Programming with multiple threads is quite
challenging worrying about when to set up mutex locks, race conditions, etc. It's
also a problem implementing implementing thread-safety in the first place. But if
want to keep Euphoria beating, this surely must be addressed. Rob is implementing
cooperative tasking; but is that a waste of time? A layer of abstraction could be
developed to ease the programmer from the challenges of thread programming.
Figure a CPU had 20 cores... Euphoria would only be able to utilize 1 of them
per execution. That is 1/20 of the CPU's throughput, thus a much greater amount
of effiecency and performance is possible using multiple threads.
It would be nice to see what Rob thinks about this.
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
Regards,
Vincent
4. Re: Important question to all Euphoria users
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Nov 14, 2005
-
Last edited Nov 15, 2005
Vincent wrote:
>
> Al Getz wrote:
> >
> > As to what/how/where/why Euphoria might support that in the future...
> > im sure if the need rises Rob will consider adding something to manage
> > separate cores, as he did with multitasking recently when a number of
> > people suddenly became interested.
> > Maybe he'd be nice enough to reply to this thread to shed some light
> > on this subject...
>
> That is the problem... cooperative tasking is not going to help with this
> situation.
> The only way we effectively utilize multi-core processors, is by developing
> multi-threaded software. The only way we can do that is if thread-safety was
> implemented.
>
> This is where Rob's point comes in. Programming with multiple threads is quite
> challenging worrying about when to set up mutex locks, race conditions, etc.
> It's also a problem implementing implementing thread-safety in the first
> place.
> But if want to keep Euphoria beating, this surely must be addressed. Rob is
> implementing cooperative tasking; but is that a waste of time? A layer of
> abstraction
> could be developed to ease the programmer from the challenges of thread
> programming.
>
> Figure a CPU had 20 cores... Euphoria would only be able to utilize 1 of them
> per execution. That is 1/20 of the CPU's throughput, thus a much greater
> amount
> of effiecency and performance is possible using multiple threads.
>
Threads may be the answer, at least in some cases. However, as of right
now, I don't think anyone has really 'solved' this problem. Also,
different operating systems may lead to different optimal solutions. For
instance, comparing Windows to most *nix variants, Windows has lighter
weight threads, while a *nix usually has much lighter weight processes.
So the answer could be to figure out how to coordinate different processes
rather than threads. Neither case is simple.
Matt Lewis
5. Re: Important question to all Euphoria users
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.
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.
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.
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Important question to all Euphoria users
Eu's new multitasking is still a single core application. There is one main
thread that switches control to another proccess (ie: task_yield). Eu can't
run two seprate processes in parallel (one must be qued after another). The
only advantage is that we have timed process mechanism.
Even though Eu can only utilize one proccessor, on a duel core system Eu
can run on the main core while the OS will utilize the other core to run
the background type stuff ie: virus scanners and other desktop resident
proccesses.
Note: A program useing more than one core does not benifit in any extra
speed. The overhead of switching states and stacks etc, outwieghs
the performance of a single inline thread.
So in my opinion the only benifit of haveing duel cores is only of benifit
to the OS in that a program won't have to be halted when the OS want's to
update the clock or somethin' stupid like that.
7. Re: Important question to all Euphoria users
- Posted by ags <eu at 531pi.co.nz>
Nov 15, 2005
Hayden McKay wrote:
>
> Eu's new multitasking is still a single core application. There is one main
> thread that switches control to another proccess (ie: task_yield). Eu can't
> run two seprate processes in parallel (one must be qued after another). The
> only advantage is that we have timed process mechanism.
If this is in response to Rob's last message, then I think the point was that
once you code your program in a threaded manner it might be possible in future
for Euphoria to parallelise those threads.
Besides which, I think even current multithreaded applications would have a
hard time running truly concurrently, which I think that article mentioned
also.
> Even though Eu can only utilize one proccessor, on a duel core system Eu
> can run on the main core while the OS will utilize the other core to run
> the background type stuff ie: virus scanners and other desktop resident
> proccesses.
I agree with this. I think it is mainly the domain of the operating system
to determine which CPUs will be used for what. I as a programmer don't want
to be concerned with that detail, nor do I want other programmers able to do
"allocateCPUs(100)" or whatever. It's the job of the operating system to
balance resources fairly and efficiently.
A typical desktop operating system runs maybe 50-100 processes so even if they
are all single threaded, if they are compiled with the operating system's
compiler it is quite feasible for the OS to multi-thread each process according
to whatever resources are available. That's what Linux's SMP does and
that can utilise Hyperthreaded CPUs as well.
> Note: A program useing more than one core does not benifit in any extra
> speed. The overhead of switching states and stacks etc, outwieghs
> the performance of a single inline thread.
The article mentioned that as well.
> So in my opinion the only benifit of haveing duel cores is only of benifit
> to the OS in that a program won't have to be halted when the OS want's to
> update the clock or somethin' stupid like that.
The article talked about possible 100's of core CPUs and how programs can
utilise that most efficiently.
I think the best Euphoria programmers can do is look at ways to thread our
applications (once this is in the binary distribution) and hope that at a
later stage Euphoria uses true OS threads to manage these 'abstract' threads.
Gary
8. 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
9. Re: Important question to all Euphoria users
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.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
10. Re: Important question to all Euphoria users
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
Hayden McKay wrote:
>
> Eu's new multitasking is still a single core application. There is one main
> thread that switches control to another proccess (ie: task_yield). Eu can't
> run two seprate processes in parallel (one must be qued after another). The
> only advantage is that we have timed process mechanism.
>
> Even though Eu can only utilize one proccessor, on a duel core system Eu
> can run on the main core while the OS will utilize the other core to run
> the background type stuff ie: virus scanners and other desktop resident
> proccesses.
>
> Note: A program useing more than one core does not benifit in any extra
> speed. The overhead of switching states and stacks etc, outwieghs
> the performance of a single inline thread.
>
A two thread program wont run twice as fast on a dual-core chip, because
of data exchanging between cores, cache time, other overhead. AMD multi- core
chips may run multi-threaded programs better than Intel chips because their
architecture is better. Intel basically "pastes cores together" sort of speak. A
well developed two thread program may run 75 to 125+ percent faster on a
dual-core processor; hyperthreading can further improve this.
> So in my opinion the only benifit of haveing duel cores is only of benifit
> to the OS in that a program won't have to be halted when the OS want's to
> update the clock or somethin' stupid like that.
The large majority of non-server applications are sequential, single threaded
applications. The OS may allow program processes to run on seperate cores, so
there is increased effeciency, but the programs themselves wont really perform
better, excect for increased built-in
CPU cache. Multi-threaded applications gain all the advantages above,
plus greatly increased performance and efficency, especially on chips
with more than two cores.
I've mentioned Intel and AMD are planning quad-core chips by 2007, so
programs with four threads may speed up 2-3 times verses sequential programs. In
general, as the number of core increase and the greater
number of threads used in apps, the better overall performance compared
to single threaded apps, despite mutex locking and other overhead.
Intel plans to have processors with hundreds of cores within the next decade (10
years), but I cannot really picture how they would manage
that while keeping the chip dimentions small. Imagine a CPU that is
the size and thickness of a standard CD jewel case (huge), with a
several thousand pin socket 
.
Regards,
Vincent
11. Re: Important question to all Euphoria users
- Posted by Craig Roberts <rwallieeyes at earthlink.net>
Nov 15, 2005
-
Last edited Nov 16, 2005
With the enormous strides in nanotechnology lately, it would be easy to
produce small, multi-multi-core cpus. They will probably be very expensive
though.
Regards,
CraigG
Answer: one.
Question: How many psychics does it take to change a light bulb.
12. Re: Important question to all Euphoria users
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
Vincent wrote:
>
> The large majority of non-server applications are sequential, single threaded
> applications. The OS may allow program processes to run on seperate cores, so
> there is increased effeciency, but the programs themselves wont really perform
> better, excect for increased built-in
> CPU cache. Multi-threaded applications gain all the advantages above,
> plus greatly increased performance and efficency, especially on chips
> with more than two cores.
>
> I've mentioned Intel and AMD are planning quad-core chips by 2007, so
> programs with four threads may speed up 2-3 times verses sequential programs.
> In general, as the number of core increase and the greater
> number of threads used in apps, the better overall performance compared
> to single threaded apps, despite mutex locking and other overhead.
Out of curiosity, what sort of things are you doing (or would like to do
that could really benefit from a multi-core architecture with multiple
threads? I can think of a few things I've done that could have benefitted
from this (some custom optimization programs I've done for work), but I
don't think it would really make any useful difference for most things.
Matt Lewis
13. Re: Important question to all Euphoria users
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
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
14. Re: Important question to all Euphoria users
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
Matt Lewis wrote:
>
> Vincent wrote:
> >
> > The large majority of non-server applications are sequential, single
> > threaded
> > applications. The OS may allow program processes to run on seperate cores,
> > so
> > there is increased effeciency, but the programs themselves wont really
> > perform
> > better, excect for increased built-in
> > CPU cache. Multi-threaded applications gain all the advantages above,
> > plus greatly increased performance and efficency, especially on chips
> > with more than two cores.
> >
> > I've mentioned Intel and AMD are planning quad-core chips by 2007, so
> > programs with four threads may speed up 2-3 times verses sequential
> > programs.
> > In general, as the number of core increase and the greater
> > number of threads used in apps, the better overall performance compared
> > to single threaded apps, despite mutex locking and other overhead.
>
> Out of curiosity, what sort of things are you doing (or would like to do
> that could really benefit from a multi-core architecture with multiple
> threads? I can think of a few things I've done that could have benefitted
> from this (some custom optimization programs I've done for work), but I
> don't think it would really make any useful difference for most things.
>
> Matt Lewis
Hi Matt,
It's not that I or anyone else wants to worry about concurrency, it's
the fact these CPU developers/manufacturers are forcing it upon us with their
extreme efforts at improving CPU performance. For the past 30 years, CPU families
have been improved by decreasing circuitry size, increasing transitor count, and
increasing clock frequency. However Moore's Law is finally starting to impose
it's limits on that philosophy, so processor manufacturers are having to come up
with new ways to extend the law a bit longer.
I hope Quantum computing will eventually save us from the traditional
laws of physics.
Regards,
Vincent
15. Re: Important question to all Euphoria users
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
Vincent wrote:
>
> It's not that I or anyone else wants to worry about concurrency, it's
> the fact these CPU developers/manufacturers are forcing it upon us with their
> extreme efforts at improving CPU performance. For the past 30 years, CPU
> families
> have been improved by decreasing circuitry size, increasing transitor count,
> and increasing clock frequency. However Moore's Law is finally starting to
> impose
> it's limits on that philosophy, so processor manufacturers are having to come
> up with new ways to extend the law a bit longer.
I think you misunderstood my question. If you're doing lots of number
crunching, for instance, then you can perhaps benefit from a multi-core
architecture (e.g., SETI at home, etc). Possibly some sort of graphics
intensive application that requires lots of calculations. But not most
of the stuff that most people write. Multiple cores probably aren't going
to give you much if you're doing lots of disk I/O, for instance. Or if
your app sits around waiting for user input.
I understand that the raw speed of processors has stalled, and that the
conventional wisdom is that we'll get multi-cored processors. And that's
probably a big bonus when you consider a system as a whole, where you're
doing multiple things simultaneously, but conventional wisdom also says
that most apps won't benefit from this in the same way that they have
from faster chips.
So. I'm genuinely curious what you (and anyone else with an interesting
answer) would do with this multi-cored machine that would be so much
better that what we have now.
Matt Lewis
16. Re: Important question to all Euphoria users
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 15, 2005
-
Last edited Nov 16, 2005
Matt Lewis wrote:
>
> Vincent wrote:
> >
> > It's not that I or anyone else wants to worry about concurrency, it's
> > the fact these CPU developers/manufacturers are forcing it upon us with
> > their
> > extreme efforts at improving CPU performance. For the past 30 years, CPU
> > families
> > have been improved by decreasing circuitry size, increasing transitor count,
> > and increasing clock frequency. However Moore's Law is finally starting to
> > impose
> > it's limits on that philosophy, so processor manufacturers are having to
> > come
> > up with new ways to extend the law a bit longer.
>
> I think you misunderstood my question. If you're doing lots of number
> crunching, for instance, then you can perhaps benefit from a multi-core
> architecture (e.g., SETI at home, etc). Possibly some sort of graphics
> intensive application that requires lots of calculations. But not most
> of the stuff that most people write. Multiple cores probably aren't going
> to give you much if you're doing lots of disk I/O, for instance. Or if
> your app sits around waiting for user input.
>
> I understand that the raw speed of processors has stalled, and that the
> conventional wisdom is that we'll get multi-cored processors. And that's
> probably a big bonus when you consider a system as a whole, where you're
> doing multiple things simultaneously, but conventional wisdom also says
> that most apps won't benefit from this in the same way that they have
> from faster chips.
Almost any class of application can benefit from this to some extent, but of
course the more CPU intensive applications will have the most impact; that has
always been the case and will continue to be.
Faster clock frequency means more instructions can be processed and sent back to
memory in a given period of time. Multiple core, superscalar processors running
programs designed for parallization, can process more than a few instructions per
cycle. The result is multi-core processors can do more in less time, or the same
at slower clock speeds than regular processors.
> So. I'm genuinely curious what you (and anyone else with an interesting
> answer) would do with this multi-cored machine that would be so much
> better that what we have now.
>
> Matt Lewis
You mean if I had money to buy one? :P
Well... I would do some intense gaming, 3D modeling, digital graphic
design/photo editing, and write libraries for Euphoria. Perhaps I would
do all this while converting a 4 GB movie to DivX, SVCD, or VCD and while
ripping music from a CD to my harddisk.
Most people wont have any trouble taking their machines to the extreme. 
Regards,
Vincent
17. Re: Important question to all Euphoria users
- Posted by ags <eu at 531pi.co.nz>
Nov 17, 2005
Matt Lewis wrote:
> So. I'm genuinely curious what you (and anyone else with an interesting
> answer) would do with this multi-cored machine that would be so much
> better that what we have now.
A couple of things that spring to mind (not for me personally!) would be
decryption (or better encryption) or modelling things like nuclear reactions
(or other scientific modelling for more constructive purposes
Gary
