davidterei:
>
> I've been looking at some of these cases and seeing how the LLVM
> back-end performs. My general impression from benchmarking the LLVM
> back-end in the past has been that it generally performs with similar
> characteristics as the C code generator (that is, where the C code
On 17/02/2010 21:15, Scott Michel wrote:
Depends a lot on the benchmark. The FreeBSD kernel dev crowd (one of
whom works for me) have seen performance improvements between 10-20%
using LLVM and clang over gcc. It also depends heavily on which
optimization passes you have LLVM invoke -- bear in m
Don Stewart wrote:
Here's an example that doesn't use floating point:
import Data.Array.Vector
import Data.Bits
main = print . sumU $ zipWith3U (\x y z -> x * y * z)
(enumFromToU 1 (1 :: Int))
(enumFromToU 2 (10001 :: Int))
(enumFromToU 7 (10008 :: Int))
In core:
main_$s$wfold
On Tue, Feb 16, 2010 at 11:37 PM, Isaac Dupree <
m...@isaac.cedarswampstudios.org> wrote:
> If you finish your CellSPU work, great! GHC 6.16 or so might be able to
> perform well on CellSPU! If not, then the present situation of using the
> "unregisterized" (slow) C backend will still be available
On Wed, Feb 17, 2010 at 6:19 AM, Simon Marlow wrote:
> On 17/02/10 07:37, Isaac Dupree wrote:
>
>> On 02/16/10 20:13, Roman Leshchinskiy wrote:
>>
>>> On 15/02/2010, at 04:58, Don Stewart wrote:
>>>
>>> Do we have the blessing of the DPH team, wrt. tight, numeric inner
loops?
>>>
>>> F
Am Mittwoch 17 Februar 2010 15:19:33 schrieb Simon Marlow:
> I should point out that for most Haskell programs, the NCG is already as
> fast (in some cases faster) than via C. The benchmarks showing a
> difference are all of the small tight loop kind - which are important to
> some people, I don't
On 17/02/10 07:37, Isaac Dupree wrote:
On 02/16/10 20:13, Roman Leshchinskiy wrote:
On 15/02/2010, at 04:58, Don Stewart wrote:
Do we have the blessing of the DPH team, wrt. tight, numeric inner
loops?
FWIW, I don't think we even use -fvia-C when benchmarking. In general,
-fvia-C is a dead e
On 17/02/2010, at 18:37, Isaac Dupree wrote:
> LLVM and GCC are open-source projects that are improving over time... is
> there any particular reason we expect GCC to have poor numeric performance
> forever?
Past experience :-) GCC has been around for a while and if it doesn't optimise
numeric
On 02/16/10 20:13, Roman Leshchinskiy wrote:
On 15/02/2010, at 04:58, Don Stewart wrote:
Do we have the blessing of the DPH team, wrt. tight, numeric inner loops?
FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C
is a dead end wrt numeric performance because gcc
m my Verizon Wireless BlackBerry
>
> -Original Message-
> From: scooter@gmail.com
> Date: Wed, 17 Feb 2010 03:26:08
> To: Don Stewart;
> Subject: Re: Removing/deprecating -fvia-c
>
> It seems to me, in the absence of any other fallback, that the C
> backen
s research department for a non-for-profit in
real life.
Sent from my Verizon Wireless BlackBerry
-Original Message-
From: scooter@gmail.com
Date: Wed, 17 Feb 2010 03:26:08
To: Don Stewart;
Subject: Re: Removing/deprecating -fvia-c
It seems to me, in the absence of any other fallback,
t's
like Monad: not everything is pure.
My vote is to keep the C backend. If it's good enough for LLVM, it's probably
good enough for GHC.
-scooter
--Original Message--
From: Don Stewart
Sender: glasgow-haskell-users-boun...@haskell.org
To: glasgow-haskell-users@haskell.org
Subj
Simon Marlow:
> [..]
> But let's face it, all of this code is crappy. It should be a tiny little
> loop rather than a tail-call with argument passing, and that's what we'll get
> with the new backend (eventually). LLVM probably won't turn it into a loop
> on its own, that needs to be done befo
On 15/02/2010, at 04:58, Don Stewart wrote:
> Do we have the blessing of the DPH team, wrt. tight, numeric inner loops?
FWIW, I don't think we even use -fvia-C when benchmarking. In general, -fvia-C
is a dead end wrt numeric performance because gcc just doesn't optimise well
enough. So even if
On Feb 16, 2010, at 12:51 PM, Don Stewart wrote:
> about the time -fvia-C dies?
I wrote more lines of raw C code in my youth than I'd care to remember, before
coming to the realization that the most important benchmark is "brain time" not
"cpu time". With this revelation, there is no language l
marlowsd:
>
> I manged to improve this:
>
> Main_mainzuzdszdwfold_info:
> .Lc1lP:
> addq $32,%r12
> cmpq 144(%r13),%r12
> ja .Lc1lS
> movq %r14,%rax
> cmpq $10,%rax
> jne .Lc1lV
> movq $ghczmprim_GHCziTypes_Dzh_con_info,-24(%r12)
>
On 15/02/2010 18:29, Don Stewart wrote:
marlowsd:
Simon Marlow has recently fixed FP performance for modern x86 chips in
the native code generator in the HEAD. That was the last reason we know
of to prefer via-C to the native code generators. But before we start
the removal process, does anyone
dons:
> marlowsd:
> >>>
> >>> Simon Marlow has recently fixed FP performance for modern x86 chips in
> >>> the native code generator in the HEAD. That was the last reason we know
> >>> of to prefer via-C to the native code generators. But before we start
> >>> the removal process, does anyone know
Am Montag 15 Februar 2010 17:37:55 schrieb Simon Marlow:
> On 14/02/2010 17:58, Don Stewart wrote:
> > igloo:
> >> Hi all,
> >>
> >> We are planning to remove the -fvia-c way of compiling code
> >> (unregisterised compilers will continue to compile via C only, but
> >> registerised compilers will o
marlowsd:
>>>
>>> Simon Marlow has recently fixed FP performance for modern x86 chips in
>>> the native code generator in the HEAD. That was the last reason we know
>>> of to prefer via-C to the native code generators. But before we start
>>> the removal process, does anyone know of any other probl
Hi,
the things I am interested in are:
foldU f init .
mapU (\k -> array_1 !: (i,k) `combine` array_2 !: (k,j)) $
enumFromToU i j
where (!:) = fancy_index_op
with both `vector` and `uvector` (then D.V.fold etc).
Since ghc 6.12 there has been no significant difference in using either
backend. Th
On 14/02/2010 17:58, Don Stewart wrote:
igloo:
Hi all,
We are planning to remove the -fvia-c way of compiling code
(unregisterised compilers will continue to compile via C only, but
registerised compilers will only use the native code generator).
We'll probably deprecate -fvia-c in the 6.14 br
On Sun, Feb 14, 2010 at 5:51 PM, Ian Lynagh wrote:
>
> Hi all,
>
> We are planning to remove the -fvia-c way of compiling code
> (unregisterised compilers will continue to compile via C only, but
> registerised compilers will only use the native code generator).
> We'll probably deprecate -fvia-c
I thought GHC's own codegen didn't do any instruction reordering for the
pipeline. I guess that ends up not being much of an issue in practice?
On Sun, Feb 14, 2010 at 12:58 PM, Don Stewart wrote:
> igloo:
> >
> > Hi all,
> >
> > We are planning to remove the -fvia-c way of compiling code
> > (u
igloo:
>
> Hi all,
>
> We are planning to remove the -fvia-c way of compiling code
> (unregisterised compilers will continue to compile via C only, but
> registerised compilers will only use the native code generator).
> We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in
> 6.16
25 matches
Mail list logo
