Re: Overlapping and incoherent instances
This is great! It's nice to see something finer grain.
We'd of course like to bring Safe Haskell into the picture though! Our
concern with the new design as it stands is the OVERLAPS flag. We'd
prefer it to be eliminated in favor of requiring developers specify
both OVERLAPPABLE and OVERLAPS if that truly is their intention.
# Why?
## Long Version
https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell/NewOverlappingInstances#NewOverlappingInstances--a.k.aInstanceSpecificPragmas
## Short Version (kind-of)
The security implications of OVERLAPPABLE vs. OVERLAPPING are fairly
different. Remember, in Safe Haskell we apply a policy of only
allowing instances from a module M compiled with `-XSafe` to overlap
other instances from module M. If it overlaps (and is the most
specific overlap) instances from modules other than M then we don't
allow this to succeed. This is done to ensure that untrusted code
compiled with `-XSafe` can't alter the behavior of existing code, some
of which may be part of the TCB and security critical.
Brining the new finer grained pragmas into the story we get the following:
* OVERLAPPABLE is the programmer communicating that they can be
overlapped, an open instance if you will. We want to relax the above
restriction and allow instances from `-XSafe` modules to overlap
instances from their own module AND instances declared OVERLAPPABLE
that reside in any module.
* OVERLAPPING is the programming simply declaring they may overlap
less specific instances. We want to keep the above restriction for
these instances. That is, a instance I1 from a `-XSafe` module M won't
be able to overlap as the most specific instance, a instance I2 from
another module if I2 is marked as OVERLAPPING.
This distinction enables new encodings in Safe Haskell by allowing
security library authors to distinguish how untrusted code can overlap
their instances. In some way giving them open vs closed instances.
This distinction is subtle and important. Having a pragma OVERLAPS
that implies both glosses over this and will encourage developers to
use this without much thought.
## Safe Inference
We can also safely infer a module that only has OVERLAPPABLE instances
as safe, while ones that contain OVERLAPPING or OVERLAPS instances
must be regarded as unsafe since there is a difference in semantics of
these pragmas under Safe vs Unsafe.
So we also have an advantage if developers are more specific about
what they want, than just defaulting to OVERLAPS.
Cheers,
David
On 29 July 2014 02:11, Simon Peyton Jones simo...@microsoft.com wrote:
Friends
One of GHC’s more widely-used features is overlapping (and sometimes
incoherent) instances. The user-manual documentation is here.
The use of overlapping/incoherent instances is controlled by LANGUAGE
pragmas: OverlappingInstances and IncoherentInstances respectively.
However the overlap/incoherent-ness is a property of the *instance
declaration* itself, and has been for a long time. Using LANGUAGE
OverlappingInstances simply sets the “I am an overlapping instance” flag for
every instance declaration in that module.
This is a Big Hammer. It give no clue about *which* particular instances
the programmer is expecting to be overlapped, nor which are doing the
overlapping.It brutally applies to every instance in the module.
Moreover, when looking at an instance declaration, there is no nearby clue
that it might be overlapped. The clue might be in the command line that
compiles that module!
Iavor has recently implemented per-instance-declaration pragmas, so you can
say
instance {-# OVERLAPPABLE #-} Show a = Show [a] where …
instance {-# OVERLAPPING #-} Show [Char] where …
This is much more precise (it affects only those specific instances) and it
is much clearer (you see it when you see the instance declaration).
This new feature will be in GHC 7.10 and I’m sure you will be happy about
that. But I propose also to deprecate the LANGUAGE pragmas
OverlappingInstances and IncoherentInstances, as way to encourage everyone
to use the new feature instead of the old big hammer. The old LANGUAGE
pragmas will continue to work, of course, for at least another complete
release cycle. We could make that two cycles if it was helpful.
However, if you want deprecation-free libraries, it will entail a wave of
library updates.
This email is just to warn you, and to let you yell if you think this is a
bad idea. It would actually not be difficult to retain the old LANGUAGE
pragmas indefinitely – it just seems wrong not to actively push authors in
the right direction.
These deprecations of course popped up in the test suite, so I’ve been
replacing them with per-instance pragmas there too. Interestingly in some
cases, when looking for which instances needed the pragmas, I found…none. So
OverlappingInstances was entirely unnecessary. Maybe library authors will
find that too!
Simon
___
Re: ghc and aarch64?
Sure. 'Extend' was the wrong phrasing. I meant more that given the work gone into ARM support in GHC in the sense of the build system, RTS, cross compilation.. e.t.c, I'd be surprised if this didn't help porting to AArch64. Just human expertise we have now helps a huge amount. On 26 March 2013 01:31, Karel Gardas karel.gar...@centrum.cz wrote: Hi David, AArch64 is completely new architecture so it's not about extending current ARM support but rather write a new beside it -- at least as a prototype, if there is a lot of synergies you can merge both together later, but I don't see it having a high chance. Well the situation with AArch64 and ARM is very similar to situation with i386 and amd64 support so you can get an idea what's the difference (extended registers set, extended registers width, extended NEON (the least important detail indeed), different calling convention, etc.) Cheers, Karel On 03/26/13 08:14 AM, David Terei wrote: I don't believe so. LLVM in head supports Arm64 so I imagine it wouldn't be too much work to extend our existing Arm support (also through LLVM) to work with Arm64. I'm not aware of any Arm64 hardware being available yet but someone could potentially start with a virtual image: http://www.linaro.org/engineering/armv8 On 25 March 2013 19:33, Jens Petersenj...@community.haskell.org wrote: I am curious if anyone has started or is planning to work on porting GHC to the new ARM 64bit architecture AArch64 for Linux? Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to compile ghc 7.6.2 with llvm?
Hi Magicloud, Setting build.mk to BuildFlavour = perf-llvm means that the GHC built will be built using the LLVM backend of GHC. For any build of GHC though, to *use* the LLVM backend of GHC you simply want to compile with -fllvm. The output of inplace/bin/ghc-stage2 �Cinfo won't differ for a GHC built with the native-code-generator compared to one built with the LLVM code generator. Both build of GHC will include support for the native-code-generator and the LLVM backends. Cheers, David On 12 February 2013 08:48, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:41 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: ./configure --with-gcc=/usr/bin/llvm-gcc Sorry, I was wrong. with 'with-gcc' option, I got a ld error, which I will post later. Without this option, I got native code generator result because the configure found gcc. Should I or not using this option? -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to compile ghc 7.6.2 with llvm?
Nothing straight forward to do this. You could do any of: 1) Look at the output of make a GHC is compiled. Verify that by and large most lines have '-fllvm' on them. 2) As above but pipe output of building GHC to a file. Grep it later for '-fllvm', you should get a very high count. 3) Add a -v2 option to the build settings in build.mk, this will give lots and lots of output, showing for example that the various LLVM tools (llc, opt) are being called. 4) temporarily remove the llvm tools (opt, llc) from the command line and verify that building GHC fails pretty quickly. I'd say 2 is the best bet. However, if you chose perf-llvm as your build setting and GHC built, you built GHC with LLVM. Cheers, David On 12 February 2013 10:13, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Thank you for the replies. These are what I got, correct me if I am wrong: If I want to build ghc executables and standard libraries, all I need is to set perf-llvm. And set perf-llvm or not does not effect the ability of ghc to use llvm. Then how to check if the output files (executables, libraries) are generated by llvm, instead of gcc? In other words, to see if llvm was used correct. On Wed, Feb 13, 2013 at 1:09 AM, Brandon Allbery allber...@gmail.com wrote: On Tue, Feb 12, 2013 at 11:41 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Then I `mv build.mk.sample build.mk`, set BuildFlavour = perf-llvm, add GhcWithLlvmCodeGen = YES. Finally `./configure --with-gcc=/usr/bin/llvm-gcc`. Configure output attached. After make, I tried `inplace/bin/ghc-stage2 �Cinfo`, it is still using native code generator. What should I do? 1. I think --with-gcc= is independent of the llvm code generator. 2. Building the llvm codegen does not necessarily make it the *default* codegen; I think native remains default. I don't know if there's a way to specify that llvm should be the default code generator. fwiw, the ghc I have on here does not mention llvm in ghc --info, but ghc -fllvm at least tries to work. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 10 February 2013 13:02, Simon Peyton-Jones simo...@microsoft.com wrote: What I am still missing is this: | Mark is asking for major GHC releases every year at the most, preferably | less frequently. That means major GHC releases in the sense that we do | them now, where libraries change, and a wave of package updates are | required to get everything working. What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately. You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. Of course we could just not do that, and say build from source, but a release brings a welcome discipline. But under this story, release or not-release would be a Little Deal, not a Big Deal. The benefits are modest; the costs are modest. In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting. My understanding of the proposed changes (which I'm also supportive of) is to separate GHC improvements that break existing libraries (or perhaps even simply add language level features), and those that are improvements under-the-hood (e.g., bug fixes, performance improvements). So rather than 7.8 be a huge single release containing new type level features, SIMD, the new code-generator. There would be two releases, one containing just say the new-code-generator, improvements to the IO manager, potentially also DPH... another release would containing new language level improvements. So then HP can benefit from improvements to the existing language and API without having to also pull in breaking (or just extending) changes... It's the issue of a research compiler Vs. and industrial compiler and managing that more explicitly in the release model. Cheers, David Simon | | Johan, Manuel and Carter are saying that they want releases that add | features but don't break code, i.e. a non-API-breaking release, as a way | to get the new bits into the hands of the punters sooner. This is | something that we don't do right now, and it would entail a change to | our workflow and release schedule. | | It doesn't mean no API changes at all - we would have to allow APIs to | be extended, because many feature additions come with new primops, or | new supporting code in the ghc-prim or base packages. The package | version policy states precisely what it means to extend an API | (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most | third-party packages will still work so long as we only bump the minor | versions of the packages that come with GHC. | | The GHC package itself would have to be exempt, because it contains | every module in GHC, and hence would be impossible to keep stable if we | are modifying the compiler to add new features. | | Of course it's not practical to maintain an extra branch of GHC for | non-API-breaking development - two branches is already plenty. So there | would need to be an API-freeze for a while between the major release and | the non-API-breaking release, during which time people developing API | changes would need to work on branches. | | Is it workable? I'm not sure, but I think it's worth a try. I wouldn't | want to see this replace the patchlevel bugfix releases that we already | do, and as Ian points out, there isn't a lot of room in the release | schedule for more releases, unless we stretch out the timescales, doing | major releases less frequently. | | Cheers, | Simon | | | ·Haskell Platform | | ·Patch-level releases | | ·New releases | | | if that’s so, all we need is better signposting. And I’m all for that! | | Have I got this right? | | | Simon | | *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com] | *Sent:* 09 February 2013 17:48 | *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon | Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter | Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org; | glasgow-haskell-users | *Subject:* Re: GHC 7.8 release? | | We seem to be circling ever closer to consensus here! Yay! | | I think the distinction of non-API breaking and API breaking release is | very important. Refining SPJ's
Re: How to get started with a new backend?
I believe that some Microsoft Research folks at Cambridge got a fairly far along implementation of Haskell on Java or .NET many years back but concluded it wasn't a good fit. My rusty memory of a conversation with Simon Marlow about this was that all the Java libraries basically ended up in IO and matching the API and type design up with Haskell wasn't very nice. Not sure what the motivation is, but you may want to look at VMKit: http://vmkit.llvm.org/. It could be a good fit and may be easy to use through the LLVM backend. On 27 January 2013 17:15, Jason Dagit dag...@gmail.com wrote: I would like to explore making a backend for .NET. I've done a lot of background reading about previous .NET and JVM attempts for Haskell. It seems like several folks have made significant progress in the past and, with the exception of UHC, I can't find any code around the internet from the previous efforts. I realize that in total it's a huge undertaking and codegen is only one of several significant hurdles to success. I would like to get a very, very, very simple translation working inside GHC. If all I can compile and run is fibonacci, then I would be quite happy. For my first attempt, proof of concept is sufficient. I found a lot of good documentation on the ghc trac for how the compilation phases work and what happens in the different parts of the backend. The documentation is excellent, especially compared to other compilers I've looked at. When I started looking at how to write the code, I started to wonder about the least effort path to getting something (anything?) working. Here are some questions: * Haskell.NET seems to be dead. Does anyone know where their code went? * Did lambdavm also disappear? (JVM I know, but close enough to be useful) * Would it make sense to copymodify the -fvia-C backend to generate C#? The trac claims that ghc can compile itself to C so that only standard gnu C tools are needed to build an unregistered compiler. Could I use this trick to translate programs to C#? * What stage in the pipeline should I translate from? Core? STG? Cmm? * Which directories/source files should I look at to get familiar with the code gen? I've heard the LLVM codegen is relatively simple. * Any other advice? Thank you in advance! Jason ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Size of crosscompiled exectuable
To pass to opt use '-optlo', e.g., $ ghc -fllvm -optlo-adce ... Its documented in the GHC userguide. Cheers, David On 26 January 2013 02:07, Nathan Hüsken nathan.hues...@posteo.de wrote: On 01/26/2013 09:24 AM, Nathan Hüsken wrote: On 01/25/2013 05:45 PM, Simon Marlow wrote: On 25/01/13 16:35, Simon Marlow wrote: On 25/01/13 15:51, Stephen Paul Weber wrote: Somebody claiming to be Simon Marlow wrote: On 25/01/13 13:58, Nathan Hüsken wrote: A simple hello world application has 1Mb in by 64 bit ubunut machine. When I stript it, is has about 750kb. When I build a cross compiler for android (arm), the executable has a asize of about 10MB, stripped about 5MB. That is huge, five times the size on my linux sysem. Not sure what you mean by five times the size on my linux system. What is 5 times larger than what? He's saying that the size of the android executable (made by his cross compiler) is five time the sive of the equivalent Ubuntu executable (made by, I assume, his system's GHC). Yes, exactly. Sorry for my bad phrasing. The problem is not the size, but the size ratio. Ah, I see. Yes, my executables are a similar size. I'm not sure why, I'll try to look into it. It's just the lack of SPLIT_OBJS. Also, unregisterised accounts for a factor of 1.5 or so. What exactly does SPLIT_OBJS do? Is there a chance to get it working for cross platform? There must be a lot of unused code in the exectuable. Is there no way to remove it? 5 Mb is rather large for an android app. Maybe it would help to pass parameters like -adce or -globaldce to opt (from llvm). But I can not figure out how I can tell ghc to pass these parameters. Someone knows? Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Hi all, Can people please file bugs about these issues when they are confirmed to some degree? Lots of ARM LLVM stuff seems to just be floating around mailing lists much higher chance of me or someone else fixing if there are filed bug reports with test cases and/or patches attached. Austin and I also fixed a couple of LLVM related issues in the last 2 days or so, so hopefully that solved some of these. Top level bugs to link to when filing other bugs please: * GHC ARM support: http://hackage.haskell.org/trac/ghc/ticket/7623 * LLVM Cross compilation: http://hackage.haskell.org/trac/ghc/ticket/7610 * LLVM unregisterised issues: http://hackage.haskell.org/trac/ghc/ticket/7622 * LLVM bootstrap issues: http://hackage.haskell.org/trac/ghc/ticket/7590 Cheers, David On 24 January 2013 10:28, Nathan Hüsken nathan.hues...@posteo.de wrote: On 01/24/2013 07:26 PM, Stephen Paul Weber wrote: Somebody claiming to be Nathan Hüsken wrote: On 01/24/2013 07:00 PM, Stephen Paul Weber wrote: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcapsthen the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( Can you run it in gdb and loock what the backtrace looks like? [New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) Not very informative :). Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with file. Maybe you have to do something like that to? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi Ian This bug is still present in mainline. Any chance of it being fixed? Cheers, David On 12 January 2013 06:38, Ian Lynagh i...@well-typed.com wrote: Hi Sean, On Mon, Dec 10, 2012 at 04:04:34PM +0100, Sean Leather wrote: On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote: Please test as much as possible; bugs are much cheaper if we find them before the release! I tried to build the source tarball on Mac OS X 10.5.8. I used GHC 7.6.1, which I also built myself (without any problem) and installed in /Library/Frameworks/GHC.framework/Versions/7.6.1/usr. I got this: HC [stage 0] ghc/stage1/build/hschooks.o ghc/hschooks.c:36:0: error: conflicting types for ‘StackOverflowHook’ Thanks for the report! I've fixed it in the 7.6 branch. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How do we best make sure {Int,Word,Float,Double} to {Int,Word,Float,Double} conversions stay efficient
I believe the testsuite now has support for inspecting assembly output. Not sure if that would be best for your use case, but something to consider. On 14 December 2012 12:53, Johan Tibell johan.tib...@gmail.com wrote: Hi, I've been tracking down a few (unrelated) performance bugs related to conversions between primitive types. What these issues had in common is that some rule failed to fire and the conversion went via Integer, killing performance. How do we best write a test that make sure that fromIntegral conversions between these types don't regress? Is it possible to test the output of the simplifier or do we have to do something less direct, like writing a loop that does such conversions and make sure that the allocation stay low? -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell Dynamic Loading with -fllvm
Hi Nathan, So dynamic libraries should be supported on a few platforms but not all, not as many as the NCG. Support also varies from LLVM version. What platform and version of LLVM are you trying to utilize? And specifically what flags are you using? Cheers, David On 11 December 2012 08:53, Nathaniel Neitzke night...@gmail.com wrote: Essentially I have a use case that, if worked, would save countless hours in development time. I am writing a scientific computing web service utilizing the Repa and Snap libraries. The Snap framework has a dynamic loader that will load modules on the fly when the source files change. This works excellent! The problem is that the modules must be compiled with full optimizations (including -fllvm) or web service operations take minutes instead of second to execute at run time. I do not mind the penalty paid for optimized compilation. It is still much faster than recompiling and linking the entire exe from scratch and restarting the server. The problem is when the code is compiled with -fllvm dynamically, it crashes. I believe this is a known issue as listed in this trac - http://hackage.haskell.org/trac/ghc/ticket/4210 NOTE: it says The LLVM backend doesn't support dynamic libraries at the moment. My question is could anyone point me in the right direction as to what might need to be implemented support for this? Is anyone currently working on it? It would be a huge win for the work I am currently doing, to the point where if I can't find a way to get this working (even if it means diving in and attacking it myself), I may have to switch to another language/platform. Thanks, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Hoopl vs LLVM?
Right now there isn't really an overlap with LLVM passes. In general the feeling of many of the GHC developers is that we don't want to spend time duplicating what LLVM already does. That said, GHC is an open source project so someone may be inclined to do so and there isn't a lot of reason not to accept such patches (Hoopl can be slow though, so would be -O3 or -O2). We just feel that aligning GHC with LLVM is the more productive approach going forward, especially when for example its the only backend on ARM. In terms of comparison, the high level arch is different as Edward pointed out. Otherwise LLVM mostly implements fairly known optimisation algorithms, so not much to steal there. On 10 December 2012 14:24, Greg Fitzgerald gari...@gmail.com wrote: I don't know my way around the GHC source tree. How can I get the list of optimizations implemented with Hoopl? Is there overlap with LLVM's optimization passes? If so, has anyone compared the implementations at all? Should one group be stealing ideas from the other? Or apples and oranges? Thanks, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The end of an era, and the dawn of a new one
I have always considered the LLVM code generator my responsibility and will continue to do so. I don't seem to find the time to make improvements to it but make sure to keep it bug free and working with the latest LLVM releases. So if others want are interested in working on it then there is plenty of room for that but I'll continue to maintain it and be responsible for it at the least. On 5 December 2012 08:56, Simon Peyton-Jones simo...@microsoft.com wrote: Friends You'll have seen Simon Marlow's recent announcement (included below): | Today I'm announcing that I'm leaving Microsoft Research. Simon Marlow and I have worked together on GHC for nearly two decades. During much of that time we have shared a cup of coffee every morning (one cup each, since you ask), to discuss what's going on in GHC-land. We had frequent detailed and illuminating debates about design alternatives. Simon is the absolute master of GHC's code generation, runtime system, garbage collector, support for parallel execution, and much else besides. His sheer programming skill in rooting out obscure and hard-to-reproduce runtime system bugs has always amazed me. He is more than just a great hacker, of course. He is a leader in our community, has a strong publication record, chaired the Haskell Prime committee for a year, and is sought after for tutorials about parallel programming. I owe Simon a great debt, as I think we all do, for the care and skill he has lavished on GHC. He's not going to disappear entirely, but he will be spending much less time on GHC than in the past. That is a change, but it's a change that was always going to happen sometime, and while change is sometimes uncomfortable, it can also open up new possibilities. GHC is over 20, and like my own children (who are actually all a bit younger than GHC), that's not a bad time to start to head out into the world. Over time, more and more people have started to help with the task of developing and maintaining GHC. We'll have to do more of that. These days GHC has a very large surface area (running on different platforms, dynamic linking, debugger, profiler, GHCi, libraries and Cabal, etc etc), and has grown far beyond what any single person or research group can manage. Lest you should wonder, I myself will certainly continue to work on GHC. But my job is to be a *researcher*, and I am not well equipped -- in temperament or expertise -- to deal with the myriad complexities of deployment, upgrade policy, portability, and the like. Well Typed (mostly in the guise of Ian Lynagh) will continue to handle some of these issues, but again there is too much for one person to do. So we need your help. Seriously. Rather than just thinking GHC HQ will sort it out, I would welcome you saying Shall I take responsibility for X?. Johan, Bryan, and others offering to be GHC Performance Tsars is a great recent example. But don't wait to be asked: just make an offer if you see a gap or an open ticket --- and I think there will be plenty of those. Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. I am going to miss that cup of coffee though. Thank you Simon! Facebook is lucky to have you. Onward and upward. Simon (PJ) | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Simon Marlow | Sent: 22 November 2012 11:27 | To: haskell; glasgow-haskell-users@haskell.org | Subject: Leaving Microsoft | | Today I'm announcing that I'm leaving Microsoft Research. | | My plan is to take a break to finish the book on Parallel and Concurrent | Haskell for O'Reilly, before taking up a position at Facebook in the UK | in March 2013. | | This is undoubtedly a big change, both for me and for the Haskell | community. I'll be stepping back from full-time GHC development and | research and heading into industry, hopefully to use Haskell. It's an | incredibly exciting opportunity for me, and one that I hope will | ultimately be a good thing for Haskell too. | | What does this mean for GHC? Obviously I'll have much less time to work | on GHC, but I do hope to find time to fix a few bugs and keep things | working smoothly. Simon Peyton Jones will still be leading the project, | and we'll still have support from Ian Lynagh, and of course the | community of regular contributors. Things are in a reasonably stable | state - there haven't been any major architectural changes in the RTS | lately, and while we have just completed the switchover to the new code | generator, I've been working over the past few weeks to squeeze out all | the bugs I can find, and I'll continue to do that
Re: GHC Performance Tsar
This is something I'd be happy to help out with. On 30 November 2012 11:48, Johan Tibell johan.tib...@gmail.com wrote: Hi Simon, I will try to find some time to set up a automatic run of nofib on my buildbot (which is powerful enough) and have it graph the results over time (and perhaps even email us when a benchmark dips). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Leaving Microsoft
Thank you Simon for all the hard work on GHC over the years and for the various opportunities I've had to work with you personally. The change sounds exciting and I wish you all the best. With you there and Bryan, hopefully Facebook can become a Haskell shop :). Also, perhaps the change will mean you'll be visiting San Francisco on a regular basis (or at least for FB bootcamp?), so please shout out to me when you do. I'd love to catch up for a beer as I know a few other Haskell hackers in the area would. Cheers, David On 22 November 2012 03:26, Simon Marlow marlo...@gmail.com wrote: Today I'm announcing that I'm leaving Microsoft Research. My plan is to take a break to finish the book on Parallel and Concurrent Haskell for O'Reilly, before taking up a position at Facebook in the UK in March 2013. This is undoubtedly a big change, both for me and for the Haskell community. I'll be stepping back from full-time GHC development and research and heading into industry, hopefully to use Haskell. It's an incredibly exciting opportunity for me, and one that I hope will ultimately be a good thing for Haskell too. What does this mean for GHC? Obviously I'll have much less time to work on GHC, but I do hope to find time to fix a few bugs and keep things working smoothly. Simon Peyton Jones will still be leading the project, and we'll still have support from Ian Lynagh, and of course the community of regular contributors. Things are in a reasonably stable state - there haven't been any major architectural changes in the RTS lately, and while we have just completed the switchover to the new code generator, I've been working over the past few weeks to squeeze out all the bugs I can find, and I'll continue to do that over the coming months up to the 7.8.1 release. In due course I hope that GHC can attract more of you talented hackers to climb the learning curve and start working on the internals, in particular the runtime and code generators, and I'll do my best to help that happen. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unregisterized
On 6 February 2012 06:09, Serge D. Mechveliani mech...@botik.ru wrote: On Mon, Feb 06, 2012 at 02:33:53PM +0100, Karel Gardas wrote: [..] I would recommend to start here: http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised Thank you. Probably, there is something like an error on http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised : To do an unregisterised build, add the following to your mk/build.mk file: GhcUnregisterised=YES GhcWithNativeCodeGen=NO SplitObjs=NO Because in ghc-7.4.1, mk/build.mk.sample contains [..] ifeq $(BuildFlavour) unreg GhcUnregisterised = YES GhcWithNativeCodeGen = NO [..], and the user rather needs to find and un-comment the line #BuildFlavour = unreg Right? Yes. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: via-C
On 5 February 2012 10:48, Serge D. Mechveliani mech...@botik.ru wrote: Dear GHC team, I cannot understand why do you remove the C stage in GHC. We didn't. GHC itself can be built in two different ways, 'unregisterized' and 'registerized'. The former method is more portable while the latter uses as many tricks as possible for performance but is quite platform specific. The C backend used to support both ways. Now it only supports unregisterized. It remains specifically for what you want, portability. The NCG of GHC only supports registerized way. The LLVM backend supports both unregisterized and registerized. So take a look at the C backend and LLVM. Cheers, David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.2.2 RC 1
On 7 November 2011 08:44, Simon Marlow marlo...@gmail.com wrote: I think we should apply the minimal change to make all packages trusted by default in 7.2.2. Any objections? Agreed. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build times on newer MacBook Pros?
I have a 16 core machine at work (with 48GB of ram, a perk of the job :)). GHC can saturate them all. Can validate GHC in well under 10 minutes on it. I also just got the 15 core i7 2.3GHz less then a week ago, it's a very nice machine so I would recommend it. But yeah just getting the 2.2GHz is the better value for money. On 23 August 2011 07:56, Johan Tibell johan.tib...@gmail.com wrote: Sounds promising. Now I just have to decide whether to get the 2.2 or 2.3 GHz version. I suspect the latter is a bit overpriced. On Tue, Aug 23, 2011 at 4:36 PM, austin seipp a...@hacks.yi.org wrote: I'm using a MBP with a quad core 2gHz Core i7; it has 8 overall hardware threads. GHC's build process using 'make -j9' or 'make -j12' totally saturates all my cores. I believe I can clock in a full build at well under 10 minutes (with BuildFlavor = quick in mk/build.mk.) For comparison, I also have a dual core 2gHz Core i7 (4 hardware threads) in a lenovo sitting next to it running Linux, and a full GHC build takes a bit longer. I can get real numbers later if it's actually that interesting. I'd recommend you getting the quad-core machine, if at all possible. On Tue, Aug 23, 2011 at 4:27 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi! I'm looking to upgrade my laptop so that I can (among other things) compile GHC faster. I'll either get the 13 2.7GHz dual-core Intel Core i7 model or the 15 2.2GHz quad-core Intel Core i7 model. Anyone know if it's worth to get the 15 model? According to these benchmarks it should be quite a bit faster: http://www.primatelabs.ca/geekbench/mac-benchmarks/ but I don't know if I can get enough parallelism out of GHC's build to use all 4 cores in the 15 model. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Regards, Austin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wiki page about new memcpy/memmove/memset primops need a home
I would suggest it be put under the Commentary/Compiler. http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler Just add it as a top level bullet point for now, maybe after 'Wired-in and known-key things'. Also you should update the Cmm language page: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType#OperatorsandPrimitiveOperations Include a small update to the page and link to the main page on the new prim ops. Cheers, David On 8 June 2011 14:05, Johan Tibell johan.tib...@gmail.com wrote: Hi, I intend to write a short wiki page explaining the design and use of the new memcpy/memmove/memset primops we added recently. Where would be a good place to put such a page? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: performance issues in simple arithmetic code
On 27 April 2011 20:01, Denys Rtveliashvili r...@mac.com wrote: The lack of expected magic is in the assembler code: --- addq $16,%r12 cmpq 144(%r13),%r12 ja .Lcz1 movl $1117,%ecx movl $1113,%r10d movl $,%r11d movq 7(%rbx),%rax cqto idivq %r11 cqto idivq %r10 cqto idivq %rcx movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) movq %rax,0(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *0(%rbp) --- Question: can't it use cheap multiplication and shift instead of expensive division here? I know that such optimisation is implemented at least to some extent for C--. I suppose it also won't do anything smart for expressions like a*4 or a/4 for the same reason. There isn't really any optimisation done on Cmm and the native code generator doesn't do much optimisation itself, hence you get the more direct forward translation. This kind of code is where the LLVM backend does well in comparison. I haven't tried benchmarking the performance of -fasm vs -fllvm for this code but if you eyeball the assembly code produced by -fllvm then you'll see it uses shifts and other magic. Cheers, David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 7.0.3
Hi Ian, Could you merge my fix for this: http://hackage.haskell.org/trac/ghc/ticket/4995 So patch is: Wed Mar 9 13:53:46 PST 2011 David Terei davidte...@gmail.com * LLVM: Fix #4995, llvm mangler broken for large compiles Its a pretty small change and fixes an ugly issue with the LLVM backend on OSX. Cheers, David On 15 March 2011 10:04, Ian Lynagh ig...@earth.li wrote: Hi all, Due to a number of issues in the 7.0.2 release, we plan to put out a 7.0.3 release before finally retiring the 7.0 branch. We intend to fix: * Doc install location on Windows * Doc building on OS X (#4997) * Object splitting on OS X (with XCode = 3.2) * Don't require the 10.5 SDK on OS X (should mean GHC works with XCode 4) We will also look into the problems with stripping and libHSghc.a (e.g. the issue building yesod #5004), and the ld warnings on OS X (#4984). We want to keep the changes in this release to a minimum, to minimise the chance of regressions, but if you think we've missed any critical issues please let us know. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 10 January 2011 22:19, Simon Marlow marlo...@gmail.com wrote: We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? I would really like GHC to move to git. I find darcs pretty annoying when working in a branch and the performance still just isn't good enough (e.g can't use 'annotate'). I've been a big fan of git from pretty much as soon as I started using it, its interface is badly designed at times but with the help of google I've always been able to get it to do what I want. Defiantly can't say the same for darcs. It didn't stop me contributing but when I first started hacking on ghc I was very put of by darcs as I had only recently got over the nightmares of the very common exponential merge issue from 1.x days. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
I haven't looked at these branches for a fair few weeks, the problem when they fail to build usually is because all the libraries are just set to follow HEAD, they're not actually branched themselves, just the ghc compiler. So there are probably some patches from ghc HEAD that need to be pulled in to sync the compiler with the libs again. If you want to do some work on the new codegen the first step is to try to pull in all the patches from ghc HEAD, synchronise the branch. Its not a fun job but GHC HQ wants to try to merge in all the new codegen stuff to HEAD asap. On 4 December 2010 23:45, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010: http://darcs.haskell.org/ghc-cmm-03Sep10/ This branch fails to build for me: inplace/bin/ghc-stage1 -M -dep-makefile libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp -include-pkg-deps -H64m -O -fasm -package-name dph-par-0.5 -hide-all-packages -i -ilibraries/dph/dph-par/../dph-common -ilibraries/dph/dph-par/dist-install/build -ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/dist-install/build -Ilibraries/dph/dph-par/dist-install/build/autogen -Ilibraries/dph/dph-par/. -optP-include -optPlibraries/dph/dph-par/dist-install/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.0.0 -package dph-base-0.5 -package dph-prim-par-0.5 -package ghc-7.1.20101126 -package ghc-prim-0.2.0.0 -package random-1.0.0.3 -package template-haskell-2.5.0.0 -Odph -funbox-strict-fields -fcpr-off -fdph-this -package-name dph-par -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -no-user-package-conf -rtsopts -O -dcore-lint -odir libraries/dph/dph-par/dist-install/build -hidir libraries/dph/dph-par/dist-install/build -stubdir libraries/dph/dph-par/dist-install/build -hisuf hi -osuf o -hcsuf hc libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Int.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Word8.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Float.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Double.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/PArray.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/PArray.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Unboxed.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Scalar.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/TH/Repr.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Repr.hs l! ibraries /dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Closure.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Instances.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Lifted/Combinators.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Int.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Word8.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Float.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Double.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Bool.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/PArr.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base/Tuple.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Base.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel/Prelude/Bool.hs libraries/dph/dph-par/../dph-common/Data/Array/Parallel.hs:1:14: Unsupported extension: ParallelArrays make[1]: *** [libraries/dph/dph-par/dist-install/build/.depend-v.haskell] Error 1 make: *** [all] Error 2 I can debug this further if you want me to. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
Which branch are you working off though? ghc HEAD doesn't have the latest changes to the new codegen, afaik the latest changes are in the branch http://darcs.haskell.org/ghc-cmm-03Sep10/ There is also a branch now though at http://darcs.haskell.org/ghc-new-co-17Nov10/ which I'm not sure what it relates to, so check that out as well or wait for someone who knows for sure to respond. Cheers, David On 4 December 2010 04:45, Edward Z. Yang ezy...@mit.edu wrote: I fired up the new codegen and ran make fast on the regression suite and the following new tests started failing: 3207(normal) 4030(normal) cgrun016(normal) cgrun045(normal) cgrun051(normal) dsrun005(normal) dsrun007(normal) dsrun008(normal) exceptionsrun001(normal) exceptionsrun002(normal) ffi021(normal) simplrun010(optc) strun002(optc) I plan on investigating them in further detail. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ld memory usage
You could also have a look at the new 'Gold' linker that's part of binutils. Not sure if this has been tested before with ghc but its meant to have far greater performance (in time is what I've heard, not sure about memory) then 'ld' and be a drop in replacement. On 17 April 2010 00:00, Roman Beslik ber...@ukr.net wrote: Hi. This is not strictly a GHC question. I observed that ld when linking GHC-compiled programs eats 0.5 GB of resident memory. ~3 times more than GHC or Haddock. So if there is not enough free memory ld uses virtual memory and works very slowly (practically does not use CPU). I'd like to know, is anyone interested in researching and improving memory usage? Is it ld or GHC problem? I found a similar discussion here http://article.gmane.org/gmane.comp.lang.haskell.cafe/66189 but it was too broad and went nowhere. -- Best regards, Roman Beslik. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removing/deprecating -fvia-c
Don Stewart wrote:
Here's an example that doesn't use floating point:
import Data.Array.Vector
import Data.Bits
main = print . sumU $ zipWith3U (\x y z - x * y * z)
(enumFromToU 1 (1 :: Int))
(enumFromToU 2 (10001 :: Int))
(enumFromToU 7 (10008 :: Int))
In core:
main_$s$wfold :: Int# - Int# - Int# - Int# - Int#
main_$s$wfold =
\ (sc_s1l1 :: Int#)
(sc1_s1l2 :: Int#)
(sc2_s1l3 :: Int#)
(sc3_s1l4 :: Int#) -
case# sc2_s1l3 1 of _ {
False -
case# sc1_s1l2 10001 of _ {
False -
case# sc_s1l1 10008 of _ {
False -
main_$s$wfold
(+# sc_s1l1 1)
(+# sc1_s1l2 1)
(+# sc2_s1l3 1)
(+#
sc3_s1l4 (*# (*# sc2_s1l3 sc1_s1l2) sc_s1l1));
True - sc3_s1l4
};
True - sc3_s1l4
};
True - sc3_s1l4
}
Rather nice!
-fvia-C -optc-O3
Main_mainzuzdszdwfold_info:
cmpq $1, %rdi
jg .L6
cmpq $10001, %rsi
jg .L6
cmpq $10008, %r14
jle .L10
.L6:
movq %r8, %rbx
movq (%rbp), %rax
jmp *%rax
.L10:
movq %rsi, %r10
leaq 1(%rsi), %rsi
imulq %rdi, %r10
leaq 1(%rdi), %rdi
imulq %r14, %r10
leaq 1(%r14), %r14
leaq (%r10,%r8), %r8
jmp Main_mainzuzdszdwfold_info
Which looks ok.
$ time ./zipwith3
3541230156834269568
./zipwith3 0.33s user 0.00s system 99% cpu 0.337 total
And -fasm we get very different code, and a bit of a slowdown:
Main_mainzuzdszdwfold_info:
.Lc1mo:
cmpq $1,%rdi
jg .Lc1mq
cmpq $10001,%rsi
jg .Lc1ms
cmpq $10008,%r14
jg .Lc1mv
movq %rsi,%rax
imulq %r14,%rax
movq %rdi,%rcx
imulq %rax,%rcx
movq %r8,%rax
addq %rcx,%rax
leaq 1(%rdi),%rcx
leaq 1(%rsi),%rdx
incq %r14
movq %rdx,%rsi
movq %rcx,%rdi
movq %rax,%r8
jmp Main_mainzuzdszdwfold_info
.Lc1mq:
movq %r8,%rbx
jmp *(%rbp)
.Lc1ms:
movq %r8,%rbx
jmp *(%rbp)
.Lc1mv:
movq %r8,%rbx
jmp *(%rbp)
Slower:
$ time ./zipwith3
3541230156834269568
./zipwith3 0.38s user 0.00s system 98% cpu 0.384 total
Now maybe we need to wait on the new backend optimizations to get there?
I've been looking at some of these cases and seeing how the LLVM
back-end performs. My general impression from benchmarking the LLVM
back-end in the past has been that it generally performs with similar
characteristics as the C code generator (that is, where the C code
generator stood out compared to the NCG, so did LLVM).
(On x86-32/Mac OS X 10.5, had some issues getting x64 working at moment):
./zipWith3_viac 0.72s
./zipWith3_fasm 0.65s
./zipWith3_llvm 0.38s
Code that LLVM produces:
_Main_mainzuzdszdwfold_entry:
## BB#0: ## %c1qP
subl $12, %esp
jmp LBB2_1
.align 4, 0x90
LBB2_4: ## %n1re
## Loop Depth 1
## Loop Header is BB2_1
## Inner Loop
movl %ecx, %esi
incl %ecx
imull %eax, %esi
incl %eax
imull %edx, %esi
incl %edx
addl (%ebp), %esi
movl %edx, 12(%ebp)
movl %ecx, 8(%ebp)
movl %eax, 4(%ebp)
movl %esi, (%ebp)
LBB2_1: ## %tailrecurse
## Loop Depth 1
## Loop Header
## Inner Loop
movl 4(%ebp), %eax
cmpl $1, %eax
jg LBB2_5
## BB#2: ## %n1qX
## Loop Depth 1
## Loop Header is BB2_1
## Inner Loop
movl 8(%ebp), %ecx
cmpl $10001, %ecx
jg LBB2_5
## BB#3: ## %n1r5
## Loop Depth 1
## Loop Header is BB2_1
## Inner Loop
movl 12(%ebp), %edx
cmpl $10008, %edx
jle LBB2_4
LBB2_5: ## %c1qW
movl 16(%ebp), %eax
movl (%ebp), %esi
addl $16, %ebp
movl (%eax), %eax
addl $12, %esp
jmpl *%eax # TAILCALL
Which is very nice. (The comments in the code are inserted by LLVM, not me).
I also ran through some of the programs outlined here:
http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/18151
All ran with 'echo '1e-8' | ./$PRG'.
Loop.hs:
{-# LANGUAGE BangPatterns #-}
module Main (main) where
main :: IO ()
main = do
putStrLn EPS:
eps - readLn :: IO Double
let !mx = (4/eps)
!pi14 = pisum mx
putStrLn $ PI mit EPS ++(show eps)++ = ++ show(4*pi14)
pisum :: Double - Double
pisum cut = go True 1 0
where
go b n s | cut n = if b then s+1/(2*n) else s-1/(2*n)
go True n !s = go False (n+2) (s+recip n)
go False n !s = go True (n+2) (s-recip n)
./Loops_fasm 4.53s
./Loops_viac 4.22s
./Loops_llvm 2.89s
Fusion.hs (uses stream-fusion package)
module Main (main) where
import qualified Data.List.Stream as S
main :: IO ()
main = do
putStrLn EPS:
eps - readLn :: IO Double
let !mx = floor (4/eps)
!k = (mx+1) `quot` 2
putStrLn $ PI mit EPS ++ (show eps) ++ = ++ show (leibniz k)
leibniz n = (4 *) $ S.sum $ S.take n step
step :: [Double]
step = S.unfoldr phi (True,1) where
phi (sig,d) | sig = Just (1/d, (False,d+2))
| otherwise = Just (negate (1/d), (True,d+2))
./Fusion_fasm 4.61s
./Fusion_viac 4.22s
./Fusion_llvm 3.62s
List.hs
module Main (main) where
import Data.List (unfoldr)
main :: IO ()
main = do
putStrLn EPS:
eps - readLn :: IO Double
let mx = floor (4/eps)
!k = (mx+1) `quot` 2
putStrLn $ PI mit EPS ++ (show eps) ++ = ++ show (leibniz k)
leibniz n = (4 *) $ sum $ take n step
step :: [Double]
step = unfoldr phi (True,1) where
phi (sig,d) |
