On 2/24/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| last days i studied GHC code generator, reading -ddumps of all sorts,
| GHC sources, various papers and John's appeals :)
|
| what i carried from this investigation:
|
| GHC has great high-level optimization. moreover, GHC now allows
Hello Simon,
Friday, February 24, 2006, 12:52:36 PM, you wrote:
SM Wow! You make a lot of good suggestions. I think some of them are
SM unfortunately unworkable, some others have been tried before, but there
SM are definitely some to try. I'll suggest a few more in this email.
can you comment
Bulat Ziganshin wrote:
* C++ calling stack should be used as much as possible
* parameters are passed in C++ way: factorial(int n, int r)
SM This is unworkable, I'm afraid. Go and read Simon's paper on the STG:
SMhttp://citeseer.ist.psu.edu/peytonjones92implementing.html
SM there are
Hello Simon,
Friday, February 24, 2006, 12:30:22 PM, you wrote:
SPJ | GHC has great high-level optimization.
SPJ However, let me strongly urge you *not* to focus attention primarily on
SPJ the gcc route. Compiling via C has received a lot of attention over the
SPJ years, and there are many
Hello,
SPJ tail calls is another,
nowadays gcc optimize tail calls
I found this thesis on the subject by Andreas Bauer:
Compilation of Functional Programming Languages using GCC -- Tail
Calls
Do you know if it is his work that was incorporated into GCC?
I browsed trough some parts of
But there are serious obstacles. That's not gcc's fault -- it wasn't
designed for this. Accurate GC is one of them, tail calls is another,
and there are plenty more smaller things that bite you only after you've
invested a lot of time. This way lies madness.
What about llvm[1]? It was
[EMAIL PROTECTED] wrote:
...
as you can see here, gcc isn't unrolled the loop and retained all the
stack-register moves. why? the short answer is what gcc just don't
know that data pointed by the Sp pointer is non-volatile - they can't
be changed in middle of the program by some async
Hello kyra,
Friday, February 24, 2006, 12:37:02 AM, you wrote:
i prefer to see the asm code. this may be because of better high-level
optimization strategies (reusing fib values). the scheme about i say
will combine advantages of both worlds
k no strategies, plain exponential algorithm,
yes,
Hello Ben,
Friday, February 24, 2006, 2:04:26 AM, you wrote:
* multiple results can be returned via C++ paira,b template, if this is
efficiently implemented in gcc
BRG There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off
BRG by default on many architectures.
thank you!
Hello Jean-Philippe,
Friday, February 24, 2006, 2:04:57 AM, you wrote:
JPB From my (limited) knowledge of GHC backend, the difficult part of your
JPB plan is that STG is not suited to compilation to native C at all. You
JPB might need to do quite advanced translation from STG to another
JPB
| last days i studied GHC code generator, reading -ddumps of all sorts,
| GHC sources, various papers and John's appeals :)
|
| what i carried from this investigation:
|
| GHC has great high-level optimization. moreover, GHC now allows to
| program STG almost directly. when i look at STG code i
Hi Bulat,
Wow! You make a lot of good suggestions. I think some of them are
unfortunately unworkable, some others have been tried before, but there
are definitely some to try. I'll suggest a few more in this email.
First of all I should say that we don't *want* to use gcc as a code
On 2/24/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello kyra,
Friday, February 24, 2006, 12:37:02 AM, you wrote:
i prefer to see the asm code. this may be because of better high-level
optimization strategies (reusing fib values). the scheme about i say
will combine advantages of both
| The closest thing I've seen to a solution is the technique used in
Urban
| Boquist's thesis, which is to put a static table in the executable
with
| information about register and stack usage indexed by procedure return
| point, and use that to unwind the stack and find roots.
Every accurate
Rene de Visser wrote:
Integer is about 30 times slower than it needs to be on GHC if you have
over half the values between 2^-31 and 2^31. On i386 can you basically
can test the low bit for free (it runs in parallel to the integer add
instruction). This would allow only values outside this
Hello Lemmih,
Friday, February 24, 2006, 1:15:51 PM, you wrote:
clean differs from Haskell in support of unique types and strictness
annotations. the last is slowly migrates into GHC in form of shebang
patters, but i think that it is a half-solution. i mentioned in
original letter my
On 2/24/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Lemmih,
Friday, February 24, 2006, 1:15:51 PM, you wrote:
clean differs from Haskell in support of unique types and strictness
annotations. the last is slowly migrates into GHC in form of shebang
patters, but i think that it is a
Hello Lemmih,
Friday, February 24, 2006, 8:55:37 PM, you wrote:
x :: ![Int]
translates to the
data StrictList a = Nil | Cons a !(StrictList a)
x :: !(StrictList a)
L Let's try this:
L x :: ![Int] - Int
L It would translate to something like this:
L mkStrictList :: [a] - StrictList a
L
Another shortcoming is that the native code generator in GHC isn't
capable of dealing with backward jumps to labels (because GHC hasn't
needed that so far). But if you did C-- optimisation, you'd probably
generate such jumps. It'd be great to beef up the native code gen to
handle that.
I'm
Simon Peyton-Jones wrote:
| [...] put a static table in the executable with
| information about register and stack usage indexed by procedure return
| point, and use that to unwind the stack and find roots.
Every accurate garbage collector (including GHC's) uses a technique like
this, but the
The following link gives reasons for not generating via C
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
Naturally a number of these are common lisp specific, however I think that
Haskell and GCC are quite semantically different, so using GCC might
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i read it now
RdV Naturally a number of these are common lisp specific,
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is generated. changing the translation of STG can't
prevent ANY ghc
Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
didn't try factorial, but exponential fib in ocaml is *FASTER* than both
gcc and intel c/c++ with highest optimization levels
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
code generated by ghc has
Hello kyra,
Thursday, February 23, 2006, 5:38:54 PM, you wrote:
k Bulat Ziganshin wrote:
i think that ocaml can't generate code better than gcc and especially
icc (intel C/C++ compiler), but may be i'm wrong? ;)
k didn't try factorial, but exponential fib in ocaml is *FASTER* than both
k
Hello Rene,
Thursday, February 23, 2006, 5:32:21 PM, you wrote:
seems that you don;t understand the situation. ghc compiles Haskell to
language called core, do almost all optimizations at level of this
language, then translates final result to the STG language from that
the C-- code is
Hello Rene,
Thursday, February 23, 2006, 4:19:15 PM, you wrote:
RdV The following link gives reasons for not generating via C
RdV
http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=4zp8kn7xe.fsf_-_%40beta.franz.com
i done reading. my question - is YOU read this? the lisp problems have
Claus Reinke writes:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code usually written by the C programmers. but
Hello Claus,
Thursday, February 23, 2006, 8:56:57 PM, you wrote:
the long answer is: are you ever heard promises that gcc is best
cpu-independent assembler? no? and you know why? because gcc is not
cpu-independent assembler. gcc was strongly optimized to make
efficient asm from the code
Hello Kevin,
Thursday, February 23, 2006, 9:06:25 PM, you wrote:
KG On a related point, Mercury has two C backends a low level one at the
KG level of GHC's and a high level one. Bulat might want to read this for
KG a description of the high level C implementation:
KG
KG
Bulat Ziganshin writes:
Hello Kevin,
KG Also, ghc used to be faster than gcc for a naive, recursive factorial
KG function (once the cpr analysis and optimisation was added). From
KG what Bulat wrote it seems that gcc got better ...
i don't say that we must compile recursive
From: Bulat Ziganshin [EMAIL PROTECTED]
Hello Rene,
i done reading. my question - is YOU read this? the lisp problems have
almost
nothing in common with haskell
It is a long time since i read this, but some things come to mind. Listed
below.
Maybe GHC should generate better C. I am
Hello Rene,
Thursday, February 23, 2006, 10:17:40 PM, you wrote:
RdV Maybe GHC should generate better C. I am just not sure whether this will
RdV bring the best global (as opposed to micro-optimizations) performance.
i answered in the original letter (search for Cray :)
RdV Generating better C
From: Bulat Ziganshin [EMAIL PROTECTED]
i answered in the original letter (search for Cray :)
Re-reading this, I see that you have a well defined goals that cover most of
my points.
seems that you don't seen the attached files. tail calls are optimized
in gcc
No I don't see any
Bulat Ziganshin wrote:
i prefer to see the asm code. this may be because of better high-level
optimization strategies (reusing fib values). the scheme about i say
will combine advantages of both worlds
no strategies, plain exponential algorithm,
ocaml:
excerpt
_camlFibo__fib_57:
sub
[EMAIL PROTECTED] wrote:
* multiple results can be returned via C++ paira,b template, if this is
efficiently implemented in gcc
There's a -freg-struct-return option in 2.x, 3.x and 4.x. I think it's off
by default on many architectures.
* recursive definitions translated into the for/while
Hello Bulat,
From my (limited) knowledge of GHC backend, the difficult part of your
plan is that STG is not suited to compilation to native C at all. You
might need to do quite advanced translation from STG to another
intemediate language, (as GRIN for example), and then some more
advanced
38 matches
Mail list logo
