Re[2]: readArray is faster than unsafeRead
Hello Scott, Wednesday, May 30, 2007, 1:42:22 AM, you wrote: I've included your implementation for comparison, as well as a simple pure matrix multiplication function, but I'm having trouble tracking them down in the profiling. I think all of their cycles are being counted under main, but I'm not sure how to stop this. this may be due to inlining. if you stop inlining, things will start count properly but perform much slower :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: readArray is faster than unsafeRead
Why would lists-of-lists be faster than unboxed arrays? No indexing arithmetic? Deforestation? I'm very curious. The first advice I got from #haskell when trying to speed up my original code was get rid of all those lists. First, I think lists-of-lists is only faster (if at all) in your special case of having only very small matrices. Moreover, the pure implementation runs without the 'near zero' tests and the array implementation is not as smart as possible. For example instead of f j1 where f j | jn = return () ; f j = work_on j f (j+1) you could simply write mapM_ work_on [j1..n] and save some comparsions. Second, clearly you have to get rid of all those lists, as long as you are trying to implement the algorithm in the usual algebra book style, where you find formulations that are suitable to mutable array implementations. The pure implementation instead tries to exploit the recursive structure and some invariants of Gauss' algorithm in a direct way. BR, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ --- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi, I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The binary works well enough to build itself and darcs. There are only sixteen unexpected test suite failures thus far. I am ignoring these for the moment while I get back to thinking about ghci. Note that you need to install libgmp to use the compiler. libgmp from the ports collection works fine. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC Extensibility
Hi (this message is mainly intended to the GHC Team), is there any plan to improve GHC's extensibility by providing a simpler way to integrante new backends? I worked at Haskell.NET project in the past, when we integrated successfully a .NET code generator to GHC 6.2.2. As it wasn't stable enough, we didn't integrate it to the main branch. However, I've been trying to integrate our code generator to 6.6.1 and I've not been able to compile it up to now, due to several changes in GHC's code! I haven't yet figured out how to call the .NET code generator from GHC 6.6.1's main function. Further, it would be great if there was a better extensibility mechanism (such as a plugin infrastructure, for example) in which it wasn't necessary to use #ifdefalong the code. Also, it would be very useful if this mechanism/API was well documented. Of course, this is only a suggestion. Best regards. -- __ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Extensibility
On Wed, May 30, 2007 at 11:45:33AM -0300, Monique Monteiro wrote: simpler way to integrante new backends? I worked at Haskell.NET project in the past, when we integrated successfully a .NET code generator to GHC 6.2.2. Do you have any documentation or papers or anything about your .NET codegen? Is it the same (somewhat bitrotted) ILX codegen that exists in the current GHC tree? I'm actually working on a new GHC backend too and would be interested seeing yours. in GHC's code! I haven't yet figured out how to call the .NET code generator from GHC 6.6.1's main function. You'll probably want to look at hscCompile in main/HscMain.lhs. From there you can pick up either the Core, Core-Prepped, or STG representation of the module and pass it off to your backend. If by chance you want the C-- rep (although that probably won't be too useful for a .NET backend) you'll want codeOutput in main/CodeOutput.lhs. -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FW: GHC as a library
Good questions.
Fwding to GHC users, to get myself out of the inner loop
Simon
-Original Message-
From: Kenny Zhuo Ming Lu [mailto:[EMAIL PROTECTED]
Sent: 30 May 2007 12:44
To: Simon Peyton-Jones
Subject: GHC as a library
Dear Simon,
I would like to bother you with some questions regarding GHC-as-a-library.
I am currently planning to use/call GHC to infer/typecheck a given
haskell module my project.
I've been following the examples (in particular, the interactive evaluator)
in http://haskell.org/haskellwiki/GHC/As_a_library
In the following program I managed to parse and type check the given
Haskell module, (Test.hs)
using the call GHC.checkModule function.
\begin{code}
main = do
session - GHC.newSession GHC.JustTypecheck (Just Test.hs)
dflags1 - GHC.getSessionDynFlags session
(dflags2, packageIds) - Packages.initPackages dflags1
GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscNothing}
let name = Test.hs
target - GHC.guessTarget name Nothing
GHC.addTarget session target
GHC.load session GHC.LoadAllTargets
let preludeModule = GHC.mkModule (PackageConfig.stringToPackageId
base) (GHC.mkModuleName Prelude)
GHC.setContext session [] [preludeModule]
m_checkedModule - GHC.checkModule session (GHC.mkModuleName Test)
...
\end{code}
I am hoping to retrieve the inferred types of the declared Ids in Test.hs
At this stage, what I obtain is a value of type Maybe CheckedModule.
Then I looked into the definition of CheckedModule,
\begin{code}
data CheckedModule =
CheckedModule { parsedSource :: ParsedSource,
renamedSource :: Maybe RenamedSource,
typecheckedSource :: Maybe TypecheckedSource,
checkedModuleInfo :: Maybe ModuleInfo
}
\end{code}
I attempted to look inside two of them,
\begin{code}
typecheckedSource :: Maybe TypecheckedSource,
checkedModuleInfo :: Maybe ModuleInfo
\end{code}
In typecheckedSource, I can only access the function definitions with
type annotations, but not the data type declaration.
In checkedModuleInfo, I can only access the Names of the exported
entities, and but not their (inferred) types are not present.
So my question is, Where I can access the inferred types?
Could you please advice?
Thanks you very much.
Best Regards,
Kenny
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FW: GHC as a library
Hi Kenny,
\begin{code}
main = do
session - GHC.newSession GHC.JustTypecheck (Just Test.hs)
dflags1 - GHC.getSessionDynFlags session
(dflags2, packageIds) - Packages.initPackages dflags1
GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscNothing}
let name = Test.hs
target - GHC.guessTarget name Nothing
GHC.addTarget session target
GHC.load session GHC.LoadAllTargets
let preludeModule = GHC.mkModule (PackageConfig.stringToPackageId
base) (GHC.mkModuleName Prelude)
GHC.setContext session [] [preludeModule]
m_checkedModule - GHC.checkModule session (GHC.mkModuleName Test)
...
\end{code}
I am hoping to retrieve the inferred types of the declared Ids in Test.hs
At this stage, what I obtain is a value of type Maybe CheckedModule.
You can certainly get the type of an arbritrary expression in your project
module using something like the following:
ghcTypeCheck session expr modName =
unsafePerformIO(
do
Just ty - exprType session (modName ++ . ++ expr)
ty' - cleanType ty
return $ showSDoc $ ppr ty'
)
cleanType ty = do
return $! GHC.dropForAlls ty
That may be of some help...
Cheers,
Chris.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC as a library
| In typecheckedSource, I can only access the function definitions with | type annotations, but not the data type declaration. | In checkedModuleInfo, I can only access the Names of the exported | entities, and but not their (inferred) types are not present. You have easy access to the data decls: In a ModuleInfo is a TypeEnv. The range of the type env (gotten with typeEnvElts) are TyThings. A TyThing can be a Id a Class a TyCon a DataCon So just pull out those TyCons and away you go! (Lots of accessor functions for TyCons in module TyCon.) The Ids are the variables declared in the module, and they each have a type (use idType). In exchange, would you like to document what you have learned? Here for example: http://haskell.org/haskellwiki/GHC/As_a_library Many thanks Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Extensibility
Hi Brian, the documentation is available at http://php.cin.ufpe.br/~haskell/haskelldotnet/hsharp.php?m=references . It has nothing to do with ILX code generator. ILX codegen was an old project run by Don Syme ([EMAIL PROTECTED]). Thanks, Monique On 5/30/07, Brian Alliet [EMAIL PROTECTED] wrote: On Wed, May 30, 2007 at 11:45:33AM -0300, Monique Monteiro wrote: simpler way to integrante new backends? I worked at Haskell.NET project in the past, when we integrated successfully a .NET code generator to GHC 6.2.2. Do you have any documentation or papers or anything about your .NET codegen? Is it the same (somewhat bitrotted) ILX codegen that exists in the current GHC tree? I'm actually working on a new GHC backend too and would be interested seeing yours. in GHC's code! I haven't yet figured out how to call the .NET code generator from GHC 6.6.1's main function. You'll probably want to look at hscCompile in main/HscMain.lhs. From there you can pick up either the Core, Core-Prepped, or STG representation of the module and pass it off to your backend. If by chance you want the C-- rep (although that probably won't be too useful for a .NET backend) you'll want codeOutput in main/CodeOutput.lhs. -Brian -- __ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Extensibility
| is there any plan to improve GHC's extensibility by providing a | simpler way to integrante new backends? I worked at Haskell.NET ... | in GHC's code! I haven't yet figured out how to call the .NET code | generator from GHC 6.6.1's main function. Further, it would be great | if there was a better extensibility mechanism (such as a plugin | infrastructure, for example) in which it wasn't necessary to use | #ifdefalong the code. Also, it would be very useful if this Yes, good idea. I think the Right Way to do this is by elaborating the GHC API. At the moment it has a baked-in way of generating output files, but presumably by elaborating the interface one could allow either a) GHC returns some Core, and you finish the job, or b) you give to GHC a function to use for code generation This requires design work on the GHC API. As I remarked a couple of days ago, there's a chicken and egg problem with the GHC API. We have not been working hard on the API because we don't have lots of evidence of strong demand. And since it doesn't do today what you want, you find another way round. One good thing might be for someone to coordinate a set of use-cases. We'd like to do X and Y and Z with the GHC API. I'm thinking pretty specific stuff, with rough type signatures etc, not just the GHC API should support .net or should support dynamic linking.And names of the protagonists who can amplify. Next, we'd want to do some API design: just what interface would be good for users? None of this requires GHC HQ to be on the critical path -- and we know that putting us in the critical path slows processes down! It'd be sensible for us to comment early and often on the practicality of various possible proposed APIs, and I think we can do that. But we don't need to drive the process. Does that sound interesting in principle? i.e. are there half a dozen people who would like to use the GHC API if only it did X? (Or did Y better.) If so, would you like to get together and follow the sequence above? I know that you all have day jobs too! But I feel bad that we often no-op on good suggestions because there are Too Many Things To Do To GHC, so it makes sense to maximise opportunities for other people to play a leading role. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Extensibility
On 5/30/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | is there any plan to improve GHC's extensibility by providing a | simpler way to integrante new backends? I worked at Haskell.NET ... | in GHC's code! I haven't yet figured out how to call the .NET code | generator from GHC 6.6.1's main function. Further, it would be great | if there was a better extensibility mechanism (such as a plugin | infrastructure, for example) in which it wasn't necessary to use | #ifdefalong the code. Also, it would be very useful if this Yes, good idea. I think the Right Way to do this is by elaborating the GHC API. At the moment it has a baked-in way of generating output files, but presumably by elaborating the interface one could allow either a) GHC returns some Core, and you finish the job, or b) you give to GHC a function to use for code generation I think b) would be a more elegant option. Further, in Haskell.NET's current implementation, we receive the STG tree. Another question: was there any significant optimization or performance change in the front-end (ie.: generation of Core/STG tree) since GHC 6.2.2? Monique __ Monique Monteiro, MSc MCP .NET Framework 2.0 / SCJP / IBM OOAD Project Manager Recife Microsoft Innovation Center +55 81 34198137 http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown-freebsd.tar.bz2 yay! Ian will supply a link from the download page in due course, I'm sure. No documentation or ghci. The former might be easily remedied although using FreeBSD's docbook chain, as suggested in the wiki, fails when asked to generate printable docs. The latter seems to be a bigger project since my naive interpretation of the problem is that we need data relocations across a 2GB boundary. The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi Simon, On May 30, 2007, at 4:05 PM, Simon Marlow wrote: Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 yay! Ian will supply a link from the download page in due course, I'm sure. I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Should I ask for push permission or just send these via the usual darcs send route (now possible, since darcs builds on x86_64)? The x86-64 (or amd64 if you like) Linux port doesn't do relocation of data references outside 2Gb. It is the subject of this bug: http://hackage.haskell.org/trac/ghc/ticket/781 the underlying problem is that the relocatable reference is only 32 bits, because we're working in the small memory model, but the address of the symbol might be outside the current 2Gb slice, because it's in a shared library somewhere. The system linker solves this by relocating the data itself from the shared library into the main program's 2Gb slice (I think), but we can't do this in GHCi. Hmm. I would have thought that the absolute addresses of static data in the shared library would have been resolved by the run time loader and written into the global offset table. It seems that all of the shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB, e.g., above 0x8. Perhaps rtld allocates space below 2GB and fills in adjusts the GOT to point to the data in lower memory. (There's not very much of it). I'll have to think about this a while. Fortunately most code doesn't reference static data from shared libraries, so we get away with it most of the time. FreeBSD/amd64 seems to make a lot of references to static data. When I edited the Linker to ignore out of range relocations and print a message I got dozens while starting GHCi. Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to create a GHC binary bundle?
Ian Lynagh wrote: Hi Maxime, On Sun, May 27, 2007 at 03:58:47AM +0200, Maxime Henrion wrote: To be more precise, I want to know how to create the ghc-$version-$arch-boot.tar.bz2 file to redistribute to users so that they can build GHC easily, and that on a platform that already has a working (but older) GHC installation. So far, I've been able to find out that I want to use the binary-dist make target, and that this requires me to put BIN_DIST=1 in mk/build.mk. Other than that, I'm pretty much lost. That's basically it. Assuming you're using a released GHC: echo BIN_DIST=1 mk/build.mk ./configure make make binary-dist stage=2 It doesn't currently work in the HEAD, but I'm working on that. Thanks Ian! I'm glad to finally know the precise incantations needed to build a GHC binary bundle :-). And while I'm here, thanks to Simon for letting me know my mail wasn't just ignored. I guess it's now time to update the FreeBSD GHC port to 6.6.1! Cheers, Maxime ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Replacing select() in the non-threaded RTS?
I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? b ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing select() in the non-threaded RTS?
On Wed, May 30, 2007 at 09:21:36PM -0700, Bryan O'Sullivan wrote: I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? I don't beleive the GHC team would be interested in receiving any patches to the non-threaded RTS, since it is scheduled for removal in 6.8 IIRC (leaving only threaded). Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
