1. documentation errors
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
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
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
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
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
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
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
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
-
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?
