The bottleneck for building on my multi-core machine is ld, which spends a considerable time consuming 100% of one core
after ghc has finished generating object files. Moreover, GHC is largely IO bound, while ld is CPU bound; incremental
linking would enable the two tasks to be performed
On 7 December 2010 08:54, John Smith volderm...@hotmail.com wrote:
Gold in an incremental and multi-threaded linker, but can only output ELF
(not Windows). Is there a cross-platform solution suitable for GHC?
Not AFAIK. One thing that would probably help a lot is if
GHC-generated code stopped
Hello John,
Tuesday, December 7, 2010, 11:54:22 AM, you wrote:
The bottleneck for building on my multi-core machine is ld, which
afaik, there was some alternative linker, at least for linux systems
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
On Tue, Dec 7, 2010 at 12:00 PM, Bulat Ziganshin
bulat.zigans...@gmail.com wrote:
Hello John,
Tuesday, December 7, 2010, 11:54:22 AM, you wrote:
The bottleneck for building on my multi-core machine is ld, which
afaik, there was some alternative linker, at least for linux systems
gold,
[Simon] might be worth adding to the docs (title: linking
times on Suns,
Sun's ld vs GNU ld; explanation: see previous mails)?
See
http://www.haskell.org/ghc/docs/latest/html/users_guide/faq.html
specifically the last question.
Cheers,
Simon
of binutils (up to and including 2.13) are reported to have
problems on Solaris, so don't throw away Sun's tools, but it
looks as if our case is now closed (and incremental linking
isn't an issue anymore with these new link times!-)
Thanks for the helpful feedback, and Good Luck
Hi Hal,
How did you get ghc to use gld when doing --make instead of standard
ld? I'm having the exact same problem you were and I'd love to make it
work faster.
[Simon] might be worth adding to the docs (title: linking times on Suns,
Sun's ld vs GNU ld; explanation: see
tools, but it
looks as if our case is now closed (and incremental linking
isn't an issue anymore with these new link times!-)
Thanks for the helpful feedback, and Good Luck with the
other suspiciously slow systems!
Claus
(*) a little stumbling block here: gcc refers to PATH only *after*
perusing
I too am getting link times in the several minutes range for
my modestly
sized project, I am on a standalone dual-cpu redhat linux box with
5.04.1 (no nfs, no nuttin')
the project is available at
http://repetae.net/john/computer/ginsu/
I think there is definatly something fishy going
chasing takes a lot of time
- Suns (?): linking takes too long
will report again if we get better news..
Claus
PS. if we get linking times down to what seems possible, incremental
linking would no longer be urgent - we'll see..
___
Glasgow-haskell
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
Hmm, I've never heard of linking being a bottleneck. Even GHC itself
Hmm, I've never heard of linking being a bottleneck. Even GHC itself
links in about 3-4 seconds here. One common problem is that linking on
a network filesystem takes a *lot* longer than linking objects from a
local disk. It's always a good idea to keep the build tree on the local
disk,
Unfortunately, we're not talking seconds, but coffee-breaks of
linking times on our Sun (yes, the stuff is in the range of a large
compiler - we're fortunate enough to be able to build on rather
substantial third-party packages, think haskell-in-haskell frontend
distributed over unusually
On Wed, Nov 27, 2002 at 09:50:56AM -, Simon Marlow wrote:
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
Hmm,
On Wed, Nov 27, 2002 at 09:50:56AM -, Simon Marlow wrote:
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
Hmm, I've never heard of linking being a bottleneck. Even GHC itself
More fun with Haskell-in-the-large: linking time has become the
main bottleneck in our development cycle. The standard solution
would be to use an incremental linker, but it seems that gnu does
not yet support this:-|
Hmm, I've never heard of linking being a bottleneck. Even
On Wed, 27 Nov 2002 15:20:44 -
Simon Marlow [EMAIL PROTECTED] wrote:
The runtime loader stuff I'm working on[1] takes around 10
seconds to compile ... and 3 minutes to link it with libHSbase
and libHSrts. (This is on a 500MHz PIII). Linking is a huge
bottleneck once you start
I too am getting link times in the several minutes range for my modestly
sized project, I am on a standalone dual-cpu redhat linux box with
5.04.1 (no nfs, no nuttin')
the project is available at
http://repetae.net/john/computer/ginsu/
I think there is definatly something fishy going on. I don't
On Wed, Nov 27, 2002 at 03:55:54PM -, Simon Marlow wrote:
Those who experience long link times (longer than a few seconds), please
reply with your
- platform / OS version
- versions of relevent things (GHC, GCC, binutils).
- time to link 'main = print hello'.
Platform: Debian
20 matches
Mail list logo
