On 25/02/2010 00:08, David Terei wrote:
Simon Marlow wrote:
> So, nofib programs are on average 4-5% slower, with a 6% increase in
> binary sizes (this is with -split-objs).
>
> What's interesting is that there are some outliers here: programs that
> go 12-17% slower without TNTC. Looking at David's thesis the results are
> quite different. Perhaps it is processor dependent?
I ran nofib again and am getting results similar to yours. I have
all the nofib runs laying around from my thesis and they give the
results I put in it. Seems to perhaps be a mistake from me that the TNTC
enabled runs weren't optimal due to some background process I didn't
notice. Also there were some nofib programs I didn't include at that
time due to problems getting them running, the missing ones seems to
have reduced the advantage of TNTC.
> I have to admit, the results I'm getting are what I would expect, so its
> conceivable that some subconscious experimental bias has crept in
> somewhere :-)
Actually its more of an unconscious self sabotage. When I did the
benchmarking of TNTC I was hoping to get the 4-6% value that I had seen
talked of before since that's basically the margin by which the LLVM
back-end is slower then the NCG. I think my body was punishing me from
lack of sleep :).
Ok, at least that's cleared up.
> [snip/new email]
So here's a crazy idea. Why don't we post-process the assembly code
coming out of LLVM? Before you throw up your hands in horror, consider
that
I think it should work pretty well, especially if its intentioned to
just be a stopgap solution until we get support for TNTC from LLVM.
Great!
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
