Hugh Perkins wrote:
On 8/22/07, Twan van Laarhoven [EMAIL PROTECTED] wrote:
But Double is already quite badly behaved:
let x = 1e20
Prelude 1 + (x - x)
1.0
Prelude (1 + x) - x
0.0
E. Whilst that's understandable and unavoidable, that kindof
rings alarm bells for folds of
Hi
Its (==) isn't
reflexive (is it transitive? probably, at least if there aren't too many
optimizations, but floating-point transitive equality isn't very useful).
It's not even referentially transparent in all cases. a == b may fail
while the double's are in the high precision registers,
On 8/23/07, Neil Mitchell [EMAIL PROTECTED] wrote:
It's not even referentially transparent in all cases. a == b may fail
while the double's are in the high precision registers, and then
succeed later on in the program once they are truncated. I think you
have to specify -fexcess-precision with
| First of all, optimizing mod and div can not be done with PrelRules,
| because they are not primitives, quot and rem are.
Yes, you can do them with PrelRules! Check out PrelRules.builtinRules.
| Multiplication and division can become shifts:
|
| {-# RULES
|
| -- x * 2^n -- x `shiftL`
Hi
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
forall a b. fromInteger a * fromInteger b = fromInteger (a * b)
This is wrong, since the class function can do what it wants. Imagine:
instance Num String where
(+) = (++)
On Wed, Aug 22, 2007 at 09:04:11AM +0100, Simon Peyton-Jones wrote:
| First of all, optimizing mod and div can not be done with PrelRules,
| because they are not primitives, quot and rem are.
Yes, you can do them with PrelRules! Check out PrelRules.builtinRules.
| Multiplication and
| Something I've pondered is adding a more-expressive form of RULES which
| works using general pattern matching:
Yes, but it would need the rule-matcher in the Simplifier to be more
sophisticated. Have a look in specialise/Rules.lhs.
No need to be so ambitious; just moving towards what you
Simon Peyton-Jones wrote:
| Something I've pondered is adding a more-expressive form of RULES which
| works using general pattern matching:
Yes, but it would need the rule-matcher in the Simplifier to be more
sophisticated. Have a look in specialise/Rules.lhs.
No need to be so ambitious;
Neil Mitchell wrote:
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
forall a b. fromInteger a * fromInteger b = fromInteger (a * b)
This is wrong, since the class function can do what it wants. Imagine:
instance Num String where
Hi
If Num obeys ring axioms, fromInteger is a perfectly fine
ring-homomorphism. (It's also the first or second homomorphism taught.)
Does Int obey these axioms? I'm thinking that assuming properties
about things such as numbers is very likely to go wrong very quickly.
Monads you might be able
Neil Mitchell wrote:
If Num obeys ring axioms, fromInteger is a perfectly fine
ring-homomorphism. (It's also the first or second homomorphism taught.)
Does Int obey these axioms? I'm thinking that assuming properties
about things such as numbers is very likely to go wrong very quickly.
On Wed, Aug 22, 2007 at 06:36:15PM +0100, Neil Mitchell wrote:
Hi
If Num obeys ring axioms, fromInteger is a perfectly fine
ring-homomorphism. (It's also the first or second homomorphism taught.)
Does Int obey these axioms? I'm thinking that assuming properties
about things such as
Stefan O'Rear wrote:
On Wed, Aug 22, 2007 at 06:36:15PM +0100, Neil Mitchell wrote:
Hi
If Num obeys ring axioms, fromInteger is a perfectly fine
ring-homomorphism. (It's also the first or second homomorphism taught.)
Does Int obey these axioms? I'm thinking that assuming properties
about
Using the fromInteger (and fromRational) axioms should only *increase*
precission, I don't see how that is such a bad thing.
I think it's bad if the behaviour of your program depends on the
optimisation level.
On 22/08/07, Twan van Laarhoven [EMAIL PROTECTED] wrote:
Stefan O'Rear wrote:
On
On Thu, 2007-08-23 at 10:17 +1000, Donald Bruce Stewart wrote:
overdrigzed:
Using the fromInteger (and fromRational) axioms should only *increase*
precission, I don't see how that is such a bad thing.
I think it's bad if the behaviour of your program depends on the
optimisation
On 8/22/07, Twan van Laarhoven [EMAIL PROTECTED] wrote:
But Double is already quite badly behaved:
let x = 1e20
Prelude 1 + (x - x)
1.0
Prelude (1 + x) - x
0.0
E. Whilst that's understandable and unavoidable, that kindof
rings alarm bells for folds of Doubles in an automatic
On Mon, Aug 20, 2007 at 09:57:38PM +0100, Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength
reduction, or using shifts instead of multiplication. It's pretty
easy to add more: it's all done in a single module. Look at
primOpRules in the module PrelRules.
phil:
On Mon, Aug 20, 2007 at 09:57:38PM +0100, Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength
reduction, or using shifts instead of multiplication. It's pretty
easy to add more: it's all done in a single module. Look at
primOpRules in the module
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines of assembly for the main loop,
compared to about 10 from GHC. I suspect the speed difference is the
result of some heavy
On Tue, Aug 21, 2007 at 01:14:20PM +0100, Rodrigo Queiro wrote:
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines of assembly for the main loop,
compared to about 10 from GHC.
On Tue, Aug 21, 2007 at 05:25:49AM -0700, Stefan O'Rear wrote:
On Tue, Aug 21, 2007 at 01:14:20PM +0100, Rodrigo Queiro wrote:
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines
Don's reply didn't reach me for some reason, but pulling it out of the
previous response:
On 21/08/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
phil:
The generated assembler suggests (if I've read it correctly) that gcc
is spotting that it can replace the tail call with a jump in the C
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Currently, it's never worse. GHC's backend is about as good as GCC;
most of the optimiations it doesn't do are not possible for GCC because
of various lack-of-information problems (the stack pointer never aliases
the heap pointer, stuff like
Hi
Wait, you're saying that ghc can produce pure c-code, that doesnt
contain any assembly code, and that runs as fast as ghc code that does
contain assembly?
No. It can produce pure C code (unregistered), but to get high
performance it processes the output assembly afterwards (registered).
On Tue, Aug 21, 2007 at 09:39:32PM +0800, Hugh Perkins wrote:
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Currently, it's never worse. GHC's backend is about as good as GCC;
most of the optimiations it doesn't do are not possible for GCC because
of various lack-of-information
Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength reduction, or
using shifts instead of multiplication. It's pretty easy to add more: it's all
done in a single module. Look at primOpRules in the module PrelRules.
Patches welcome! But please also supply
| GHC does some constant folding, but little by way of strength
| reduction, or using shifts instead of multiplication. It's pretty easy
| to add more: it's all done in a single module. Look at primOpRules in
| the module PrelRules.
|
| Patches welcome! But please also supply test-suite
Simon Peyton-Jones wrote:
| GHC does some constant folding, but little by way of strength
| reduction, or using shifts instead of multiplication. It's pretty easy
| to add more: it's all done in a single module. Look at primOpRules in
| the module PrelRules.
|
| Patches welcome! But please
Isaac Dupree wrote:
Simon Peyton-Jones wrote:
...
No, constant folding is part of the compiler, I'm afraid, in the
module PrelRules.
Simon
_Constant_ folding is, but in GHC.Base there are rules like (unboxed)
multiplying by zero or one, or adding or subtracting zero, from an
unknown
On Aug 21, 2007, at 22:13 , Twan van Laarhoven wrote:
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
I don't think this will work, a and b have to be the same type.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL
Brandon S. Allbery KF8NH wrote:
On Aug 21, 2007, at 22:13 , Twan van Laarhoven wrote:
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
I don't think this will work, a and b have to be the same type.
They are of the same type,
Thank-you for the information. It was very useful. Couple of reactions FWIW:
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Sooo if I was feeling evil, could I take this c-code and pipe it
into something that turns it into C#???
Yes. You could do the same with the original
Stefan O'Rear wrote:
On Sun, Aug 19, 2007 at 12:53:07PM +0100, Andrew Coppin wrote:
Does GHC do stuff like converting (2*) into (shift 1) or converting x + x
into 2*x?
For a good time, compile some code which uses even or odd :: Int - Bool
using -O2 -fasm -ddump-asm... The compiler
On Mon, Aug 20, 2007 at 06:30:27PM +0100, Andrew Coppin wrote:
Stefan O'Rear wrote:
On Sun, Aug 19, 2007 at 12:53:07PM +0100, Andrew Coppin wrote:
Does GHC do stuff like converting (2*) into (shift 1) or converting x + x
into 2*x?
For a good time, compile some code which uses even or
the
correctness of the rules.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:haskell-cafe-
| [EMAIL PROTECTED] On Behalf Of Stefan O'Rear
| Sent: 19 August 2007 20:14
| To: Andrew Coppin
| Cc: haskell-cafe@haskell.org
| Subject: Re: [Haskell-cafe] GHC optimisations
Does GHC do stuff like converting (2*) into (shift 1) or converting x +
x into 2*x?
If I do x * sin 12, is GHC likely to compute sin 12 at compile-time?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 8/19/07, Andrew Coppin [EMAIL PROTECTED] wrote:
Does GHC do stuff like converting (2*) into (shift 1) or converting x +
x into 2*x?
Hmm, that's an interesting architecture where multiplication is
cheaper than addition :-)
If I do x * sin 12, is GHC likely to compute sin 12 at
On Sun, Aug 19, 2007 at 12:53:07PM +0100, Andrew Coppin wrote:
Does GHC do stuff like converting (2*) into (shift 1) or converting x + x
into 2*x?
For a good time, compile some code which uses even or odd :: Int - Bool
using -O2 -fasm -ddump-asm... The compiler *really* shouldn't be using
Does GHC do dead code elimination?
I observe that if you take a module and edit it so that some function is
now no longer exported or called by any exported function, the size of
the *.o file seems to go down. This suggests that dead code within a
single module is eliminated.
However... how
On Mon, Aug 13, 2007 at 07:05:03PM +0100, Andrew Coppin wrote:
Does GHC do dead code elimination?
Yes - all unused let-binders are removed.
I observe that if you take a module and edit it so that some function is
now no longer exported or called by any exported function, the size of the
Stefan O'Rear wrote:
On Mon, Aug 13, 2007 at 07:05:03PM +0100, Andrew Coppin wrote:
Does GHC do dead code elimination?
Yes - all unused let-binders are removed.
Not related to optimisation, but... is there some switch to warn you if
something gets removed? (Presumably this means
On Mon, Aug 13, 2007 at 07:35:31PM +0100, Andrew Coppin wrote:
Not related to optimisation, but... is there some switch to warn you if
something gets removed? (Presumably this means you forgot to export
something, or you haven't coded the bit that calls it yet or something.)
Stefan O'Rear wrote:
On Mon, Aug 13, 2007 at 07:35:31PM +0100, Andrew Coppin wrote:
(I once compiled a program that used the GHC API. The final binary was
several times larger than ghc.exe...)
GHC is a particularly bad case because what it does is determined by the
settings of a bunch
43 matches
Mail list logo
