March 2009 - jhc - Haskell.org

Compile OpenGL for jhc
by Csaba Hruska 27 Mar '09

27 Mar '09

Hi! As OpenGL haskell binding depends only on base, it would be great to compile it with jhc. I've tried to do that, but I had some problems with preprocessor directives. It would be also great to add jhc support for OpenGL bindings build scripts. Or, it would be better to add jhc support for cabal-install. :) Is there anyone who has any idea any of this things? (for soulution)

2 3

Cheaper Mobile Cellphone Calls...
by Cheaper Mobile Cellphone Calls... 25 Mar '09

25 Mar '09

1 0

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by Don Stewart 25 Mar '09

25 Mar '09

sylvain.nahas: > Hi, > > This compiler is very promising, for the least. > > Here is a small dummy Haskell program. > countdown :: Int -> IO () > countdown 0 = putStrLn "finished" > countdown x = do > putStrLn (show x) > countdown (x-1) > main = countdown 10000000 > > and the C program that comes to closest. > #include <stdio.h> > int main(void) > { > int i; > for(i=0; i<10000000; i++) > { > printf("%d\n",i); > } > printf("finished\n"); > return 0; > } > > GHC is 6.10.1, gcc is 4.3.2, jhc is 0.6.0 > arch is i386/Linux(Ubuntu) > > $ ghc hello.hs -o hello1 > $ jhc hello.hs -o hello2 > $ gcc hello.c -o hello3 Oh boy. Compile with optimizations on please! ghc -O2 et al.

5 5

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by Don Stewart 25 Mar '09

25 Mar '09

peter.vers: > > On Sat, Mar 21, 2009 at 10:00 AM, Don Stewart <dons(a)galois.com> wrote: > > ghc-pkg hide transformers-0.1.1.0 > > But that is an global change no? Can this be configured in the cabal file? > > -hide-package in a Makefile. Cabal handles this automatically for you, by hiding everything by default, and then enabling only those things explicitly listed.

1 0

ANNOUNCE: jhc 0.6.0 Haskell Compiler
by John Meacham 24 Mar '09

24 Mar '09

Hi, I am pleased to announce jhc 0.6.0, It has been a long time since an official release, so there have been a lot of changes. Jhc is an optimizing haskell compiler that focuses on creating fast and portable code. Jhc is still mainly of interest to jhc hackers and developers than the general haskell public, but it is starting to see use in embedded development with haskell so I decided to make more public announcements of major releases in the future. some links: The jhc homepage: http://repetae.net/computer/jhc/ Installation Instructions: http://repetae.net/computer/jhc/building.shtml The jhc manual: http://repetae.net/computer/jhc/manual.html And I am happy to announce, there is now a yum repository* for jhc and my other projects (such as DrIFT), so if you use an rpm based linux distribution, you can keep up to date with jhc official releases by doing: ; rpm -i http://repetae.net/yum/repetae-repo-1.0-3.noarch.rpm ; yum install jhc A couple recent changes: jhc now comes bundled with the 'containers' and 'applicative' library making it much easier to compile many haskell programs out there. (Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree, Control.Applicative, Control.Arrow, Control.Category, Data.Foldable, Data.Traversable) signifigant speed and resource usage improvements in compilation time. transparent cross compilation support for creating windows programs on a unix box. (or iPhone/Nokia Tablet/etc..) If you are interested in jhc development, please sign up on the jhc mailing list here: http://www.haskell.org/mailman/listinfo/jhc John * I would love to get proper 'deb's and BSD packages built also automatically, if anyone wants to help with this, please join the list and let us know. -- John Meacham - ⑆repetae.net⑆john⑈

6 7

Microsoft Customer Lists
by mike gordon 23 Mar '09

23 Mar '09

We are pleased to announce the availability of the following Microsoft customer lists: Sharepoint Dynamics SQL Exchange Biztalk FRX CRM System Center Visual Studio VAR If you would like more information or a sample off any of our lists, please contact us at (905) 721-8456 or email us at repharm1(a)aol.com, Also we have the following lists as well Below are just some of the lists available: ERP (ENTERPRISE RESOURCE PLANNING): Baan JD Edwards Lawson Made2Manage Mapics Marcam Oracle Peoplesoft SAP SSA E-BUSINESS APPLICATIONS: Ariba BMC BroadVision Commerce One Webtrends MIDDLEWARE/CONNECTIVITY/APP SERVERS/WEB SERVERS: Bea Systems Iona Unisys OPERATING SYSTEMS/HARDWARE/SOFTWARE: COMPAQ HP 3000 HP 9000 HP-UX IBM AS/400 IBM OS/390 Lotus Notes Microsoft Sun Microsystems DATABASE: DB2 FileMaker Informix Oracle SQL SybaseCRM (CUSTOMER RELATIONSHIP MANAGEMENT): Clarify E.piphany HNC Onyx Pivotal Siebel Vantive Xchange SUPPLY CHAIN: Agile i2 Technologies Manugistics QAD Webplan COMMUNICATIONS: Nortel Cisco 3com Siemens Alcatel Telecom Vars ASP’s CLECS ISP’s E-COMMERCE: Dot Com Directory Consultant Directory Software Directory EXECUTIVE DIRECTORIES: Chief Executive Officer Chief Financial Officer Chief Information Officer Engineering Human Resources Purchasing Sales/Marketing INDUSTRY SPECIFIC LISTS: Agriculture, Forestry and Fishing, Communications, Construction, Finance, Insurance and Real Estate, Manufacturing, Mining, Public Administration, Retail Trade, Services, Transportation, Utilities, Wholesale Trade

1 0

some jhc weirdness
by sylvain 21 Mar '09

21 Mar '09

Hi, after having adapted "binaries-tree" from http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=… to remove the dependency on Text.Printf (program below), I get the following results. 1. reference run. $ghc --make -O2 -fglasgow-exts -fasm prog.hs -o prog.ghc $./prog.ghc 1 "stretch tree" of depth 7 check: -1 "128 trees" of depth 4 check: -128 "32 trees" of depth 6 check: -32 "long lived tree" of depth 6 check: -1 2. jhc run. $jhc -o prog of depth 77 check: -1 of depth 44 check: -128 of depth 66 check: -32 of depth 66 check: -1 $ ./prog.jhc 18 of depth 1919 check: -1 segmentation fault Maybe is it time to set up a bug tracker :) Sylvain --snip-- import System import Data.Bits -- -- an artificially strict tree. -- -- normally you would ensure the branches are lazy, but this benchmark -- requires strict allocation. -- data Tree = Nil | Node !Int !Tree !Tree minN = 4 io s n t = putStrLn (show s++" of depth "++(show n)++" check: "++(show t)) main = do n <- getArgs >>= readIO . head let maxN = max (minN + 2) n stretchN = maxN + 1 -- stretch memory tree let c = check (make 0 stretchN) io "stretch tree" stretchN c -- allocate a long lived tree let long = make 0 maxN -- allocate, walk, and deallocate many bottom-up binary trees let vs = depth minN maxN mapM_ (\((m,d,i)) -> io (show m ++ " trees") d i) vs -- confirm the the long-lived binary tree still exists io "long lived tree" maxN (check long) -- generate many trees depth :: Int -> Int -> [(Int,Int,Int)] depth d m | d <= m = (2*n,d,sumT d n 0) : depth (d+2) m | otherwise = [] where n = 1 `shiftL` (m - d + minN) -- allocate and check lots of trees sumT :: Int -> Int -> Int -> Int sumT d 0 t = t sumT d i t = sumT d (i-1) (t + a + b) where a = check (make i d) b = check (make (-i) d) -- traverse the tree, counting up the nodes check :: Tree -> Int check Nil = 0 check (Node i l r) = i + check l - check r -- build a tree make :: Int -> Int -> Tree make i 0 = Node i Nil Nil make i d = Node i (make (i2-1) d2) (make i2 d2) where i2 = 2*i; d2 = d-1 --snip--

3 2

some more jhc weirdness
by sylvain 21 Mar '09

21 Mar '09

Hi, I have rewritten the program in my previous mail. io s n t = do putStr s putStr " of depth " putStr (show n) putStr " check: " putStrLn (show t) With this workaround, the ghc and jhc generated programs give the same output. Let do some speed comparison. $ ghc --make -O2 -fglasgow-exts -fasm prog.hs -o prog.ghc $ jhc prog.hs -o prog.jhc You can get a reference C version, supposedly optimized, here: http://shootout.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=… $ gcc -pipe -Wall -O3 -fomit-frame-pointer -march=native -lm prog.c -o prog.gcc below are the results for the third run (to mitigate cache miss effect) of each program: $ time ./prog.ghc 17 real 0m5.606s user 0m5.104s sys 0m0.032s $ time ./prog.gcc 17 real 0m5.269s user 0m5.264s sys 0m0.004s C is faster than GHC Haskell, things are in order. $ time ./prog.jhc 17 real 0m2.656s user 0m1.364s sys 0m1.048s What is wrong with my computer, I wonder? :) Sylvain Nahas

1 0

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by John Meacham 20 Mar '09

20 Mar '09

nice, although not quite fair, as jhc always has optimization turned on, so compiling the others with -O is more appropriate. The 'show' instance is clearly eating up most of the time in the jhc version, if you look at the generated C code. here is main as generated by jhc annotated with the haskell it cooresponds to in the comments : static void A_STD ftheMain(void) { // passing in 100000000 to countdown uint32_t v184744394 = 10000000; // countdown :: Int -> IO () fW_a__fMain__fl_aMain__countdown_d43_u8:; { sptr_t v261990436 = ((sptr_t)VALUE(v184744394)); // check if it is zero if (0 == v184744394) { // putStr "finished" fPrelude__IO__putStr(c8); // putChar '\n' return (void)jhc_utf8_putchar((int)10); } else { // let s = show x wptr_t v100000 = fInstance_a__iJhc__Show__show__default(v261990436); sptr_t v118875000 = demote(v100000); // putsStr s fPrelude__IO__putStr(v118875000); // putChar '\n' (void)jhc_utf8_putchar((int)10); // jump to countdown with x = x - 1 uint32_t v14532078 = (v184744394 - 1); v184744394 = v14532078; goto fW_a__fMain__fl_aMain__countdown_d43_u8; } } } John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

Re: [Haskell] ANNOUNCE: jhc 0.6.0 Haskell Compiler
by Taral 19 Mar '09

19 Mar '09

2009/3/18 Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu>: > I suspect if you profile you'll find that Haskell's show is faster than C's > printf, especially if the appropriate show instance is selected at compile > time. Probably why the executable is bigger, too. Try static linking if you want apples-to-apples. -- Taral <taralx(a)gmail.com> "Please let me know if there's any further trouble I can give you." -- Unknown

1 0