Andrew Coppin wrote:
[snip]
Fact #1: I don't *know* of any other numerical integration algorithm.
(I've heard of RK4, but it's too complicated for me to understand.)
higher-order runge-kutta algorithms typically have high integration
accuracy, but may require multiple energy/force evaluations
| The source code has explicit monomorphic types all over it; I would
| expect GHC to be able to optimise out any method calls. (OTOH, I'm not a
| GHC expert... Simon? Don?)
Full monomorphisation is a whole-program optimisation and GHC isn't (yet) a
whole-program compiler. Overloaded functions
Simon Peyton-Jones wrote:
| The source code has explicit monomorphic types all over it; I would
| expect GHC to be able to optimise out any method calls. (OTOH, I'm not a
| GHC expert... Simon? Don?)
Full monomorphisation is a whole-program optimisation and GHC isn't (yet) a
whole-program
| What I'm trying to say is, I would have expected, say,
|
| resultant :: [Vector2] - Vector2
| resultant = sum
|
| to run faster than
|
| resultant = sum
|
| In the latter case, we have resultant :: (Num n) = [n] - n. I'm no
| expert, but I would expect that this requires a method lookup
| In the latter case, we have resultant :: (Num n) = [n] - n. I'm no
| expert, but I would expect that this requires a method lookup on each
| call, whereas with the more restrictive type I would expect the compiler
| to be able to just link directly to the correct method implementation.
| Am I
| Presumably changing it to resultant = foldl' (+) wouldn't help much either?
I think not.
| Seems to me there's always a tradeoff to be made between CPU time, RAM
| usage, and code size - if not other factors too. :-S But Haskell seems
| to be fairly unique in that (it looks like) it's possible
Simon Peyton-Jones wrote:
| I guess I was assuming that a function like sum is simple enough to
| get inlined at the call site - and hence possibly optimised at that
| site. Apparently not.
There is no reason in principle why not. It's just that GHC doesn't do it at
the moment.
On one
On May 7, 2007, at 8:50 , Andrew Coppin wrote:
recognisable expression involving GHC.Prim.+##. (Anybody know what
the difference between GHC.Prim.Double# and GHC.Float.Double is?)
This in spite of the fact that the definition is actually
Double# is an unboxed (raw) double; Double is
| Ah well, I doubt I'm going to come up with any new ideas for how to make
| my code go faster, but it's mildly entertaining wading through over 200
| KB of textual output trying to guess what it means.
Ha ha. You did say that you wanted to know what GHC *really* does :-)
Seriously, there is
Sorry, my mail client fooled me, too, so here it is again:
Andrew Coppin:
What I'm trying to say is, I would have expected, say,
resultant :: [Vector2] - Vector2
resultant = sum
to run faster than
resultant = sum
In the latter case, we have resultant :: (Num n) = [n] - n.
So... if I'm not actually using lazyness for anything, would it do
any harm to change Double to Double# in the Haskell source code? Or
is there some reason why this would be undesirable? (The source is
carefully constructed
Well, you'd need -fglasgow-exts for it to even compile. Other than
On 07/05/07, Andrew Coppin [EMAIL PROTECTED] wrote:
(Anybody know what the difference between GHC.Prim.Double#
and GHC.Float.Double is?)
It's the difference between unboxed and boxed types. A boxed type's
representation is in fact a pointer to the unboxed type (I think), so
that a Double would
On Mon, 2007-05-07 at 21:50 +0100, David House wrote:
On 07/05/07, Andrew Coppin [EMAIL PROTECTED] wrote:
(Anybody know what the difference between GHC.Prim.Double#
and GHC.Float.Double is?)
It's the difference between unboxed and boxed types. A boxed type's
representation is in fact a
On 07/05/07, David House [EMAIL PROTECTED] wrote:
represented by a null pointer. So such luck with unboxed types. So
working with unboxed types is quicker and consumes less memory, but
don't use them in any kind of high level because the lack of a _|_
will bite you sooner or later.
I hesitate
[EMAIL PROTECTED] wrote:
I appreciated the elegance of
overloading, the usage of Num classes, etc, which makes it more readable,
although somewhat slower.
The source code has explicit monomorphic types all over it; I would
expect GHC to be able to optimise out any method calls. (OTOH, I'm not
Andrew Coppin shares with us his Chaos program.
I confirm that on my HP laptop it was faster than 15 minutes, but
I won't speculate how to optimize it. I appreciated the elegance of
overloading, the usage of Num classes, etc, which makes it more readable,
although somewhat slower. Actually it
16 matches
Mail list logo
