Small optimisation question
Suppose I write something like this: foo :: [Int] foo = concat (replicate 4 [4,7,2,9]) The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here? Obviously, once somebody has completely examined the contents of "foo", after that point it won't matter either way. I'm just curiose. Concatinating some strings is cheap; I sometimes write constructs like the above using much more expensive operations. (Expensive in time; the space taken up by the result isn't that great.)
On Sat, Nov 17, 2007 at 04:01:34PM +0000, Andrew Coppin wrote:
Suppose I write something like this:
foo :: [Int] foo = concat (replicate 4 [4,7,2,9])
The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here?
Obviously, once somebody has completely examined the contents of "foo", after that point it won't matter either way. I'm just curiose. Concatinating some strings is cheap; I sometimes write constructs like the above using much more expensive operations. (Expensive in time; the space taken up by the result isn't that great.)
The compiler will generate calls to concat and replicate. Stefan, who is pretty sure he has a proposal for generalized folding pragmas Stefan
Stefan O'Rear wrote:
On Sat, Nov 17, 2007 at 04:01:34PM +0000, Andrew Coppin wrote:
Suppose I write something like this:
foo :: [Int] foo = concat (replicate 4 [4,7,2,9])
The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here?
The compiler will generate calls to concat and replicate.
OK. I presume this is due to the fact that the result of executing an expression at compile-time could be arbitrarily large? Are there any buttons that can be twiddled to control this behaviour? For that matter, when I say "[4,7,2,9]", what does that compile into? Some data structures in memory? Or code to actually build said structures?
On Sat, Nov 17, 2007 at 04:10:58PM +0000, Andrew Coppin wrote:
Stefan O'Rear wrote:
On Sat, Nov 17, 2007 at 04:01:34PM +0000, Andrew Coppin wrote:
Suppose I write something like this:
foo :: [Int] foo = concat (replicate 4 [4,7,2,9])
The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here?
The compiler will generate calls to concat and replicate.
OK. I presume this is due to the fact that the result of executing an expression at compile-time could be arbitrarily large?
Yes, and it's not even guaranteed to terminate.
Are there any buttons that can be twiddled to control this behaviour?
Not that I'm aware of, though you can hack something with RULEs probably.
For that matter, when I say "[4,7,2,9]", what does that compile into? Some data structures in memory? Or code to actually build said structures?
Both. A curious feature of the STG machine is that constructor thunks and evaluated data are represented identically in memory. Stefan
Stefan O'Rear wrote:
On Sat, Nov 17, 2007 at 04:10:58PM +0000, Andrew Coppin wrote:
OK. I presume this is due to the fact that the result of executing an expression at compile-time could be arbitrarily large?
Yes, and it's not even guaranteed to terminate.
That would be "arbitrarily large", yes. ;-)
Are there any buttons that can be twiddled to control this behaviour?
Not that I'm aware of, though you can hack something with RULEs probably.
I was just wondering whether there was some way to say "please unravel this expression until the result is X units big" or something. Oh well. (I'm sure Template Haskell could do it if you wanted it that badly... or just write a small Haskell program that writes a Haskell program. Eeps!)
For that matter, when I say "[4,7,2,9]", what does that compile into? Some data structures in memory? Or code to actually build said structures?
Both. A curious feature of the STG machine is that constructor thunks and evaluated data are represented identically in memory.
Ooo... As per the Lambdacats "Boxed cat has a uniform representation"? Well, presumably the guys who designed STG did it this way for a really good reason, and they know far more than me, so... ;-)
On Sat, Nov 17, 2007 at 04:31:33PM +0000, Andrew Coppin wrote:
Both. A curious feature of the STG machine is that constructor thunks and evaluated data are represented identically in memory.
Ooo... As per the Lambdacats "Boxed cat has a uniform representation"?
Well, presumably the guys who designed STG did it this way for a really good reason, and they know far more than me, so... ;-)
The STG-machine was brilliant when it was designed, but times have changed. In particular, indirect jumps are no longer cheap. Pointer tagging has allowed STG to hobble into the 21st century, but really the air is ripe for a new abstract machine. Stefan
Stefan O'Rear wrote:
On Sat, Nov 17, 2007 at 04:31:33PM +0000, Andrew Coppin wrote:
Well, presumably the guys who designed STG did it this way for a really good reason, and they know far more than me, so... ;-)
The STG-machine was brilliant when it was designed, but times have changed. In particular, indirect jumps are no longer cheap. Pointer tagging has allowed STG to hobble into the 21st century, but really the air is ripe for a new abstract machine.
You volunteering? 0;-)
On Nov 17, 2007, at 11:26 AM, Stefan O'Rear wrote:
The STG-machine was brilliant when it was designed, but times have changed. In particular, indirect jumps are no longer cheap. Pointer tagging has allowed STG to hobble into the 21st century, but really the air is ripe for a new abstract machine.
Do you know of any candidates? - Jake
On Sat, Nov 17, 2007 at 12:39:14PM -0600, Jake McArthur wrote:
On Nov 17, 2007, at 11:26 AM, Stefan O'Rear wrote:
The STG-machine was brilliant when it was designed, but times have changed. In particular, indirect jumps are no longer cheap. Pointer tagging has allowed STG to hobble into the 21st century, but really the air is ripe for a new abstract machine.
Do you know of any candidates?
Hahaha - no. (Do ask John Meacham though - he keeps *saying* he has a new AM...) Stefan
Stefan O'Rear writes:
Jake McArthur wrote:
On Nov 17, 2007, at 11:26 AM, Stefan O'Rear wrote:
The STG-machine was brilliant when it was designed, but times have changed. ... really the air is ripe for a new abstract machine.
Do you know of any candidates? Hahaha - no. (Do ask John Meacham though - he keeps *saying* he has a new AM...) Stefan
I think that many people work on that, and the STG creators in particular. SPJ regularly emits some papers on parallelisation. If I am not mistaken, the paper of both Simons and Tim Harris, about Haskell on a shared memory multiprocessor, has more than two years. Some people speculate about making Haskell on the Clean G-machine, others think about Java-like architectures... The world *IS* steadily progressing, no need to hahaha-dynamite an open door saying that "the air is ripe...". Jerzy Karczmarczuk
On Nov 17, 2007 1:39 PM, Jake McArthur
On Nov 17, 2007, at 11:26 AM, Stefan O'Rear wrote:
The STG-machine was brilliant when it was designed, but times have changed. In particular, indirect jumps are no longer cheap. Pointer tagging has allowed STG to hobble into the 21st century, but really the air is ripe for a new abstract machine.
Do you know of any candidates?
There's Boquist's GRIN. I believe JHC uses a variant of it.
http://www.cs.chalmers.se/~boquist/phd/
--
Dave Menendez
There's no "the compiler". :) There are many compilers. I don't know of
any that evaluate those expressions at compile time, but it's certainly not
forbidden. Nor would it be exceedingly hard to implement.
But it's not too bad to do it at run time either, because it will (most
likely) only be evaluated once at run time.
-- Lennart
On Nov 17, 2007 4:01 PM, Andrew Coppin
Suppose I write something like this:
foo :: [Int] foo = concat (replicate 4 [4,7,2,9])
The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here?
Obviously, once somebody has completely examined the contents of "foo", after that point it won't matter either way. I'm just curiose. Concatinating some strings is cheap; I sometimes write constructs like the above using much more expensive operations. (Expensive in time; the space taken up by the result isn't that great.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 11/17/07, Andrew Coppin
Suppose I write something like this:
foo :: [Int] foo = concat (replicate 4 [4,7,2,9])
The value of "foo" is completely determined at compile-time. So, will the compiler generate calls to concat and replicate, or will it just insert a large list constant here?
To add to what others have said, you might want to read the Simons' paper "Secrets of the Glasgow Haskell Compiler Inliner": http://research.microsoft.com/~simonpj/Papers/inlining/ It's pretty accessible, and talks about the various knobs that can be twiddled in order to influence the black art of inlining. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "'There are no atheists in foxholes' isn't an argument against atheism, it's an argument against foxholes." -- James Morrow
participants (7)
-
Andrew Coppin -
David Menendez -
Jake McArthur -
jerzy.karczmarczuk＠info.unicaen.fr -
Lennart Augustsson -
Stefan O'Rear -
Tim Chevalier