Mitsutoshi Aoe | 29 Apr 06:37 2015

Looking for retainers of PINNED objects

Hi all,

I'm profiling a fairly large program which seems to have a space leak. The heap profiling (-hc) shows that PINNED objects are accumulated over time. In order to check the retainers of the objects, I ran the retainer profiling. Unfortunately it didn't output anything with -hr -hcPINNED. Also, this is just a guess though, the retainer profiling without any filters (I mean just -hr) doesn't seem to include PINNED objects at all.

Is there a way to check what retains the PINNED objects?


Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Dominic Steinitz | 13 Apr 15:05 2015


Hi Geoff,

Thanks for the update. I found this

  • Geoff Mainland stepped up and fixed Data Parallel Haskell to work with a new version of vector and GHC. Austin had disabled DPH a few weeks prior due to its difficulty to upgrade, and divergent source trees. With 7.10, GHC will hopefully ship a more modern vector and dph to boot.

From what you say this has been superseded?

Also seems that this page should be updated and if I knew what it should say I would volunteer to update it.

A bit of background on why I am asking these questions: I am working on a Monte Carlo simulation and performance is a key issue. We are using parallelisation to good effect (after some interesting issues with thread affinity but I am trying to understand what other options might be available to speed things up.

On 13 Apr 2015, at 13:37, Geoffrey Mainland <mainland <at>> wrote:

SIMD support was merged to HEAD before the 7.8 release, so any version
of GHC after 7.8 has SIMD support built-in.

If you want a branch that compiles with DPH, I'm afraid you are out of
luck. DPH no longer builds at all, and I believe Austin actually deleted
the simd branch mentioned on the Wiki.


On 04/13/2015 02:54 AM, Simon Peyton Jones wrote:

Geoff Mainland is the originator of the SIMD instruction set work. 
Let’s see what he says.


[mailto:glasgow-haskell-users-bounces <at>] *On Behalf Of
*Dominic Steinitz
*Sent:* 11 April 2015 17:45
*To:* GHC users
*Subject:* SIMD

What’s the story with this? I tried to follow the instructions
here: but I get

   ~ $ git clone -b simd

   Cloning into 'ghc'...

   fatal: Remote branch simd not found in upstream origin

Dominic Steinitz

dominic <at> <mailto:dominic <at>>

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Dominic Steinitz | 11 Apr 18:44 2015


What’s the story with this? I tried to follow the instructions here: but I get

~ $ git clone -b simd
Cloning into 'ghc'...
fatal: Remote branch simd not found in upstream origin

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
acrisciu | 9 Apr 12:51 2015

acrisciu <at> has indicated you're a friend. Accept?

Click here to discover acrisciu <at>'s favorite content!

acrisciu <at> says you're a friend

I would like to add you as a friend


Connecting with acrisciu <at> helps you discover great content they recommend :)

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Jeremy | 6 Apr 16:35 2015

skip hpc during build

I'm deleting hpc after building ghc for a vm to save space. Is there an easy
way to skip building it in the first place?

View this message in context:
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Jeremy | 6 Apr 16:34 2015

runghc and GhcWithInterpreter

I've built GHC with GhcWithInterpreter = NO. runghc is built and installed,
but errors out with "not built for interactive use".

Is runghc supposed to work with such a build? If not, why is it built at

View this message in context:
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Mark Wotton | 3 Apr 07:05 2015

immortal profiling

Would be really useful to be able to profile code without dying, especially in the context of a long-lived server. Am I missing something that would allow me to do this?

Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Jan Stolarek | 1 Apr 14:26 2015

Increased memory usage with GHC 7.10.1

Forall hi,

I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and 
this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored 
inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC 
taking up all of available memory.

With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story 
is that when I do a clean build of Idris GHC consumes all of memory when compiling that module 
and I have to kill the build. But when I restart the build after killing GHC the module is 
compiled using a reasonable amount of memory and within reasonable time.

With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing 
the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which 
works without problems though the mentioned module still requires a lot of memory) and alter my 
setup so that Agda binary is not stored inside GHC sandbox.

I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data 
that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases?

All of the above happened on 64bit Debian Wheezy with 2GB of RAM.


Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at>
Jeremy | 1 Apr 11:30 2015

Binary bloat in 7.10

Why do the 7.10 libraries take up so much more space than 7.8? For example,
using the same build options and strip --strip-unneeded, 7.8 leaves me with

15M     libHSCabal-
17M     HSCabal-

whereas 7.10 balloons to

23M     HSCabal-
53M     libHSCabal-

View this message in context:
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
John Wiegley | 31 Mar 15:18 2015

Re: Welcome, and getting started

>>>>> Simon Marlow <marlowsd <at>> writes:

> Perhaps some of this would be solved by switching to -dynamic by default for
> everything, but there are performance issues with that.

Some of these performance issues are documented at:

John Wiegley | 31 Mar 15:21 2015

Re: Welcome, and getting started

>>>>> Neil Mitchell <ndmitchell <at>> writes:

> Is the ability to generate dlls with both shared and non-shared RTS's a
> feature of dynamic linking? At Standard Chartered we build non-shared
> (static) dlls on Windows 32bit and shared-RTS dlls/sos on Linux 64bit. Both
> are essential to us.

I believe for your scenario you would use:

    Windows: -shared
    Linux:   -dynamic -shared

This is from