Re: [GHC] #673: Import FastPackedStrings for 6.6
#673: Import FastPackedStrings for 6.6 ---+ Reporter: simonmar | Owner: Type: task | Status: closed Priority: high | Milestone: 6.6 Component: libraries/base|Version: 6.4.1 Severity: normal| Resolution: fixed Keywords:| Os: Unknown Difficulty: Moderate (1 day) | Architecture: Unknown ---+ Changes (by simonmar): * resolution: = fixed * status: new = closed Comment: Data.PackedString deprecated, for now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/673 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #847: Threaded RTS problems on FreeBSD
#847: Threaded RTS problems on FreeBSD ---+ Reporter: simonmar|Owner: simonmar Type: bug | Status: new Priority: normal |Milestone: 6.4.3 Component: Runtime System | Version: 6.4.2 Severity: normal | Keywords: Os: FreeBSD | Difficulty: Unknown Architecture: Multiple| ---+ The threaded RTS has some problems on FreeBSD. Symptoms are occasional hangs, seen when * using a stage2 GHC compiled with -threaded * running the testsuite, the timeout program sometimes hangs I have been unable to reproduce these on a uniprocessor, but have seen them on a dual proc. Related mailing list mutterings: * [http://www.haskell.org//pipermail/glasgow-haskell-bugs/2006- April/006445.html] * [http://www.haskell.org/pipermail/glasgow-haskell-users/2006- July/010609.html] * [http://www.haskell.org/pipermail/glasgow-haskell-users/2006- August/010690.html] * [http://www.haskell.org/pipermail/glasgow-haskell-users/2006- August/010697.html] -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/847 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Threading woes on FreeBSD
Gregory Wright wrote: Some additional information on the threading problems experienced on FreeBSD. The system was FreeBSD 6.1-RELEASE-p2, dual 2.8 GHz Xeon. I built ghc-6.4.2 from cvs using the FreeBSD ports version of ghc-6.4.2. (The latter has the threaded RTS disabled.) I ran the ghc-regress tests on the built compiler. I used the libmap.conf (5) method to change the threading library from pthreads to libthr and libc_r. The build from cvs uses pthreads by default. The compiler using pthreads had 47 unexpected failures, and accumulated about 30 timeout processes, which were just burning cpu cycles. Using the reentrant c library (libc_r) gave essentially the same result, with a tens of timeout processes consuming cpu but apparently doing nothing else. When I used the 1:1 threading library (libthr) the testing process ground to a halt, with just one timeout process consuming about 95 percent of the cpu. I kill the test, since it had not made significant progress in about 5 hours. That's a useful data point, we know that just switching to -lthr or -lc_r will not fix this. I'm going to set aside working on the FreeBSD threading question and concentrate on threaded runtime problem on OS X. I had originally hoped that they would show similar behavior, but that seems to not be the case. No problem, I'm on the trail of the FreeBSD problem (on your box :-). Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #844: panic on conflicting patterns in TH splice
#844: panic on conflicting patterns in TH splice ---+ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal| Milestone: Component: Template Haskell |Version: 6.4.2 Severity: minor | Resolution: fixed Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonpj): * resolution: = fixed * status: new = closed Comment: Fixed, thank you for the report Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/844 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #848: Threaded RTS problems on Solaris
#848: Threaded RTS problems on Solaris ---+ Reporter: simonmar|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.4.3 Component: Runtime System | Version: 6.4.2 Severity: normal | Keywords: Os: Solaris | Difficulty: Unknown Architecture: Multiple| ---+ Just so we don't forget: the threaded RTS also has problems on Solaris, both Sparc and x86 have been reported to have problems. The symptom is that the stage2 linked with -threaded crashes at random points. Might be related to #751. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/848 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #729: Build system uses wrong version of include files.
#729: Build system uses wrong version of include files.
---+
Reporter: guest | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Build System |Version: 6.4.1
Severity: normal| Resolution: worksforme
Keywords:| Os: MacOS X
Difficulty: Unknown | Architecture: powerpc
---+
Changes (by simonmar):
* resolution: = worksforme
* status: new = closed
Comment:
Closing; we asked for more details but there was no response. I don't
''think'' there's a problem here; using the installed {{{HsUnix.h}}} is
reasonable during the stage1 compilation.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/729
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #849: Offer control over branch prediction
#849: Offer control over branch prediction
+---
Reporter: simonpj |Owner:
Type: feature request | Status: new
Priority: normal |Milestone:
Component: Compiler | Version: 6.4.2
Severity: normal | Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
+---
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.
The first version looks much like this:
{{{
loop fp n off s = case next s of
Done - return $! PS fp 0 off
Skips' - loop fp n off s'
Yield x s' - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
}}}
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
{{{
loop fp n off s = case next s of
Done - trimUp fp n off
Skips' - loop fp n off s'
Yield x s'
| n == off - realloc fp n off s' x
| otherwise - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
}}}
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.
That is:
{{{
| n == off - realloc fp n off s' x
| otherwise - do ...
}}}
vs
{{{
| n /= off - do ...
| otherwise - realloc fp n off s' x
}}}
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.
In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation {{{__builtin_expect()}}} which
many
C projects use in the form of a macro:
{{{
if (unlikely(x==0)) { ...
}}}
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.
Anyway, so what I wish is that I could write something like:
{{{
loop fp n off s = case next s of
Done - {-# UNLIKELY #-}
trimUp fp n off
Skips' - loop fp n off s'
Yield x s'
| n == off - {-# UNLIKELY #-}
realloc fp n off s' x
| otherwise - do
withForeignPtr fp $ \p - pokeByteOff p off x
loop fp n (off+1) s'
}}}
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with {{{ {-# NOINLINE #-} }}} so that the code for the realloc case
doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.
However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.
Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's {{{__builtin_expect()}}}. I also didn't connect
it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it
[GHC] #850: threaded RTS uses SIGALRM
#850: threaded RTS uses SIGALRM ---+ Reporter: simonmar|Owner: Type: bug | Status: new Priority: normal |Milestone: 6.6.1 Component: Runtime System | Version: 6.4.2 Severity: normal | Keywords: Os: Unknown | Difficulty: Unknown Architecture: Unknown | ---+ The threaded RTS uses SIGALRM for its timer signal, this is a bit naughty and could interfere with use of SIGALRM by the application. Also it can cause EINTR of system calls, which the application might not be prepared to handle. Some system calls can't be reliably restarted (eg. usleep()). The single threaded RTS uses SIGVTALRM, but we can't use this in the multithreaded RTS because it ticks in CPU time, and our threads might be idle. Ideally we should be using the timer_*() family of functions, if supported. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/850 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: heap corruption?
Hi Simon,
I'm sorry I don't have a test case, aside from what I've sent already,
and it's sometimes difficult to reproduce. (though note that the
GSLHaskell library can still be downloaded at the provided URL)
However, I've checked and double-checked our code and can't find
anything on our side which could result in the reported bug.
Since it's happening only for allocations above 2^20-8128 bytes, I
would recommend creating a ticket and some time checking the heap code
for any special cases that happen for allocations near 1MB.
Frederik
On Tue, Aug 08, 2006 at 03:18:34PM +0100, Simon Marlow wrote:
(cleaning up old mail). Frederik: did you ever get to the bottom of this?
Do you have a test case,
and should we create a ticket for it?
Cheers,
Simon
Frederik Eaton wrote:
I'm now using 6.4.2. The bug still persists, but I can't immediately
reproduce it with basic GSLHaskell operations, nor with raw memory
operations. It is even difficult to reproduce as it is, the examples I
gave don't trigger it anymore (I was running them under 6.4.1). For
instance, this gives a correct result:
dot (useFast $ $(dim 100) (2*vconst 2)) (vconst 4)
and this gives an incorrect result:
dot (useFast $ $(dim 100) (2.*vconst 2)) (vconst 4)
(the first one creates a new matrix of 2's and does element-wise
multiplication; the second just scales by 2)
It could be a bug in our code, but I'd be surprised. It only triggers
for vectors of length 130056 or greater (that's 130056 8-byte doubles,
or 2^20-8128 bytes). If something were being prematurely finalized, one
would imagine that shorter vectors would also expose the problem. Most
of all, it seems very strange that in certain situations two different
objects would get the same address when they're large, but not when
they're small. But I'll keep looking for the source of the problem.
Frederik
On Fri, Jun 02, 2006 at 05:11:24PM +0200, Alberto Ruiz wrote:
Hi Frederik, I will be out of town this weekend (I really need it!), I will
take a look at the
problem on Monday. By now my recommendation is:
1) try to reproduce the problem without GSLHaskell or any other library,
using just mallocArray,
newArray, etc. with those big sizes. (Use ghc 6.4.2 or better..)
2) If this is not possible, try to reproduce the problem with the simplest
possible example using
the unmodified GSLHaskell.
Alberto
On Friday 02 June 2006 16:15, Frederik Eaton wrote:
Hi Alberto,
I'm experiencing a problem which may be a bug in GHC. Here I take the
dot product of two vectors. I put debugging traces in the 'dotR' C
function (which I call in 'dot'), so one can see the addresses of the
memory blocks. When the vectors are below a certain size, the function
seems to give the correct result. However, when they are above a
certain size, the same pointers are sometimes used for both arguments
(ap and bp), and the result is of course incorrect. The incorrect
result is consistent with both pointers referring to the first vector
(vconst 2). Also, with other arguments I sometimes get heap
corruption. Any idea what might be the problem?
Prelude Vector print $ (dot $ useFast $ $(dim 1000) $ (vconst 2)) (ones)
ap=0xb1b0a008, bp=0xb1b0c008, rp=0xb1b036c8
an=1000, bn=1000, rn=1
res=2000.00
2000.0
Prelude Vector print $ (dot $ useFast $ $(dim 100) $ (vconst 2))
(ones) ap=0xb3402008, bp=0xb3402008, rp=0xb1b0c770
an=100, bn=100, rn=1
res=400.00
400.0
Prelude Vector print $ (dot $ useFast $ $(dim 100) $ (vconst 2))
(vconst 2) ap=0xb2c02008, bp=0xb2302008, rp=0xb1b08780
an=100, bn=100, rn=1
ap[130055]=2.00 bp[130055]=-0.00
ap[130056]=2.00 bp[130056]=2.01
ap[130058]=2.00 bp[130058]=2.00
ap[130059]=2.00 bp[130059]=0.00
ap[130060]=2.00 bp[130060]=2.01
...
res=3992888.004728
3992888.004727577
Here is dotR:
int dotR(DVEC(a), DVEC(b), DVEC(r)) {
REQUIRES(an == bn rn == 1, BAD_SIZE);
DEBUGMSG(dotR);
fprintf(stderr,ap=%p, bp=%p, rp=%p\n,ap,bp,rp);
fprintf(stderr,an=%d, bn=%d, rn=%d\n,an,bn,rn);
double res=0.0;
int i;
for(i=0; ian; i++) {
if(ap[i] != floor(ap[i]) || bp[i] != floor(bp[i]))
fprintf(stderr,ap[%d]=%lf bp[%d]=%lf\n,i,ap[i],i,bp[i]);
res += ap[i]*bp[i];
}
fprintf(stderr,res=%lf\n,res);
rp[0] = res;
OK
}
I switched to not using gsl here, so that I could be sure the bug
wasn't in gsl. However, when using gsl the same problems occur. So I
think it may be heap corruption in ghc. But I don't know how to debug
that. I tried running in valgrind but it doesn't show anything
obvious. If you want to run what I have, here is my code:
http://ofb.net/~frederik/GSLHaskell2.tar.gz
The problem is exposed by building and running:
print -l ':m Vector' 'print $ (dot $ useFast $ $(dim 100) $ (vconst 2))
(vconst 2)' | =ghci -package GSL -fglasgow-exts
Thanks,
Frederik
Re: [GHC] #281: Wrong overlapped/missing pattern warnings
#281: Wrong overlapped/missing pattern warnings ---+ Reporter: nobody| Owner: nobody Type: bug | Status: closed Priority: lowest| Milestone: Component: Compiler |Version: 6.2.2 Severity: normal| Resolution: fixed Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonpj): * resolution: None = fixed * status: assigned = closed Comment: All of these are fixed, except the first. I'm going to open a new bug report for that, since fixing n+k patterns isn't going to happen soon. And I'll close this. ds059 checks for the cases that now work ok. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/281 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #852: Browsing a module in ghci can cause a panic
#852: Browsing a module in ghci can cause a panic
-+--
Reporter: mnislaih |Owner:
Type: bug | Status: new
Priority: normal|Milestone: 6.6
Component: Driver| Version: 6.4.2
Severity: normal| Keywords: ghci module package
Os: MacOS X | Difficulty: Easy (1 hr)
Architecture: x86 |
-+--
Consider a file `Test2.hs` containing
{{{
module Test.Test2 where
...
}}}
Then, in the ghci prompt:
{{{
:l Test2
:b Test2
}}}
results in a panic in my 6.5 (08 Aug) system:
{{{
*main:Test.Test2 :b Test2
Could not find module `Test2':ghc-6.5: panic! (the 'impossible' happened)
(GHC version 6.5 for i386-apple-darwin):
cantFindErr
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/852
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #852: Browsing a module in ghci can cause a panic
#852: Browsing a module in ghci can cause a panic --+- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6 Component: Driver |Version: 6.5 Severity: normal | Resolution: Keywords: ghci module package | Os: MacOS X Difficulty: Easy (1 hr) | Architecture: x86 --+- Changes (by mnislaih): * version: 6.4.2 = 6.5 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/852 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: posix, POpen, ghc 6.5
... here3 here4 [ here it hangs and i press ^C ] runghc: waitForProcess: interrupted (Interrupted system call) ... Ah yes, this is because GHCi isn't compiled with -threaded. Looks like we've found one more reason to do that. Can I compile ghci with -threaded myself? Or is there a recommended way to experiment with threaded code interactively? Thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
