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!

new topic     » topic index » view message » categorize

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!
>

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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.

new topic     » goto parent     » topic index » view message » categorize

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.

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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.

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

9. Re: documentation errors

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. smile

<snip>

Regards,
   Juergen

-- 
Have you read a good program lately?

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu