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
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 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!
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
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 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
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
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
13 matches
Mail list logo
