1. documentation errors
- Posted by Alexander Toresson <toressonodakra at swipnet.se> Nov 24, 2004
- 667 views
- Last edited Nov 25, 2004
I found out that the documentation of eu2.5 still says: "lightning-fast pre-compilation. Your program source is checked for syntax and converted into an efficient internal form at over 35,000 lines per second on a lowly Pentium-150." This is currently a pure lie. In eu2.5, you are happy if it reaches 2000 lines per second. /Lex Shhh! Be vewy quiet! I'm hunting wuntime ewwows!
2. Re: documentation errors
- Posted by CoJaBo <CoJaBo_EUforum_Address at CJBN.net> Nov 25, 2004
- 656 views
Alexander Toresson wrote: > > I found out that the documentation of eu2.5 still says: > > "lightning-fast pre-compilation. Your program source is checked for > syntax and converted into an efficient internal form at over > 35,000 lines per second on a lowly Pentium-150." > > This is currently a pure lie. > > In eu2.5, you are happy if it reaches 2000 lines per second. Since 2.5 is only alpha there is still plenty of time for improvement. I belive Rob already said he was working on this. > > /Lex > > Shhh! Be vewy quiet! I'm hunting wuntime ewwows! >
3. Re: documentation errors
- Posted by Robert Craig <rds at RapidEuphoria.com> Nov 25, 2004
- 646 views
Alexander Toresson wrote: > I found out that the documentation of eu2.5 still says: > > "lightning-fast pre-compilation. Your program source is checked for > syntax and converted into an efficient internal form at over > 35,000 lines per second on a lowly Pentium-150." > > This is currently a pure lie. > > In eu2.5, you are happy if it reaches 2000 lines per second. I found out today why the start-up of large programs can be very slow on old machines using 2.5 alpha. I went back to my old Windows ME machine today and did a bunch of careful performance measurements. On my new beta version of the front-end (that I'm still improving), I now get this: 350 MHz Pentium II, 64 Mb RAM Judith's IDE - 103,000 lines of code 2.5 alpha 2.5 beta (work in progress) parse-time: 15 13 time-until SPLASH screen: 48 14 time until ready to use: 70 24 There's more that I'm working on that will improve this. Anyway the main finding was that the time is wasted after the front end is finished, and before the back-end starts, as well as during the initial phase of the back-end. It's due to inefficiencies with WATCOM's management of the the heap. I've fixed that now. This between-ends delay isn't a problem on newer machines. On my XP machine, 1.8 GHz, 256MB RAM, the time-until-ready-to-use is 6 seconds or less of which about 2.5 seconds is parse time. The rest is Judith's initializaton code. Smaller programs parse faster (more lines/sec). The time to parse a program goes up somewhat more than linearly, due to there being thousands of symbols, longer sequences to append to, a bigger heap to search etc. But I guess I should lower the 35000 figure a bit (or raise the CPU MHz), since I'm using machine-generated C for the parser, rather than hand-coded C. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: documentation errors
- Posted by Jason Gade <jaygade at yahoo.com> Nov 25, 2004
- 641 views
Robert Craig wrote: > I found out today why the start-up of large programs can be > very slow on old machines using 2.5 alpha. > I went back to my old Windows ME machine today > and did a bunch of careful performance measurements. > On my new beta version of the front-end (that I'm still improving), > I now get this: > > 350 MHz Pentium II, 64 Mb RAM > Judith's IDE - 103,000 lines of code > > 2.5 alpha 2.5 beta (work in progress) > parse-time: 15 13 > time-until SPLASH screen: 48 14 > time until ready to use: 70 24 > > There's more that I'm working on that will > improve this. Anyway the main finding > was that the time is wasted after the front end > is finished, and before the back-end starts, > as well as during the initial phase of the back-end. > It's due to inefficiencies with WATCOM's management > of the the heap. I've fixed that now. > > This between-ends delay isn't a problem on newer machines. > On my XP machine, 1.8 GHz, 256MB RAM, the > time-until-ready-to-use is 6 seconds or less of which > about 2.5 seconds is parse time. The rest is > Judith's initializaton code. > > Smaller programs parse faster (more lines/sec). > The time to parse a program goes up somewhat > more than linearly, due to there being thousands > of symbols, longer sequences to append to, > a bigger heap to search etc. But I guess I should > lower the 35000 figure a bit (or raise the CPU MHz), > since I'm using machine-generated C for the parser, > rather than hand-coded C. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > Okay, so is there any reason for you to stick with the Watcom compiler? Can you try say the <a href="http://www.digitalmars.com" title="Digital Mars C/C++"/a> Also, Digital Mars D language has a lot of features similar to Euphoria sequences in a compiled language. Could it be used to implement Euphoria? j.
5. Re: documentation errors
- Posted by Jason Gade <jaygade at yahoo.com> Nov 25, 2004
- 647 views
Jason Gade wrote: > > Robert Craig wrote: > > > I found out today why the start-up of large programs can be > > very slow on old machines using 2.5 alpha. > > I went back to my old Windows ME machine today > > and did a bunch of careful performance measurements. > > On my new beta version of the front-end (that I'm still improving), > > I now get this: > > > > 350 MHz Pentium II, 64 Mb RAM > > Judith's IDE - 103,000 lines of code > > > > 2.5 alpha 2.5 beta (work in progress) > > parse-time: 15 13 > > time-until SPLASH screen: 48 14 > > time until ready to use: 70 24 > > > > There's more that I'm working on that will > > improve this. Anyway the main finding > > was that the time is wasted after the front end > > is finished, and before the back-end starts, > > as well as during the initial phase of the back-end. > > It's due to inefficiencies with WATCOM's management > > of the the heap. I've fixed that now. > > > > This between-ends delay isn't a problem on newer machines. > > On my XP machine, 1.8 GHz, 256MB RAM, the > > time-until-ready-to-use is 6 seconds or less of which > > about 2.5 seconds is parse time. The rest is > > Judith's initializaton code. > > > > Smaller programs parse faster (more lines/sec). > > The time to parse a program goes up somewhat > > more than linearly, due to there being thousands > > of symbols, longer sequences to append to, > > a bigger heap to search etc. But I guess I should > > lower the 35000 figure a bit (or raise the CPU MHz), > > since I'm using machine-generated C for the parser, > > rather than hand-coded C. > > > > Regards, > > Rob Craig > > Rapid Deployment Software > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > > Okay, so is there any reason for you to stick with the Watcom compiler? Can > you try > say the <a href="http://www.digitalmars.com" title="Digital Mars C/C++"></a> > > Also, Digital Mars D language has a lot of features similar to Euphoria > sequences in > a compiled language. Could it be used to implement Euphoria? > > > j. > Sorry, last message had badly formed HTML. I'm not an HTML expert... j.
6. Re: documentation errors
- Posted by Robert Craig <rds at RapidEuphoria.com> Nov 25, 2004
- 677 views
Jason Gade wrote: > Okay, so is there any reason for you to stick with the Watcom compiler? Can > you try Yes. It's quite solid and generates excellent code. Now that I think of it, I'm not even using Watcom's heap manager any more on Windows, only on DOS. I'm using Microsoft's heap. The problem was the huge number of free blocks I was suddenly creating, and also the large amount of memory I was using. I use a lot less memory now. Any heap manager can have peculiar situations where its performance drops off badly. > say the <a href="http://www.digitalmars.com" title="Digital Mars C/C++"/a> > > Also, Digital Mars D language has a lot of features similar to Euphoria > sequences in > a compiled language. Could it be used to implement Euphoria? Probably, but I already support 7 C compilers, any of which can be used to build the interpreter. I really don't want to test another, thanks. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
7. Re: documentation errors
- Posted by Jason Gade <jaygade at yahoo.com> Nov 25, 2004
- 677 views
Robert Craig wrote: > > Jason Gade wrote: > > Okay, so is there any reason for you to stick with the Watcom compiler? > > Yes. It's quite solid and generates excellent code. > > Now that I think of it, I'm not even using Watcom's > heap manager any more on Windows, only on DOS. > I'm using Microsoft's heap. The problem was the huge number > of free blocks I was suddenly creating, and also the > large amount of memory I was using. I use a lot less memory now. > Any heap manager can have peculiar situations where its > performance drops off badly. > > > Can you try say the <a href="http://www.digitalmars.com" title="Digital > > Mars C/C++"></a> > > > > Also, Digital Mars D language has a lot of features similar to Euphoria > > sequences in > > a compiled language. Could it be used to implement Euphoria? > > Probably, but I already support 7 C compilers, > any of which can be used to build the interpreter. > I really don't want to test another, thanks. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > Okay, I know you're very busy keeping Euphoria up to date and all. I just wanted to make a suggestion. Digital Mars C/C++ is formerly Symantec C/C++ and is free(as in beer). It is very fast compiling but I don't know about the quality of the code. If you drop LCC, you should check it out. Also, FYI, Digital Mars D language is a compiled language that has a lot of features that people around here have requested of Euphoria for a long time. It might be interesting to implement the public domain Euphoria backend in D. It would also be interesting to see if it was possible to create a Euphoria to D translator, but both of those tasks are beyond my meager abilities. On another note, can you implement wordwrap and preview on the listfilter interface? Also my sig consists of a line of dashes and then a sig but it doesn't show up. j.
8. Re: documentation errors
- Posted by "Igor Kachan" <kinz at peterlink.ru> Nov 25, 2004
- 629 views
Alexander Toresson wrote: > I found out that the documentation of eu2.5 still says: > > "lightning-fast pre-compilation. Your program source is checked for > syntax and converted into an efficient internal form at over > 35,000 lines per second on a lowly Pentium-150." > > This is currently a pure lie. This is just an old number in a new draft alpha documentation. These numbers will be changing from day to day to be more correct and precise in the official 2.5. It is not a *lie* at all. We *all do know* that the pre-compilation is slower in 2.5. I know about this fact from February or so, from this list, BTW. I am sorry, select your words, please. > In eu2.5, you are happy if it reaches 2000 lines per second. It depends. What is your method, machine, test program, test code? Regards, Igor Kachan kinz at peterlink.ru
9. Re: documentation errors
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 25, 2004
- 629 views
- Last edited Nov 26, 2004
Robert Craig wrote: <snip> > I found out today why the start-up of large programs can be > very slow on old machines using 2.5 alpha. > I went back to my old Windows ME machine today > and did a bunch of careful performance measurements. > On my new beta version of the front-end (that I'm still improving), > I now get this: > > 350 MHz Pentium II, 64 Mb RAM > Judith's IDE - 103,000 lines of code > > 2.5 alpha 2.5 beta (work in progress) > parse-time: 15 13 > time-until SPLASH screen: 48 14 > time until ready to use: 70 24 > > There's more that I'm working on that will > improve this. All this sounds very promising. <snip> Regards, Juergen -- Have you read a good program lately?