1. Important question to all Euphoria users
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 14, 2005
- 621 views
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
- Posted by Al Getz <Xaxo at aol.com> Nov 14, 2005
- 643 views
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
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 14, 2005
- 584 views
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
- 578 views
- 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
- Posted by Robert Craig <rds at RapidEuphoria.com> Nov 15, 2005
- 583 views
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
- Posted by Hayden McKay <hmck1 at dodo.com.au> Nov 15, 2005
- 576 views
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
- 555 views
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
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 15, 2005
- 571 views
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
- Posted by Al Getz <Xaxo at aol.com> Nov 15, 2005
- 569 views
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
- 580 views
- 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
- 580 views
- 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
- 561 views
- 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
- 587 views
- 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
- 576 views
- 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
- 574 views
- 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
- 563 views
- 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
- 568 views
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