RE: how and where to {-# specialize #-} ?

| > The only workaround is to define T early, | > import it into A, and specialise A.f there. | | What if A is a pre-defined module, say FiniteMap? | Then I can't change its source text. (Which isn't even there.) | (Of course, I can grab it from the source distribution.) | | It is sad that the usage of libraries containing polymorphic code | (which is a good thing, for obvious software engineering reasons) | seems to imply runtime overheads, by preventing specialisation. | I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work s

| It is sad that the usage of libraries containing polymorphic code | [...] | seems to imply runtime overheads, by preventing specialisation.
I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work
One way of tackling it would be to change ghc so that compilation doesn't produce .o files containing machine code but, rather, files containing a concise encoding of STG code. One possible concise encoding would be as bytecodes. (With just a little care over their design, you can easily uncompile bytecodes to recover the original code so we're not losing any information.) Obviously, ghci could interpret this code directly but it would take little more work to have ghci compile the bytecode to machine code. There's been lots of research into how to do this effectively by both the Forth and the Java communities. This case ought to be easier because STG code has already had a very powerful optimizer applied to it so all that's left is doing a good job with register allocation and pipelining. That same compilation engine could also be used in linking: read a bunch of bytecodes, compile to machine code, write out a .o file to be linked against the runtime and any C libraries. The 'unoptimized, portable' variant of this could either generate C code for compilation by gcc or, easier still, leave them as bytecodes and include a bytecode interpreter in the system. Benefits: I think the result would be more portable (because there is always the interpreter to fall back on). Instead of the ghc folks shipping a bunch of .hc files for porting purposes, they would ship a load of bytecode files. [Of course, it won't eliminate all porting issues: Windows and Solaris differ in more ways than just their processor...] This technology would support things like template Haskell and persistence research nicely. An optimizer can easily get hold of any source code it needs by dipping into the compiled files when it wants and decompiling the bytecodes. Of course, none of this negates Simon PJ's comment that it would be Real Work. -- Alastair Reid

On Wed, 25 Jun 2003 10:18:17 +0100
Alastair Reid
| It is sad that the usage of libraries containing polymorphic code | [...] | seems to imply runtime overheads, by preventing specialisation.
I agree that it is sad. The only way around it is to ship libraries with *all* their source code (perhaps hidden in the interface file). That could be done, but it'd be Real Work
One way of tackling it would be to change ghc so that compilation doesn't produce .o files containing machine code but, rather, files containing a concise encoding of STG code. One possible concise encoding would be as bytecodes. (With just a little care over their design, you can easily uncompile bytecodes to recover the original code so we're not losing any information.)
Something similar was proposed by the gcc folk at their recent conference. The idea is that when you gcc -O4 your .c files, you get .o files containing an intermediate typed SSA form. Upon linking the program, gcc invokes a 'smart linker' which runs another pass on the whole program. This allows for all kinds of cross-module inlining, specialisation etc. http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf pg 121, Architecture for a Next-Generation GCC Duncan
participants (3)
-
Alastair Reid
-
Duncan Coutts
-
Simon Peyton-Jones