Mitsutoshi Aoe | 29 Apr 06:37 2015
Picon

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?

Thanks,

Mitsutoshi
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Dominic Steinitz | 13 Apr 15:05 2015

Re: SIMD

Hi Geoff,

Thanks for the update. I found this https://ghc.haskell.org/trac/ghc/blog/weekly20141020

  • 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  https://ghc.haskell.org/trac/ghc/wiki/SIMD 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 https://ghc.haskell.org/trac/ghc/ticket/10229) 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> cs.drexel.edu> 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.

Geoff

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.



Simon



*From:*Glasgow-haskell-users
[mailto:glasgow-haskell-users-bounces <at> haskell.org] *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: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get



   ~ $ git clone -b simd http://git.haskell.org/ghc.git
   <http://git.haskell.org/ghc.git>

   Cloning into 'ghc'...

   fatal: Remote branch simd not found in upstream origin



Dominic Steinitz

dominic <at> steinitz.org <mailto:dominic <at> steinitz.org>

http://idontgetoutmuch.wordpress.com

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Dominic Steinitz | 11 Apr 18:44 2015

SIMD

What’s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD but I get

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
acrisciu | 9 Apr 12:51 2015
Picon

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

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

acrisciu <at> gmail.com says you're a friend

I would like to add you as a friend

Accept
Decline

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

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Jeremy | 6 Apr 16:35 2015
Picon

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: http://haskell.1045720.n5.nabble.com/skip-hpc-during-build-tp5768327.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Jeremy | 6 Apr 16:34 2015
Picon

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
all?

--
View this message in context: http://haskell.1045720.n5.nabble.com/runghc-and-GhcWithInterpreter-tp5768326.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
Mark Wotton | 3 Apr 07:05 2015
Picon

immortal profiling

https://ghc.haskell.org/trac/ghc/ticket/10235#ticket

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?

cheers
mark
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Jan Stolarek | 1 Apr 14:26 2015
Picon

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.

Janek

---
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> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Jeremy | 1 Apr 11:30 2015
Picon

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-1.18.1.5.a
17M     HSCabal-1.18.1.5.o

whereas 7.10 balloons to

23M     HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o
53M     libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a

--
View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
John Wiegley | 31 Mar 15:18 2015

Re: Welcome, and getting started

>>>>> Simon Marlow <marlowsd <at> gmail.com> 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:

    https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault

John
John Wiegley | 31 Mar 15:21 2015

Re: Welcome, and getting started

>>>>> Neil Mitchell <ndmitchell <at> gmail.com> 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 http://www.vex.net/~trebla/haskell/so.xhtml.

John

Gmane