> Simon Marlow wrote:
>> The biggest problem with doing this kind of thing is that in order to
>> revert a thunk to its unevaluated state,...
>
Shelby Moore wrote:
> I am suggesting the algorithm would apply only to unevaluated thunks...
>
> I understand you are implying hysteresis, because paging
On 03/11/2009, at 03:37, Simon Peyton-Jones wrote:
Roman, Manuel [ccing cvs-ghc for interest]
Consider this:
let xs = build g
in map (\y. ...(foldr k z xs)...) ys
The foldr/build rule doesn't fire, because in principle it might
take lots of work to construct the list 'xs'.
> ...Thus, an optimization minimization for the target audience.
Typo, "optimization" should be "opportunity cost".
> ...but an upper bound on physical memory and thus paging load.
I do not mean upper bound on paging load. I mean "thus impacting paging
load".
__
> On 31/10/2009 21:49, Shelby Moore wrote:
>> http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
>> Shelby Moore wrote:
>>> One possible runtime optimization to provide an upper bound for cache
>>> control, might be to not cache thunks when the runtime computation time
>>> times numb
Build description = HEAD on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Mon Nov 2 19:00:01 GMT 2009.
***
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Mon Nov 2 18:00:01 GMT 2009.
checking out
Roman, Manuel [ccing cvs-ghc for interest]
Consider this:
let xs = build g
in map (\y. ...(foldr k z xs)...) ys
The foldr/build rule doesn't fire, because in principle it might take lots of
work to construct the list 'xs'. By doing it outside the 'let' we share all
the computa
On 31/10/2009 21:49, Shelby Moore wrote:
http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Shelby Moore wrote:
One possible runtime optimization to provide an upper bound for cache
control, might be to not cache thunks when the runtime computation time
times number of cache hits,
On 30/10/2009 08:31, Manuel M T Chakravarty wrote:
I understand that there were good reasons to implement a custom dynamic
linker in Linker.c for ghci at the time. However, I just experienced
first-hand that this design has a significant cost. Linking is a tricky
platform-dependent business. It's
On 28/10/2009 19:59, Ian Lynagh wrote:
Wed Oct 28 10:54:21 PDT 2009 Ian Lynagh
* Don't use threads on Windows
It seems to cause some sort of deadlock
M ./driver/runtests.py -17 +22
M ./mk/test.mk +6
I tried to look into this once. As far as I could tell, the deadlock
occurre
Ian
What's the deal with LazyUniqFM? It is imported all over the place -- but
actually, UniqFM is lazy. Relevant patches are below (ages ago).
Currently I think we may be adding a redundant 'Lazy' wrapper around every
element in a UniqFM, because many things that looks as if they are called
I have no idea what is wrong, but if you add "-v" to the ghc command line
you'll see exactly what flags it is giving to the C compiler, and that might
help. You can also keep intermediate files so you can see them later
http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html
12 matches
Mail list logo
