Ticket and standalone program are here ->
http://hackage.haskell.org/trac/ghc/ticket/2396
But I don't know anything about the test suite or how to make a test case.
Scott
On Thu, Jun 26, 2008 at 9:37 AM, Ian Lynagh <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 10:42:
On Tue, Jun 24, 2008 at 4:15 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
>
> Nope, there's a lot of optimisations taking place on the core-to-core
> phase, to ensure the core that gets unfolded into your .hi files is as
> nice as possible. And then still there's things that actually stay as
> calls
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 have inline pragmas, and all are sm
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, Jun 24, 2008 at 02:01:58PM -0700
>
>
> 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 unfolding and high
> optimisat
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:
http://graphics.cs.ucdavis.edu/~sdillard/Vec
I notice a slight drop in performance when I install the library using
cabal. Maybe 10-20%, on one particular function. This is in
Something strange happened and the body of my previous email was lost. I've
re-sent it here. The attachments are there.
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-June/014973.html
=
Hi,
I'm seeing the following bug revived in 6.8.2 and 6.8.3:
http://hackage.haskell.org/trac
Hi,
I'm seeing the following bug revived in 6.8.2 and 6.8.3:
http://hackage.haskell.org/trac/ghc/ticket/672
I use a default definition for class method, one that calls methods of
dependent (super?) classes. Of course I'm embarrassed it took me so long to
realize I didn't _need_ the class in the f
Hi,
I've been fidgeting with a fixed-length list library, for things like 3d
vectors/points, rgba tuples, etc. The data type is
data a :. b = (:.) a b
deriving (everything reasonable)
infixr :.
Nothing in that type specifies that for the partially instantiated type
t1:.t2:.t3, t1 and t2 shoul
Simon, Don,
You're right. -fno-state-hack fixed it. I've opened a trac ticket.
Program and test data are there.
http://hackage.haskell.org/trac/ghc/ticket/2284
Scott
On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> Scott
>
> | I'm experiencing some undesirable
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 (Int,Int) (Int,Int)
Hi,
I think I found a performance bug. Either that, or something is going
on that I don't understand.
I've attached an example program. Here's my session with it:
===
ghc --make -O2 MaybeBug.hs; time ./MaybeBug +RTS -tstderr
[1 of 1] Compiling Main ( MaybeBug.hs, MaybeBu
Thanks for the response guys.
I'm still curious as to the specific mechanism by which a strictly
compile-time function affects the run-time behavior of the GC. Bulat
says that touch# makes the runtime aware that the fptr object is still
in use, but how does it do this if, at runtime, it doesn't do
Hi,
I do a lot of programming with small compound objects, things like 3d
vectors or RGBA tuples for images. For performance reasons, I keep
them in StorableArrays, since there is no way to use these things with
UArrays. (But that's a topic for another thread.)
Some how the notion got into my hea
ath.V
you'll see lots, due to a call to peek that is not inlined.
This is with ghc-6.8.1 and ghc-6.8.2 (no difference)
Thanks for any light you can shed on this,
Scott
On Dec 12, 2007 1:48 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> stefanor:
>
> > On Wed, Dec 12,
Hi,
I have a statically-sized-list library that I use for linear algebra stuff.
It's got a vector type something like this:
> data V a b = V a b
so that a 3D vector is
> type Vec3 a = V a (V a (V a ()))
and I have type classes for operations on these things, like so:
> class VZipWith a b c u
On Nov 13, 2007 3:45 AM, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> What you're seeing here is the magic of automatic specialisation. When the
> Vec type and instances are in the same module as the use, GHC can see what
> type the instances are being used at, and can create specialised instances,
Hello,
What is the interaction between the UNPACK pragma and modules? I've
attached a small test case where a datatype is unpacked when it and
its associated functions are defined in the same file in which they
are used, but it is not unpacked if the definitions are given in
another module. There
Hello,
This is somewhat related to this thread:
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012646.html
In that email I asked about the performance of gaussian elimination on
small matrices represented by unboxed arrays, because I noticed that
unsafeRead was unexpectedly slo
You're right. I broke them when experimenting to see where the cycles
were going. I've fixed them, but the other pair of functions, named
gaussElim2, were correct and the issue remains that unsafeRead appears
slower than readArray.
I've included your implementation for comparison, as well as a si
Hello,
I'm writing some matrix multiplication and inversion functions for
small matrices (3x3 and 4x4 mostly, for 3d graphics, modeling,
simulation, etc.) I noticed that the matrix multiplication was a
bottleneck so I set out to optimize and found that using unsafeRead
instead of (!) (or readArr
21 matches
Mail list logo
