1. Translator

I downloaded build 2466 via SVN and built from source (on XP). Everything seems to be working well. I then translated a rather large application which also worked well. But what surprised me was the size of the executable - almost 20% smaller than an earlier version. I don't know if this is due to the removal of support for DOS or other changes but I'm not complaining.

With default parameters the translator is very slow on my rather elderly XP system with 512MB RAM. But using -maxsize 10000 reduces this considerably.

new topic     » topic index » view message » categorize

2. Re: Translator

Can you do a bench mark and give me stats of these two commands? To benchmark, you can do:

C:\euphoria> euc -con -o bin\bench.exe demo\bench.ex 
... 
C:\euphoria> bench any_command any_parameters 

So, try this please:

C:\myproject> bench euc -nobuild myproj.ex 
... 
C:\myproject> bench euc -nobuild -maxsize 10000 myproj.ex 

and let me know the final timings. This will be good information.

P.S. Can you please also look at bug https://sourceforge.net/tracker/?func=detail&aid=2834722&group_id=182827&atid=902782 and close it if it's fixed?

Jeremy

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

3. Re: Translator

jeremy said...

Can you do a bench mark and give me stats of these two commands? To benchmark, you can do:

C:\euphoria> euc -con -o bin\bench.exe demo\bench.ex 
... 
C:\euphoria> bench any_command any_parameters 

So, try this please:

C:\myproject> bench euc -nobuild myproj.ex 
... 
C:\myproject> bench euc -nobuild -maxsize 10000 myproj.ex 

and let me know the final timings. This will be good information.

P.S. Can you please also look at bug https://sourceforge.net/tracker/?func=detail&aid=2834722&group_id=182827&atid=902782 and close it if it's fixed?

Jeremy

Timing results:

bench euc -nobuild myproj.ex 48.812

bench euc -nobuild -maxsize 10000 myproj.ex 53.906

bench euc myproj.ex 474.703 3,687,936 bytes

bench euc -maxsize 10000 myproj.ex 178.938 3,628,544 bytes

bench euc -maxsize 5000 myproj.ex 176.875 3,587,072 bytes

bench euc -maxsize 2000 myproj.ex 181.875 3,428,875 bytes

As I expected, translation to a large number of .c files takes longer. But compiling these fles is much faster. The code sizes are surprising.

I don't have exact figures but these times are better than my previous tests.

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

4. Re: Translator

LarryMiller said...

I downloaded build 2466 via SVN and built from source (on XP). Everything seems to be working well. I then translated a rather large application which also worked well. But what surprised me was the size of the executable - almost 20% smaller than an earlier version. I don't know if this is due to the removal of support for DOS or other changes but I'm not complaining.

As a result of the auto-cleanup feature added to euphoria, we've found that temps need to be handled differently. If you look at the end of a routine, you'll notice that it no longer contains a long list of DeRef macros to clean up the temps used in the routine.

First, temps don't automatically get their reference count increased in the case of, say a slice on the RHS of an expression. Instead, the reference is only added if it needs to be. For instance:

    var = seq[sub][script] 

...but the reference count is never incremented in cases like:

    var = length(seq[sub][script]) 

...because the result of the subscript operation is never stored. Since we never increment, we never need to decrement the reference count. This reduces a fair amount of code (20% seems like a lot, but maybe the compiler can do a lot more once all those are gone...or maybe there's something going on in addition to this).

I just overhauled the translator to implement these changes in a systematic way. We've discovered that we need to do something with the interpreter (probably after the first beta release).

LarryMiller said...

With default parameters the translator is very slow on my rather elderly XP system with 512MB RAM. But using -maxsize 10000 reduces this considerably.

That makes sense. The default is 100,000 (I think 10,000 may have been the original default). This means that you end up with bigger .c files, which gives the compiler more to work with, so it can potentially do more optimizations, but, as you found, can increase compile times.

Matt

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

5. Re: Translator

mattlewis said...

That makes sense. The default is 100,000 (I think 10,000 may have been the original default). This means that you end up with bigger .c files, which gives the compiler more to work with, so it can potentially do more optimizations, but, as you found, can increase compile times.

I don't think it normally increases it that much. It was only a second across the translator and interpreter. I think what is really killing the large file compilation on Larry's box is the 512mb of memory. So, a large C file is much more pronounced when the memory is limited than it is on a box with say 2gb of memory.

Jeremy

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

6. Re: Translator

jeremy said...
mattlewis said...

That makes sense. The default is 100,000 (I think 10,000 may have been the original default). This means that you end up with bigger .c files, which gives the compiler more to work with, so it can potentially do more optimizations, but, as you found, can increase compile times.

I don't think it normally increases it that much. It was only a second across the translator and interpreter. I think what is really killing the large file compilation on Larry's box is the 512mb of memory. So, a large C file is much more pronounced when the memory is limited than it is on a box with say 2gb of memory.

Jeremy

I am beginning to think that RAM size may very well be an issue. There is a sizeable increase in the commit charge during the compile and the available memory does go quite low. When this occurs quickly there could be a lot of paging activity.

As you might expect, compiling Euphoria is slow. In this case I have no doubts that RAM is an issue. During a compile the commit charge sometimes exceeds 700MB while normaly it is under 500. I have seen it over 900MB.

Hardly a problem though. I don't compile Euphoria very often and I use the translator primarily to see if it still works.

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

Search



Quick Links

User menu

Not signed in.

Misc Menu