haskell:
I can confirm this performance bug with GHC version 6.6.1 on OS X PCC (G4)
Leopard.
It performs correctly, lazily keeping 'primes' for all 4 repetitions, when
using ghc -Onot but the the doSlow fails to retain 'primes' when
compiling with ghc -O and ghc -O2
Sounds like the
jpvogel1:
I am running my program in WinXP with ghc 2.6.8
If you install netstat and change the parameters it should still work in
linux.
Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?
I can't use the sleep
Great!
Does this mean we can submit GHC to be distributed from Apple's
hackage, http://www.apple.com/downloads/ ? (Click the Submit Downloads
button).
-- Don
chak:
Ladies and Gentlemen,
Finally, you can have the glorious GHC in a format satisfying the
discerning Mac user:
chak:
Don Stewart:
Great!
Does this mean we can submit GHC to be distributed from Apple's
hackage, http://www.apple.com/downloads/ ? (Click the Submit
Downloads button).
Yes, I was thinking about that, too. However, I think we should wait
until 6.8.3 and until we have a stable
jason.dusek:
I have an awkward programming problem -- I need to take a
dictionary, parse it, build a bunch of intermediate lists and
then make maps and tries out of the list. A programming
problem because it's taken me a fair amount of effort to pull
together the parser and list
jason.dusek:
Don Stewart [EMAIL PROTECTED] wrote:
You can build large constant bytestrings, fwiw. They turn into
an Addr#, and GHC will leave them alone.
Well, for my particular problem -- I guess I could align all
the elements of the lists, and then build the trie and maps
from
jay:
Jason Dusek [EMAIL PROTECTED]:
I have an awkward programming problem -- I need to take a
dictionary, parse it, build a bunch of intermediate lists and
then make maps and tries out of the list. A programming
problem because it's taken me a fair amount of effort to pull
together
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try bytestring literals (and maybe parsing them in-memory
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases
jason.dusek:
I have an awkward programming problem -- I need to take a
dictionary, parse it, build a bunch of intermediate lists and
then make maps and tries out of the list. A programming
problem because it's taken me a fair amount of effort to pull
together the parser and list
Hey Johan,
The main thing to remember is that anything you wish to match on
in a rule needs to not be inlined in the first pass.
So to match many or satisfy robustly, you'll need:
{-# NOINLINE [1] many #-}
For example.
johan.tibell:
Hi,
I'm trying (for the first time ever) to use
johan.tibell:
On Thu, Mar 13, 2008 at 11:24 PM, Don Stewart [EMAIL PROTECTED] wrote:
Hey Johan,
The main thing to remember is that anything you wish to match on
in a rule needs to not be inlined in the first pass.
So to match many or satisfy robustly, you'll need
bbr:
Simon Peyton-Jones wrote:
GHC does a lot of cross-module inlining already, and *does* write stuff
into interface files, provided you use -O.
I used -O4. Is that the bad thing?
There's nothing about -O2
However, I think that's ok -- it clamps -ON | N2 to -O2
I'm always
igloo:
On Wed, Mar 19, 2008 at 05:31:08PM +, Ian Lynagh wrote:
On Tue, Mar 18, 2008 at 04:12:35PM -, GHC wrote:
(don't worry, this often catches me out too. Perhaps a strict let
should be indicated more explicitly in `-ddump-simpl`).
I'd certainly find it useful if it
bbr:
I suspect that if all modules are compiled -O0, then you recompile one
module with -O2, high up in the dependency graph (i.e. it depends on
many lower-level modules), plus all things that in turn depend on it
(--make), you will not get the good performance you expect. None of the
I think it would make sense to announce this on [EMAIL PROTECTED]
too , which has a much broader readership.
fegaras:
I would like to announce the release of HXQ: A Compiler from XQuery to
Haskell.
HXQ is a fast and space-efficient translator from XQuery (the standard
query language for
conal:
I'd like to know if it's possible to get GHC to perform some simple CSE
for function-level programming. Here's a simple example:
liftA2 (*) sin sin :: Double - Double
which inlines and simplifies to
\ t - sin t * sin t
A more realistic, equivalent,
chak:
Yitzchak Gale:
OK for the time
being, but it would be really, really good to be able to compile
ghc without gmp.
Well, just go ahead and write an alternative portable high-
performance implementation of Integer.
This idea of a Mac OS X binary with statically-linked
gmp is nice,
jimmyguang2005:
Hi!
the ghc compiler keeps complaing can't find module 'Char', perhaps you
haven't installed the profiling libraries for package haskell98?.
but actually I did install it, and i checked with ghc -v , it is right
there:
wired-in package haskell98 mapped
Geraint.Jones:
Are there well-known differences in the implementations of Haskell in
ghci and hugs? I've got some moderately intricate code (simulations
of pipelined processors) that behave differently - apparently because
ghci Haskell is stricter than hugs Haskell, and I cannot find any
ndmitchell:
Hi
(All these results are from GHC 6.9.20071226, but suspect they hold
for 6.9.* and 6.8)
The following code:
test = head neil
Produces (with -O2):
Text.HTML.TagSoup.Development.Sample.test =
case GHC.Base.unpackCString# neil of wild_aaU {
[] - GHC.List.badHead
dons:
ndmitchell:
Hi
(All these results are from GHC 6.9.20071226, but suspect they hold
for 6.9.* and 6.8)
The following code:
test = head neil
Produces (with -O2):
Text.HTML.TagSoup.Development.Sample.test =
case GHC.Base.unpackCString# neil of wild_aaU {
ndmitchell:
Hi
The first case makes sense, and is just a RULE. Though it seems GHC already
does this?
g = head
goes to:
M.g = badHead @ Char
without prompting.
Nope, as far as I can tell gets translated to [], not
unpackCString# - hence the unpack never
ndmitchell:
Hi
That would work on GHC, but not on Hugs.
Optimisation and Hugs don't go together anyway.
I want the code to work on Hugs, and perform fast on GHC. As it turns
out, for this particular application, Hugs is faster than GHCi by
about 25%.
Optimisation and ghci don't
ndmitchell:
Hi
Optimisation and ghci don't go together, so I don't know what your point
is there.
It's very worth having the application work in both Hugs and GHCi, and
its not always GHC=faster, only if you compile it - so you trade your
compile time for your run time. A delicate
ndmitchell:
Hi
what is general purpose stuff. I don't think there is anything wrong with
magic for primitive
types, but if there is a useful general-purpose mechanism trying to get
out, let's liberate it.
I think the tension comes from representing String's as CString's, not
ndmitchell:
Hi
Cons: Makes the simplifier slightly more complex - but I hope not by
much!
And it doesn't work for my case -- I'd really want length as a compile
time constant.
Could you elaborate on what kind of rules you think we could write with
the ability to get the
igloo:
On Mon, Apr 28, 2008 at 02:00:38PM -0700, Donald Bruce Stewart wrote:
This goes back to an old gripe of mine actually -- we can't get
at the length of a C string literal at compile time either, which
would be super useful in rules.
I think that this is easy to do by, instead of
hp:
I convinced myself that the ~500kbytes for the
'hello' code is 'correct' in version 6.6.1.
[ The exact size on the platform mentioned below
is 422k. ]
Looks like version 6.8.2 blows up the binary code size
significantly --- 3.9Mbytes vs 0.422Mbytes.
Is this a known issue with
alexander.fuchs:
Hi there,
I am trying to write my first serious Haskell program, but have
problems understanding 'strange' performance results. It seems to be
a ghc specific question, so I am asking here.
In a happy parser I have this code 1):
%monad { Parsed } { thenP } { returnP }
alexander.fuchs:
Hi Don.
Could you submit a minimal, complete grammar file, so
we can look at the generated code?
After reducing and simplifying the grammar file to the minimum for my
sample input I can't see any difference in performance anymore. Due to
other code changes the difference
sedillard:
Hi Everybody,
I'm experiencing some undesirable performance behavior, I suspect from
inlining things that shouldn't be, defeating my memoization attempts.
I've been experimenting with purely functional 3D modeling code, so a
mesh is (initially) something like
type Mesh = Map
I discovered something today I didn't know.
gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
Consider this program,
import Data.Array.Vector
import Data.Bits
main = print . sumU
. mapU (*2)
. mapU (`shiftL` 2)
duncan.coutts:
On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote:
Hello Don,
Thursday, May 15, 2008, 10:47:20 PM, you wrote:
I discovered something today I didn't know.
gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
seems that decision to
what causes ghc to emit a stub.c file? - Conal
the use of 'foreign export' - Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bulat.ziganshin:
Hello Duncan,
Friday, May 23, 2008, 11:55:57 PM, you wrote:
me too. btw, this already present in jhc. inlining doesn't work in any
complex case since recursive functions can't be inlined
GHC inlines recursive functions, too, otherwise it could not turn 'foldl'
jakubuv:
Hi,
I'm trying to find out how the GHC rewrite rules pragma work, but I'm
not able to make it working. I have this simple example, where I would
like to specialize the function gen to spec on strings:
{-# OPTIONS -O2 -fglasgow-exts #-}
gen :: [a] - a
gen = head
{-# RULES
jakubuv:
Thanks lot, it works now. Now, I have just a simple question:
Is there any chance to make rewriting working in ghci ?
I think you can actually enable them by putting:
{-# OPTIONS -frewrite-rules #-}
at the top of the file to be interpreted. Works for me, anyway.
-- Don
marlowsd:
Hi Folks,
6.8.3 is nearing release, and we have an outstanding bug affecting the
GHCi on the BSDs:
http://hackage.haskell.org/trac/ghc/ticket/2013
We need someone to help out with this. The patch in the ticket apparently
works, but can't be committed as is because it
Hello Serge,
I was looking at the cabal file used to build docon,
I note the current flags are:
ghc-options:
-fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances
-fno-warn-overlapping-patterns -fwarn-unused-binds
-fwarn-unused-matches
trebla:
I do not have a platform to try it on; the following is pure speculation.
In main, the builder of input is highly lazy, since randoms is. To be
sure, the spine of the list is presently forced by printing its length,
but the numbers inside the list... It is very bleak because
claus.reinke:
Here it is:
{-# OPTIONS_GHC -O2 -Wall -fglasgow-exts -ddump-simpl #-}
-- compile with: ghc -fno-method-sharing -c F.hs
thanks! it seems i misread the users guide (or is this a bug?).
i used -frewrite-rules (Switch on all rewrite rules), which
does not(!) work, instead of
claus.reinke:
Right. There are two things here:
1) -frewrite-rules
enables rules to fire.
2) -fglasgow-exts
enables parsing of RULES pragmas, and their interpretation.
You need both if you wish to both write your own rules, and have them
fire.
nope!-) -fglasgow-exts is
claus.reinke:
nope!-) -fglasgow-exts is sufficient for the RULE to be parsed
and applied in Lennart's code, -frewrite-rules doesn't seem to
serve any noticable purpose.
Well, if -O is on, -frewrite-rules is already on by default.
Try -fno-rewrite-rules with -O to turn them off specifically,
dons:
sedillard:
Hi,
I've got a library that I'm in the process of uploading to hackage
(waiting for account) but the darcs repo is here:
[1]http://graphics.cs.ucdavis.edu/~sdillard/Vec
I notice a slight drop in performance when I install the library using
sedillard:
That said, it's entirely possible to program libraries in a way to
specifically allow full inlining of the libraries. The Data.Binary and
Data.Array.Vector libraries are written in this style for example,
which means lots of {-# INLINE #-} pragmas, maximum
sedillard:
I can't reproduce the behavior on any of the less egregiously inlined
functions. For everything else the running times are the same using either
local packages or installed libraries.
On Tue, Jun 24, 2008 at 3:16 PM, Ian Lynagh [EMAIL PROTECTED] wrote:
On Tue,
sedillard:
On Tue, Jun 24, 2008 at 3:51 PM, Don Stewart [EMAIL PROTECTED] wrote:
I've taken all optimization flags out of the .cabal file. They
don't have
any effect. My understanding of things is this: (please correct if
wrong)
All functions
conal:
I want to use ghc-6.9 for improved support of type families, but I see
that the change to the Arrow interface breaks some of my libraries (since
() is no longer a method of Arrow). Will this change really be in
() has been reexported from Control.Category through Arrow for a
claus.reinke:
I seem to recall someone mentioning a tool for normalizing
the output of things like -ddump-simpl to make diffs easier
by reducing irrelevant differences due to gensym-generated
names. Was that just wishful thinking, or does such a thing exist?-)
I would also find such a tool
marlowsd:
Following lots of useful discussion and evaluation of the available DVCSs
out there, the GHC team have made a decision: we're going to switch to git.
Hooray, this will generate a lot of open source good will, and help make
GHC more accessible to the outside world.
Just see the
dons:
chak:
Ian Lynagh:
On Fri, Aug 08, 2008 at 12:04:15PM +1000, Manuel M T Chakravarty
wrote:
I seriously hope the plan is to move all *core* libraries (including
GHC's cabal repo) etc over to git, too. In other word, everything
that you need to build the development version
kili:
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
[...]
As for Cabal - we had a thread on cvs-ghc last week, and as I said there
we'd love to hear suggestions for how to improve things, including wild
and crazy ideas for throwing it all away and starting again. However,
I think we're all rather excited about seeing this stuff land.
What's the expected timeline, wrt. ghc 6.10's release?
-- Don
t-jodias:
I've added some text and links to point the reader in the right
direction. Here's the new text, cribbed from the Wiki:
Dataflow optimization: We can define
bulat.ziganshin:
Hello glasgow-haskell-users,
when GHC builds executable, it adds debug info by default. since this
info is useless for Haskell and since it significantly increases
executable size, will it be better to delete it by default by passing
-optl-s option to the linker?
another
leledumbo_cool:
Don Stewart-2 wrote:
Use cabal to build your application. It strips the applications for you,
in a portable manner.
Even if it's only a single module program? That's far too complicated!
It depends on if you want to deploy the code, and if you want to do it
portably
leledumbo_cool:
Sometimes it's annoying to call strip --strip-all program name everytime
after compilation. Is there anything like gcc's -s so that debugging symbols
aren't included?
Use cabal to build your application. It strips the applications for you,
in a portable manner.
duncan.coutts:
Hi,
We're getting pretty close to a final ghc-6.10.1 release. We would like
of course for the transition this time to be less painful than last
time. We all got a lot of flack last time for having no plan in place
and making everyone change all their .cabal files etc.
This
duncan.coutts:
On Thu, 2008-10-09 at 12:47 -0500, Paulo Tanimoto wrote:
Hi Duncan,
On Thu, Oct 9, 2008 at 10:28 AM, Duncan Coutts
[EMAIL PROTECTED] wrote:
On Thu, 2008-10-09 at 10:20 +0200, Jean-Philippe Bernardy wrote:
On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts
[EMAIL
jeff.polakow:
We have a server that accepts messages over a socket, spawning threads to
process them. Processing these messages may cause other, outgoing
connections, to be spawned. Under sufficient load, the main server loop
(i.e. the call to accept, followed by a forkIO), becomes
jgoerzen:
Duncan Coutts wrote:
There are actually more instances than this in the code, but I already
have fixed it in my git tree. I guess it's time to make a release.
Yay!
Between that and a bump for the time lib we'll probably have another ~50
packages building with 6.10.
Quick summary of the latest hackage state, now hslogger has been
amended.
x86_64/linux/ghc-6.10/cabal-install 0.6/Cabal 1.6
1 UnpackFailed
2 DownloadFailed
2 InstallFailed
16 ConfigureFailed
71 DependencyFailed
138 BuildFailed
447 InstallOk
So you can see
OK, so we have *56* packages total that no longer compile with GHC 6.10, but
did with 6.8.3. We can now see exactly what broke and why.
I think these potential breakage issues, and how to solve them canonically ,
should be documented on the wiki. Most should have standard solutions, some
might
claus.reinke:
We've been using the cabal-install build reporting stuff to get more
detailed info on build failures with ghc-6.10 vs 6.8. cabal-install
generates these build-reports.log files and individual log files for
each build.
Since you do have the infrastructure set up: haddock is
http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GHC_6.10
It collects the 7 or so known issues that break code with GHC 6.10.
Please feel free to clean up, and especially *add techniques for
handling each change*.
If we do this right, with cabal-install being smart, clear
niklas.broberg:
So there is a compatibility module in the new syb. Unfortunately,
that won't tell you about the moves and rationale. Most of the time,
you'll want Data.Data (check ghc -e ':browse Data.Data' or the
Haddock pages, or google for syb in the libraries@ archives):
$
bulat.ziganshin:
Hello Don,
Saturday, October 11, 2008, 9:21:47 PM, you wrote:
It collects the 7 or so known issues that break code with GHC 6.10.
i've quickly tried to compile my app with 6.10 (using base4). all the
problems i got was due to exception handling. catch, finally, throwIO
bulat.ziganshin:
Hello Don,
Saturday, October 11, 2008, 9:54:10 PM, you wrote:
seems that i misunderstood it: i thought it's a list of base4 vs base3
changes, but actually it seems like a base30 vs base31?
base3 - base4 upgrade hints are not documented anywhere?
It's a list of how to
Daily update of the state of Hackage wrt. GHC 6.10 release candidates.
Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6
were also put out. Things are in a good shape.
Note that you'll need a soft dep in your cabal index file,
base 4
parsec 3
HaXml == 1.13.*
Hey all.
The GHC 6.10 RCs are out, and we're preparing the release. To help manage the
transistion to GHC 6.10 it is now possible to actually build all the 3rd party
Haskell packages, and publish their results wrt. the release candidate.
For the first time ever, we're able to have all the 3rd
marlowsd:
Don Stewart wrote:
Note that these builds are with soft deps, provided on hackage,
base 4
parsec 3
HaXml == 1.13.*
QuickCheck 2
which train cabal-install to build a larger set of packages.
Will this happen automatically somehow, or will users have to do
Hey all.
The GHC 6.10 RCs are out, and we're preparing the release of GHC proper.
To help manage the transistion to GHC 6.10 it is now possible to
actually build all the 3rd party Haskell packages, and publish their
results wrt. the release candidate.
For the first time ever, we're able to have
dgorin:
I've tried adding some signatures (together with -
XScopedTypeVariables), but with no luck. Why is it that this no longer
compiles? More importantly, how can I make it compile again? :)
If you work out how to make it compile, can you document the soln. here,
schlepptop:
Don Stewart schrieb:
numeric-prelude-0.0.4
Easy: Lanuage pragma
My question was still not answered: I used the non-existing pragma
LANGUAGE_HOW_CAN_WE_ENABLE - I hoped it would be ignored, but it was
parsed and made GHC fail. Why? Bug or feature?
Feature
twhitehead:
Consider the following code
data Data = Data { unData :: !Int }
func :: Data - Int
func x = case unData x of
1 - 2
_ - 0
Compiling with GHC 6.8.2 gives the following stg code
Main.func =
\r [x_slg]
case x_slg of tpl_slx {
twhitehead:
On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote:
On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:
BUT people who care probably UNPACK their strict fields too, which
is even better. The time you can't do that is for sum types
data T = MkT ![Int]
twhitehead:
On Thursday 16 October 2008 14:34:01 Don Stewart wrote:
FWIW, I get much nicer code with uvector (which uses type families
to select monomorphic instances of things, and aggressive inlining, to
yield much better code in practice). The DPH arrays library uses
a similar method
magicloud.magiclouds:
Hi,
I want to install ghc 6.10. Well
I installed ghc 6.6.1 (binary distribution), and cabal, happy, alex
(all from darcs, the latest version). Then darcsed 6.10's source. And made.
I got: templates/GenericTemplate.hs:47:21: parse error on input
`#',
g9ks157k:
Am Samstag, 11. Oktober 2008 09:36 schrieb Duncan Coutts:
All,
We've been using the cabal-install build reporting stuff to get more
detailed info on build failures with ghc-6.10 vs 6.8. cabal-install
generates these build-reports.log files and individual log files for
each
claus.reinke:
I keep wanting to use DiffArray as the natural functional solution to
single-threaded array use. But everytime I try, I get smacked over
the head with the actual performance figures. Sometimes, even plain
arrays are faster in a loop doing array updates, in spite of all the
jeff.polakow:
Hello,
You will be even more surpised to find out that:
bar = (fst foo, snd foo)
is considered correct. Does this hint give you any insight?
This tells me that GHC definitely has a bug, or at at best an infelicity.
Hey Jeff,
File a bug here
duncan.coutts:
On Fri, 2008-11-07 at 13:02 -0800, Don Stewart wrote:
Does anyone know how libedit is supposed to be configured? readline
uses /etc/inputrc but libedit either does not or doesn't understand all
of it.
/me wonders if it was really necessary to switch from readline
judah.jacobson:
On Sun, Nov 9, 2008 at 6:42 AM, Duncan Coutts
[EMAIL PROTECTED] wrote:
On Sun, 2008-11-09 at 01:49 +, Ian Lynagh wrote:
On Sat, Nov 08, 2008 at 12:33:57PM -0800, Judah Jacobson wrote:
bind \e[3~ ed-delete-next-char
It's a shame this doesn't just work out of the
james.swaine:
We've had unbelievable problems getting past this ridiculous 'unable to
load object file or shared library libedit.so.0' error when attempting to
build the 6.10.1 source tree. We initially just built editline in a user
directory and attempted to manipulate
This is a straight forward ld.so path problem, by the sounds of it.
Are you sure you're setting ld environment search paths correctly?
-- Don
james.swaine:
that didn't fix the problem - i still get the same error message. the
configure script help should be updated though to show that
doesn't include /usr/local/lib, do you
think this might be the problem?
-james
On Fri, Nov 14, 2008 at 1:00 AM, Don Stewart [EMAIL PROTECTED] wrote:
james.swaine:
We've had unbelievable problems getting past this ridiculous
'unable to
load object file
at 12:02 PM, Don Stewart [EMAIL PROTECTED] wrote:
Is your LD_LIBRARY_PATH environment variable exported, and set to
include the path to the lib dir that libedit lives in?
e.g.
$ echo $LD_LIBRARY_PATH
/home/dons/lib
Allows the system linker to find things
jwlato:
Hello,
I have a problem with a package I'm working on, and I don't have any
idea how to sort out the current problem.
One part of my package is in one monolithic module, without an export
list, which works fine. However, when I've started to separate out
certain functions into
duncan.coutts:
I don't think I'm just speaking for myself when I say that pseq is
confusing and the docs similarly.
Given the type
a - b - b
we would assume that it is lazy in it's first arg and strict in the
second. (Even in the presence of seq we know that it really really must
be
jwlato:
On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones
[EMAIL PROTECTED] wrote:
| I'm compiling with -O2 -Wall. After looking at the Core output, I
| think I've found the key difference. A function that is bound in a
| where statement is different between the monolithic and split
shoot.spam:
Hi,
Please bear with a very basic question. I am trying to 'learn me a
Haskell for great good' using Hutton's book and some online tutorials.
I started off with Hugs and recently used GHC (to use the 'let a =
.. syntax interactively, which Hugs doesn't allow perhaps).
igloo:
Hi all,
We've been weighing up the options to solve the recent problems that
editline has given us, and we think that this is the best way forward:
For 6.12:
* http://hackage.haskell.org/trac/ghc/ticket/2811
Implement unicode support for text I/O
(we've had this on the
hoangta:
Hello everybody,
I am following A Tutorial on Parallel and Concurrent Programming in
Haskell and I have a problem with making Haskell to use my multi-cores
(Core 2 Quad CPU).
The Haskel version I used is GHC 6.10.1, for Haskell 98. I compile my
below program with
Running time as a function of module name length,
http://galois.com/~dons/images/results.png
10 is the magic threshold, where indirections start creeping in.
Codegen cost heuristic fail?
-- Don
___
Glasgow-haskell-users mailing list
dons:
Running time as a function of module name length,
http://galois.com/~dons/images/results.png
10 is the magic threshold, where indirections start creeping in.
Codegen cost heuristic fail?
Given this, could you open a bug ticket for it, with all the info we
have,
gwright:
Hi,
What is the preferred gcc to use with ghc 6.10.1? I'm starting
the long and doubtless slow process of putting together a more user
friendly (and binary distributable) ghc distribution to be built using
MacPorts.
The guidance about gcc on the wiki is vague. Is there a
Ah ha! Excellent!
Much apprciated.
twhitehead:
I believe the arrays for (Word/Int)(8/16/32) are currently taking eight,
four,
and two times, respectively, as much memory as actually required. That is,
newMBU n = ST $ \s1# -
case sizeBU n (undefined::e) of {I# len# -
case
claus.reinke:
Looking at prelude/PrelRules.hs has reminded me of an old
conundrum: if I switch from Int to Word, should I expect any
performance differences?
A while ago, I needed lots of fairly small positive numbers,
together with a small number of flags for each, so I thought
I'd switch
claus.reinke:
Here is a trivial example with drastic difference between
T = Int and T = Word (~2.5x here):
main = print $ foldl' (+) 0 [1..1::T]
..
GHC.Prim.word2Int#
(GHC.Prim.and#
(GHC.Prim.int2Word# wild13_XbE)
(GHC.Prim.int2Word# y#_a4EZ))
1 - 100 of 197 matches
Mail list logo
