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
|
Not Categorized, Please Help
|
|
