1. Translator/Compiler Hints
This is a multi-part message in MIME format.
------=_NextPart_000_0004_01C3B927.529D27C0
charset="iso-8859-1"
I purpose some sort of hints for translators/compilers for euphoria, that tell
certain things about the program and speed up the compiled program, but be
completly ignored by interpeter.
These hints would include things like profiling, unregistering variables,
variable sizes and types, inlining of function/procedures, inlining of assembly/C
calls. These hints are there for the purpose of optimization of size(memsize and
disk size) and speed.
The need for thses hints come from observing very poor performance doing
software graphics or heavy math in pure euphoria. The performance of other more
control centered processing is very good and doesn't need the hints.
Some example of the hints may be:
specifying type classes like C
for atoms and ints -----> char/short/long/longer(forgot what a 64bit int
is)/float/double/extdouble(80bit)
for sequences -> the C style struct may be good or maybe simple things
like char arrays
profiling is currently absent from compiled/translated euphoria, adding that
would be good
and maybe a different from though, use the ReadTimeStamp instruction to get tick
accurite profiling
unregistering variables, say your working with large arrays, it is somtimes
nessasary to be able to dynamically free up that memory used by them.
inlining of functions/procedures, If you like to right clean code, and want the
speed back thats wasted on procedure/function calls, especially if called very
often, then you may wish to make it inline and cut away that speed loss
inlining of assembly/C calls, while the new c_func()/c_proc do go along way I
think there still may be a way to make them better, thus I purpose a method for
allowing the assembly to be more integrated with the inlining and TYPEing in the
new hints
size hints, for when you are making a huge sequence, or huge char array, or huge
float array, actually allocates the mem instead of just making copies of stuff
I think that kind of covers alot, but maybe not so well. I would like comments,
cause this all sounds pretty cool to me. I'm not at all fond of C, but I do like
the speed of it for Graphics/HeavyMath so I want to give myself and everyone else
an excuse not to ever use it again. And I like Assembly just fine, I just don't
like righting whole pieces of code in it because of the weaknesses of euphoria,
so I want to make it stronger. And another application that comes to mind is
networking protocols or servers transfering data quickly.
In summary, just add hints to help the compiler/translator make better code, and
in the process make euphoria way more usefulll.
Daniel Kluss(xerox_irs at lvcm.com or codepilot at netzero.net or xerox_irs at
hotmail.com, redundancy makes the world go round)
------=_NextPart_000_0004_01C3B927.529D27C0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>I purpose some sort of hints for
translators/compilers for euphoria, that tell certain things about the program
and speed up the compiled program, but be completly ignored by
interpeter.</FONT></DIV>
<DIV><FONT face=Arial size=2>These hints would include things like profiling,
unregistering variables, variable sizes and types, inlining of
function/procedures, inlining of assembly/C calls. These hints are there for the
purpose of optimization of size(memsize and disk size) and
speed.</FONT></DIV>
<DIV><FONT face=Arial size=2>The need for thses hints come from observing very
poor performance doing software graphics or heavy math in pure euphoria. The
performance of other more control centered processing is very good and
doesn't need the hints.</FONT></DIV>
<DIV><FONT face=Arial size=2>Some example of the hints may be:</FONT></DIV>
<DIV><FONT face=Arial size=2>specifying type classes like C</FONT></DIV>
<DIV><FONT face=Arial size=2>for atoms and ints ----->
char/short/long/longer(forgot what a 64bit int
is)/float/double/extdouble(80bit)</FONT></DIV>
<DIV><FONT face=Arial size=2>for sequences
-> the C style struct may be good or maybe simple things like char
arrays</FONT></DIV>
<DIV><FONT face=Arial size=2>profiling is currently absent from
compiled/translated euphoria, adding that would be good</FONT></DIV>
<DIV><FONT face=Arial size=2>and maybe a different from though, use the
ReadTimeStamp instruction to get tick accurite profiling</FONT></DIV>
<DIV><FONT face=Arial size=2>unregistering variables, say your working with
large arrays, it is somtimes nessasary to be able to dynamically free up that
memory used by them.</FONT></DIV>
<DIV><FONT face=Arial size=2>inlining of functions/procedures, If you like to
right clean code, and want the speed back thats wasted on procedure/function
calls, especially if called very often, then you may wish to make it inline and
cut away that speed loss</FONT></DIV>
<DIV><FONT face=Arial size=2>inlining of assembly/C calls, while the new
c_func()/c_proc do go along way I think there still may be a way to make them
better, thus I purpose a method for allowing the assembly to be more integrated
with the inlining and TYPEing in the new hints</FONT></DIV>
<DIV><FONT face=Arial size=2>size hints, for when you are making a huge
sequence, or huge char array, or huge float array, actually allocates the mem
instead of just making copies of stuff</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I think that kind of covers alot, but maybe not so
well. I would like comments, cause this all sounds pretty cool to me. I'm not at
all fond of C, but I do like the speed of it for Graphics/HeavyMath so I want to
give myself and everyone else an excuse not to ever use it again. And I like
Assembly just fine, I just don't like righting whole pieces of code in it
because of the weaknesses of euphoria, so I want to make it stronger. And
another application that comes to mind is networking protocols or servers
transfering data quickly.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>In summary, just add hints to help the
compiler/translator make better code, and in the process make euphoria way more
usefulll.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Daniel Kluss(<A
href="mailto:xerox_irs at lvcm.com">xerox_irs at lvcm.com</A> or <A
href="mailto:codepilot at netzero.net">codepilot at netzero.net</A> or <A
href="mailto:xerox_irs at hotmail.com">xerox_irs at hotmail.com</A>, redundancy
makes
------=_NextPart_000_0004_01C3B927.529D27C0--
2. Re: Translator/Compiler Hints
Daniel Kluss wrote:
> I purpose some sort of hints for translators/compilers for euphoria,
> that tell certain things about the program and speed up the compiled
> program, but be completly ignored by interpeter.
> These hints would include things like profiling, unregistering
> variables, variable sizes and types, inlining of function/procedures,
> inlining of assembly/C calls. These hints are there for the purpose of
> optimization of size(memsize and disk size) and speed.
> The need for thses hints come from observing very poor performance doing
> software graphics or heavy math in pure euphoria. The performance of
> other more control centered processing is very good and doesn't need the
> hints.
If you have some examples of Euphoria code that does not
translate into fast C code, I'd like to see it.
There may be other ways of speeding things up.
> Some example of the hints may be:
> specifying type classes like C
> for atoms and ints -----> char/short/long/longer(forgot what a 64bit int
> is)/float/double/extdouble(80bit)
> for sequences -> the C style struct may be good or maybe simple
> things like char arrays
> profiling is currently absent from compiled/translated euphoria, adding
> that would be good
> and maybe a different from though, use the ReadTimeStamp instruction to
> get tick accurite profiling
> unregistering variables, say your working with large arrays, it is
> somtimes nessasary to be able to dynamically free up that memory used by
> them.
> inlining of functions/procedures, If you like to right clean code, and
> want the speed back thats wasted on procedure/function calls, especially
> if called very often, then you may wish to make it inline and cut away
> that speed loss
> inlining of assembly/C calls, while the new c_func()/c_proc do go along
> way I think there still may be a way to make them better, thus I purpose
> a method for allowing the assembly to be more integrated with the
> inlining and TYPEing in the new hints
> size hints, for when you are making a huge sequence, or huge char array,
> or huge float array, actually allocates the mem instead of just making
> copies of stuff
>
> I think that kind of covers alot, but maybe not so well. I would like
> comments, cause this all sounds pretty cool to me. I'm not at all fond
> of C, but I do like the speed of it for Graphics/HeavyMath so I want to
> give myself and everyone else an excuse not to ever use it again. And I
> like Assembly just fine, I just don't like righting whole pieces of code
> in it because of the weaknesses of euphoria, so I want to make it
> stronger. And another application that comes to mind is networking
> protocols or servers transfering data quickly.
>
> In summary, just add hints to help the compiler/translator make better
> code, and in the process make euphoria way more usefulll.
These are interesting ideas, and
for someone who is very concerned about speed,
what you request is quite valid, but I think in order to
avoid the "need for C" your plan would essentially change
Euphoria into C. I'd rather make the Translator itself
smarter, than add syntax for lots of small hints that would
each allow a tiny improvement in the C code, such as
eliminating an if-statement here and there.
Adding hints seems inelegant.
It would also create additional cases to test,
and therefore might detract from the reliability of the Translator.
There are still several algorithmic improvements I can make
in the Translator to get better C code. I could, as you suggest,
in-line some routines, but my experience with various
C compilers tells me that in-lining often does not
pay off, especially since code size and caching will be worse.
In practice, with at least 3 different C compilers,
I've found it caused code-generation bugs, maybe because
it isn't used (tested) that much.
(Of course I'd implement it perfectly. 
)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Translator/Compiler Hints
Below
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: <EUforum at topica.com>
Subject: Re: Translator/Compiler Hints
>
>
> Daniel Kluss wrote:
> > I purpose some sort of hints for translators/compilers for euphoria,
> > that tell certain things about the program and speed up the compiled
> > program, but be completly ignored by interpeter.
> > These hints would include things like profiling, unregistering
> > variables, variable sizes and types, inlining of function/procedures,
> > inlining of assembly/C calls. These hints are there for the purpose of
> > optimization of size(memsize and disk size) and speed.
> > The need for thses hints come from observing very poor performance doing
> > software graphics or heavy math in pure euphoria. The performance of
> > other more control centered processing is very good and doesn't need the
> > hints.
>
> If you have some examples of Euphoria code that does not
> translate into fast C code, I'd like to see it.
> There may be other ways of speeding things up.
Not only do I have things that go slow, I got things that crash when
translated to C.
I made a ray tracer a while ago, and translated that, and it went 25% faster
then interpreted.
Then I made the same thing in native C and it when 200%-500% faster then
interpreted.
The algorythems were Identical, I think the speed gets hurt from checking
every atom/element of a sequence to see if it is a Double of Int(Ive look at
the code, should be slow at all), and even then I think I might be just some
of something else.
Maybe you should experiment with making translator to ASM and use like MASM
to compile it, and see how many insructions it takes per calculation, then
get that number down and I will be much faster. But thats alot of work.
>
> > Some example of the hints may be:
> > specifying type classes like C
> > for atoms and ints -----> char/short/long/longer(forgot what a 64bit int
> > is)/float/double/extdouble(80bit)
> > for sequences -> the C style struct may be good or maybe simple
> > things like char arrays
> > profiling is currently absent from compiled/translated euphoria, adding
> > that would be good
> > and maybe a different from though, use the ReadTimeStamp instruction to
> > get tick accurite profiling
> > unregistering variables, say your working with large arrays, it is
> > somtimes nessasary to be able to dynamically free up that memory used by
> > them.
> > inlining of functions/procedures, If you like to right clean code, and
> > want the speed back thats wasted on procedure/function calls, especially
> > if called very often, then you may wish to make it inline and cut away
> > that speed loss
> > inlining of assembly/C calls, while the new c_func()/c_proc do go along
> > way I think there still may be a way to make them better, thus I purpose
> > a method for allowing the assembly to be more integrated with the
> > inlining and TYPEing in the new hints
> > size hints, for when you are making a huge sequence, or huge char array,
> > or huge float array, actually allocates the mem instead of just making
> > copies of stuff
> >
> > I think that kind of covers alot, but maybe not so well. I would like
> > comments, cause this all sounds pretty cool to me. I'm not at all fond
> > of C, but I do like the speed of it for Graphics/HeavyMath so I want to
> > give myself and everyone else an excuse not to ever use it again. And I
> > like Assembly just fine, I just don't like righting whole pieces of code
> > in it because of the weaknesses of euphoria, so I want to make it
> > stronger. And another application that comes to mind is networking
> > protocols or servers transfering data quickly.
> >
> > In summary, just add hints to help the compiler/translator make better
> > code, and in the process make euphoria way more usefulll.
>
> These are interesting ideas, and
> for someone who is very concerned about speed,
> what you request is quite valid, but I think in order to
> avoid the "need for C" your plan would essentially change
> Euphoria into C. I'd rather make the Translator itself
> smarter, than add syntax for lots of small hints that would
> each allow a tiny improvement in the C code, such as
> eliminating an if-statement here and there.
I don't mean to change Euphroia into C, but like have a little file that
goes with the source and describes what some of the variables are. Say like
an XML file, that my work pretty nice.
Ex.
Euphoria Source
sequence a
a="hello world"
puts(1,a)
XML hints--
<source>
<a>char*="hello world" maxlen=100 minlen=5</a>
</souce>
And thats pretty much it, no actual change of the source file, and the XML
hints are not nessasary.
And that should make that puts() alot faster, say if you did it a million
times, cause it no longer has to check every element one at a time, instead
makes it a standard C string type thing.
>
> Adding hints seems inelegant.
> It would also create additional cases to test,
> and therefore might detract from the reliability of the Translator.
>
I do see how the reliability could be comprimised, say if someone gave an
inaccurate hint, so something but maybe the hints a very special cases.
But I realy don't think the translator could always know when someone realy
wants a string, not a sequence and when somone only needs floats and not
doubles.
> There are still several algorithmic improvements I can make
> in the Translator to get better C code. I could, as you suggest,
> in-line some routines, but my experience with various
> C compilers tells me that in-lining often does not
> pay off, especially since code size and caching will be worse.
Maybe not inline in the C code, but preprocess the euphoria and inline the
procedures inside.
> In practice, with at least 3 different C compilers,
> I've found it caused code-generation bugs, maybe because
> it isn't used (tested) that much.
> (Of course I'd implement it perfectly. )
Daniel Kluss
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
