Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Hi all,
[Hoping it's not too late.]
During my work on parallelising 'ghc --make' [1] I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any parallel build tool built on top of 'ghc -c' will be significantly
handicapped [2]. As far as I understand, this is mainly due to the
effects of interface file caching - 'ghc --make' only needs to parse
and load them once. One potential improvement (suggested by Duncan
Coutts [3]) is to produce whole-package interface files and load them
in using mmap().
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
[1] https://github.com/23Skidoo/ghc-parmake
[2] https://gist.github.com/1360470
[3]
http://www.reddit.com/r/haskell/comments/qwj5j/the_cabal_of_my_dreams/c41a5gx
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential ways to bring 'ghc -c' performance up to par with 'ghc --make'? I implemented a ghc server that runs several persistent ghcs, and distributes compiles among them. It seemed to work, but the speed gains weren't what I'd hoped for. But perhaps I was doing something dumb that hurt performance. I'd be happy to upload the source if you're interested. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What do the following numbers mean?
Dear all, I ran a small example program, and this is what I got from using the -s flag: 486,550,118,368 bytes allocated in the heap 323,749,418,440 bytes copied during GC 1,842,979,344 bytes maximum residency (219 sample(s)) 204,653,688 bytes maximum slop 4451 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 924208 collections, 0 parallel, 1861.17s, 1866.05s elapsed Generation 1: 219 collections, 0 parallel, 283.44s, 284.01s elapsed INIT time0.00s ( 0.00s elapsed) MUT time 740.61s (745.45s elapsed) GCtime 2144.61s (2150.06s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 2885.23s (2895.51s elapsed) %GC time 74.3% (74.3% elapsed) Alloc rate656,953,176 bytes per MUT second Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this information in the docs anywhere, but I may have missed it. best, Jur ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. On Sun, Apr 1, 2012 at 7:10 PM, Christopher Done chrisd...@googlemail.comwrote: I actually read the first couple paragraphs and thought “sounds interesting I'll read it later”. After reading it properly, I lol'd. After some initial feedback, I'm going to create a page for the Homotopy Extensional Records Proposal (HERP) on trac. There are really only a few remaining questions. 1) Having introduced homotopies, why not go all the way and introduce dependent records? In fact, are HERP and Dependent Extensional Records Proposal (DERP) already isomorphic? My suspicion is that HERP is isomorphic, but DERP is not. ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestanogullari ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
On 2 April 2012 14:41, Michael Snoyman mich...@snoyman.com wrote: import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real. (This output is not a joke. But run this program again to be sure.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install version selection
Thanks, that was a rather curious problem then. With more version annotations, hackage compiled everything. Thanks for for testing! Gruss, Christian * Albert Y. C. Lai tre...@vex.net [31.03.2012 03:58]: On 12-03-30 06:37 PM, Christian Höner zu Siederdissen wrote: I fail to remember or re-google the package version selection for cabal, if no version constraints are given. If I depend on iteratee, and there are no constraints, does it take the lowest version? It takes the highest version. To verify, I fetched RNAFold.cabal of 1.99.1.0 and tried: cabal install --dry-run Its answer: Resolving dependencies... In order, the following would be installed (use -v for more details): ListLike-3.1.4 MonadCatchIO-transformers-0.2.2.3 OneTuple-0.2.1 PrimitiveArray-0.2.1.1 ADPfusion-0.0.1.0 bytestring-lexing-0.4.0 cmdargs-0.9.5 csv-0.1.2 file-embed-0.0.4.1 iteratee-0.8.8.1 ... It chooses the newest iteratee alright. I don't know what is going on with hackage's build bot. And I can't control it anyway. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users pgpKciJD4zPci.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
I for one think this would make a good GSoC project. Make sure you get your application in in time though. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] A Modest Records Proposal
On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman mich...@snoyman.com wrote: On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari alpmes...@gmail.com wrote: Lesson learned: for next year, write a Haskell program that tells if a given -cafe thread or reddit discussion is a April Fool's joke or not. import Data.Time main = do now - getCurrentTime let (_, month, day) = toGregorian $ utctDay now putStrLn $ if month == 4 day == 1 then It's a joke else It's real My strategy next year will be to not read any email on the 1st. I'll just wait until the 2nd to read it all. Foolproof! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: A Modest Records Proposal
ROTFL!
Ben
Gershom B wrote:
The records discussion has been really complicated and confusing. But
I have a suggestion that should provide a great deal of power to
records, while being mostly[1] backwards-compatible with Haskell 2010.
Consider this example:
data A a = A{a:a, aa::a, aaa :: a - A (a - a)}
data B a = B{aaa :: a - A (a - a), a :: A}
Now what is the type of this?
a a aa = a{a = a, aaa = aa}
Using standard Haskell typeclasses this is a difficult question to
answer. The types of for A and B do not unify in an obvious way.
However, while they are intensionally quite distinct, they unify
trivially extensionally. The obvious thing to do is then to extend the
type system with extensional equality on record functions.
Back when Haskell was invented, extensional equality was thought to be
hard. But purity was thought to be hard too, and so were Monads. Now,
we know that function existentionality is easy. In fact, if we add the
Univalence Axiom to GHC[2], then this is enough to get function
existensionality. This is a well-known result of Homotopy Type
Theory[3], which is a well-explored approach that has existed for at
least a few years and produced more than one paper[4]. Homotopy Type
Theory is so sound and well understood that it has even been
formalized in Coq.
Once we extend GHC with homotopies, it turns out that records reduce
to mere syntactic sugar, and there is a natural proof of their
soundness (Appendix A). Furthermore, there is a canonical projection
for any group of fields (Appendix B). Even better, we can make .
into the identity path operator, unifying its uses in composition and
projection. In fact, with extended (parenthesis-free) section rules,
. can also be used to terminate expressions, making Haskell friendly
not only to programmers coming from Java, but also to those coming
from Prolog!
After some initial feedback, I'm going to create a page for the
Homotopy Extensional Records Proposal (HERP) on trac. There are really
only a few remaining questions. 1) Having introduced homotopies, why
not go all the way and introduce dependent records? In fact, are HERP
and Dependent Extensional Records Proposal (DERP) already isomorphic?
My suspicion is that HERP is isomorphic, but DERP is not. However, I
can only get away with my proof using Scott-free semantics. 2) Which
trac should I post this too? Given how well understood homotopy type
theory is, I'm tempted to bypass GHC entirely and propose this for
haskell-prime. 3) What syntax should we use to represent homotopies?
See extend discussion in Appendix C.
HTH HAND,
Gershom
[1] To be precise, 100% of Haskell 2010 programs should, usually, be
able to be rewritten to work with this proposal with a minimal set of
changes[1a].
[1a] A minimal set of changes is defined as the smallest set of
changes necessary to make to a Haskell 2010 program such that it works
with this proposal. We can arrive at these changes by the following
procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3)
are we done? If not, make another change.
[1b] To do this constructively, we need an order. I suggest the lo
mein, since noodles give rise to a free soda.
[2] I haven't looked at the source, but I would suggest putting it in
the file Axioms.hs.
[3] http://homotopytypetheory.org/
[4] http://arxiv.org/
*Appendix A: A Natural Proof of the Soundness of HERP
Take the category of all types in HERP, with functions as morphisms.
Call it C. Take the category of all sound expressions in HERP, with
functions as morphisms. Call it D. Define a full functor from C to D.
Call it F. Define a faithful functor on C and D. Call it G. Draw the
following diagram.
F(X)F(Y)
| |
| |
| |
G(X)G(Y)
Define the arrows such that everything commutes.
*Appendix B: Construction of a Canonical Projection for Any Group of
Fields.
1) Take the fields along the homotopy to an n-ball.
2) Pack them loosely with newspaper and gunpowder.
3) Project them from a cannon.
In an intuitionistic logic, the following simplification is possible:
1) Use your intuition.
*Appendix C: Homotopy Syntax
Given that we already are using the full unicode set, what syntax
should we use to distinguish paths and homotopies? At first, I thought
we could avoid providing any syntax for homotopies at all. Haskell is
a language with type inference, so we should just be able to infer
paths and homotopies behind the scenes by adding homotopies to the
type system. That's a very nice answer in theory. But in the real
world, when we're writing code that solves actual problems,
theoretical niceties break down. What if a user wants to use a
nonstandard homotopy?
Why should we stop them just because we're too lazy to come up with a
good syntax? I then realized that we keep running out of syntax
because we've limited
Re: What do the following numbers mean?
On 02/04/2012, at 10:10 PM, Jurriaan Hage wrote: Can anyone tell me what the exact difference is between 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB total memory in use (0 MB lost due to fragmentation) I could not find this information in the docs anywhere, but I may have missed it. The maximum residency is the peak amount of live data in the heap. The total memory in use is the peak amount that the GHC runtime requested from the operating system. Because the runtime system ensures that the heap is always bigger than the size of the live data, the second number will be larger. The maximum residency is determined by performing a garbage collection, which traces out the graph of live objects. This means that the number reported may not be the exact peak memory use of the program, because objects could be allocated and then become unreachable before the next sample. If you want a more accurate number then increase the frequency of the heap sampling with the -isec RTS flag. Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
