2008/7/18 Mitar <[EMAIL PROTECTED]>:
> On Sat, Jul 12, 2008 at 3:33 AM, Max Bolingbroke
> <[EMAIL PROTECTED]> wrote:
>> If findColor had been a function defined in terms of foldr rather than
>> using explicit recursion, then theres a good chance GHC 6.9 would have
>> fused it with the list to yield
Hi!
On Fri, Jul 18, 2008 at 3:54 PM, Chaddaï Fouché
<[EMAIL PROTECTED]> wrote:
>> So that I can easily change the type everywhere. But it would be much
>> nicer to write:
>>
>> data Quaternion a = Q !a !a !a !a deriving (Eq,Show)
>>
>> Only the performance of Num instance functions of Quaternion i
2008/7/12 Mitar <[EMAIL PROTECTED]>:
> So that I can easily change the type everywhere. But it would be much
> nicer to write:
>
> data Quaternion a = Q !a !a !a !a deriving (Eq,Show)
>
> Only the performance of Num instance functions of Quaternion is then
> quite worse.
You can probably use a spe
Hi!
On Sat, Jul 12, 2008 at 3:33 AM, Max Bolingbroke
<[EMAIL PROTECTED]> wrote:
> If findColor had been a function defined in terms of foldr rather than
> using explicit recursion, then theres a good chance GHC 6.9 would have
> fused it with the list to yield your optimized, loop unrolled,
> versi
Hi!
> My guess is that it was premature optimization that created this bug.
It is the root of all evil. ;-)
> Unboxed tuples are not the best answer for every situation. They are
> evaluated strictly!
Then I have not understood the last paragraph correctly:
http://www.haskell.org/ghc/docs/lat
On Sat, Jul 12, 2008 at 8:57 PM, Mitar <[EMAIL PROTECTED]> wrote:
> julia4DFractal :: BasicReal -> World
> julia4DFractal param (x,y,z) = julia4D (Q (x / scale) (y / scale) (z /
> scale) param) iterations
> where c = (Q (-0.08) 0.0 (-0.8) (-0.03))
>alphaBlue = VoxelColor 0 0 (2 /
Hi!
(I will reply propely later, I have a project to finish and GHC is
playing me around and does not want to cooperate.)
This project of mine is getting really interesting. Is like playing
table tennis with GHC. Some time it gives a nice ball, sometimes I
have to run around after it. But I just
> It is somehow award that passing function as an argument slow down the
> program so much. Is not Haskell a functional language and this such
> (functional) code reuse is one of its main points?
I can think of a few reasons why function passing is slow:
* There is an overhead to closure creation
On 2008 Jul 11, at 19:46, Mitar wrote:
It is somehow award that passing function as an argument slow down the
program so much. Is not Haskell a functional language and this such
(functional) code reuse is one of its main points?
That is in fact the case; GHC's version of various Prelude funct
Hi!
This is not all. If I compare performance of those two semantically
same functions:
castRayScene1 :: Ray -> ViewportDotColor
castRayScene1 (Ray vd o d) = ViewportDotColor vd (castRay' noColor 0)
where castRay' color@(VoxelColor _ _ _ alpha) depth | depth >
depthOfField = color
2008/7/9 Mitar <[EMAIL PROTECTED]>:
>
> And it took 15 s. And also the profiling was like I would anticipate.
> Calculating points coordinates and checking spheres takes almost all
> time.
>
> So any suggestions how could I build a list of objects to check at
> runtime and still have this third pe
Hi!
I am making a simple raycasting engine and have a function which take
a point in space and return a color of an object (if there is any) at
this point in space.
And because the whole thing is really slow (or was really slow) on
simple examples I decided to profile it. It takes around 60 secon
12 matches
Mail list logo