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 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
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 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
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 Wed, Feb 17, 2010 at 6:19 AM, Simon Marlow marlo...@gmail.com 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?
FWIW, I
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; we
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)
movsd
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 like
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 before
: 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
Subject: Re: Removing/deprecating -fvia
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 Stewartd...@galois.com; glasgow-haskell-users@haskell.org
Subject: Re: Removing/deprecating -fvia-c
It seems to me
: scooter@gmail.com
Date: Wed, 17 Feb 2010 03:26:08
To: Don Stewartd...@galois.com; glasgow-haskell-users@haskell.org
Subject: Re: Removing/deprecating -fvia-c
It seems to me, in the absence of any other fallback, that the C
backend should stay around. Assume that one is porting to a new
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
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
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.
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 problems with the
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 only use the
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 of any other
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.
Simon Marlow has
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.
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 d...@galois.com wrote:
igloo:
Hi all,
We are planning to remove the -fvia-c way of compiling code
22 matches
Mail list logo
