Hi Axel,
When do you expect to publish an updated version of gtk2hs on hackage?
On Thu, Nov 3, 2011 at 1:02 PM, Eugene Kirpichov ekirpic...@gmail.com wrote:
Hi,
The actual thanks for tracking this down go to Vincent Hanquez for finding
that we're doing a lot of gmp calls (and for making me
Hi,
The actual thanks for tracking this down go to Vincent Hanquez for finding
that we're doing a lot of gmp calls (and for making me aware of ltrace),
and to Felipe Lessa for finding that this is caused by poor code generated
for cFloatConv :)
Your changes look identical to those that I made
I forgot to specify my environment.
Windows Server 2008 R2 x64, ghc 7.0.3.
However, I observed the same speed differences on a 64-bit ubuntu with ghc
6.12 - I profiled my application with cairo-trace, and cairo-perf-trace
drew in a fraction of a second the picture that my Haskell program spend a
On 02/11/11 09:17, Eugene Kirpichov wrote:
Hello,
I've got two very simple programs that draw a very simple picture using
cairo, doing a couple hundred thousand of cairo calls.
One program is in C++. The other is in Haskell and uses the cairo library
bindings.
The C++ program completes in a
Hi Claude,
I suspected that the issue could be about unsafe foreign imports - all
imports in the cairo bindings are safe.
I compiled myself a version of cairo bindings with the rectangle and
fill functions marked as unsafe.
Unfortunately that didn't help the case at all, even though the core
On 11/02/2011 09:51 AM, Eugene Kirpichov wrote:
Hi Claude,
I suspected that the issue could be about unsafe foreign imports - all imports
in the cairo bindings are safe.
I compiled myself a version of cairo bindings with the rectangle and fill
functions marked as unsafe.
Unfortunately that
Oh. This is pretty crazy, I wonder what they're doing with GMP so much...
I modified the Haskell program to use cairo directly, even with safe calls,
and it now takes the same time as the C program.
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import qualified
+gtk2hs-users
On Wed, Nov 2, 2011 at 2:10 PM, Eugene Kirpichov ekirpic...@gmail.comwrote:
Oh. This is pretty crazy, I wonder what they're doing with GMP so much...
I modified the Haskell program to use cairo directly, even with safe
calls, and it now takes the same time as the C program.
On 11/02/2011 10:10 AM, Eugene Kirpichov wrote:
Oh. This is pretty crazy, I wonder what they're doing with GMP so much...
I modified the Haskell program to use cairo directly, even with safe calls,
and it now takes the same time as the C program.
yep, i ended up doing the exact same thing
Any idea how to debug why all the GMP calls?
I'm looking at even the auto-generated source for cairo bindings, but I
don't see anything at all that could lead to *thousands* of them.
On Wed, Nov 2, 2011 at 2:14 PM, Vincent Hanquez t...@snarc.org wrote:
On 11/02/2011 10:10 AM, Eugene Kirpichov
On Wed, Nov 2, 2011 at 8:15 AM, Eugene Kirpichov ekirpic...@gmail.com wrote:
Any idea how to debug why all the GMP calls?
I'm looking at even the auto-generated source for cairo bindings, but I
don't see anything at all that could lead to *thousands* of them.
Found them. Look at the Types
On Wednesday 02 November 2011, 10:19:08, Eugene Kirpichov wrote:
I forgot to specify my environment.
Windows Server 2008 R2 x64, ghc 7.0.3.
However, I observed the same speed differences on a 64-bit ubuntu with
ghc 6.12 - I profiled my application with cairo-trace, and
cairo-perf-trace
Hi Eugene,
did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and
Haskell 2010 specifications.
On 02.11.2011, at 12:14, Eugene Kirpichov wrote:
Yay!!!
I made a small change in Types.chs and got my original cairo-binding-based
program to be just as blazing fast. The
Hi,
No, I didn't, as I read in the GHC docs that it is deprecated in favor of
the RULES pragma (I wanted to replace specifically with floatToDouble and
doubleToFloat).
On Wed, Nov 2, 2011 at 5:24 PM, Jean-Marie Gaillourdet
j...@gaillourdet.netwrote:
Hi Eugene,
did you try using the
On Wed, Nov 2, 2011 at 11:24 AM, Jean-Marie Gaillourdet
j...@gaillourdet.net wrote:
Hi Eugene,
did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and
Haskell 2010 specifications.
I don't think it's going to make any difference, as the core already
have an specialized poor
Heh.
Guess what!
A simple {-# INLINE cFloatConv #-} helped to the same extent!
Axel, I think this change should be pretty easy to incorporate, and it
probably makes sense to inline all other functions in Types.chs too.
Would you like me to send the trivial darcs patch or the gtk2hs team
will
On 11/2/11 9:24 AM, Jean-Marie Gaillourdet wrote:
Hi Eugene,
did you try using the SPECIALIZE pragma? It is part of the Haskell 98 and
Haskell 2010 specifications.
The problem with SPECIALIZE is that you still have to give a parametric
definition for the function, whereas the whole point of
17 matches
Mail list logo
