Ryan, is your benchmark using CAS on pointers, or immediate words? trying
to get atomic primops to build on my 7.8 build on my mac
On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald wrote:
> https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
>
> when i'm more awake i'll experiment
On Sat, Feb 1, 2014 at 12:17 AM, Joachim Breitner
wrote:
> Dar Akio,
>
> I just noticed that even with your approach, the code for foldl-as-foldr
> is not automatically beautiful. Consider this:
>
> I modified the eft function to do to some heavy work at each step (or at
> least to look like that)
https://ghc.haskell.org/trac/ghc/ticket/8724#ticket is the ticket
when i'm more awake i'll experiment some more
On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald wrote:
> i have a ticket for tracking this, though i'm thinking my initial attempt
> at a patch generates the same object code as it
i have a ticket for tracking this, though i'm thinking my initial attempt
at a patch generates the same object code as it did before.
@ryan, what CPU variant are you testing this on? is this on a NUMA machine
or something?
On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald wrote:
> woops, i mean
woops, i mean cmpxchgq
On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald wrote:
> ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
> rather than cmpxchg
> i'll whip up a strawman patch on head that can be cherrypicked / tested
> out by ryan et al
>
>
> On Sat, Feb 1, 2014
ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl
rather than cmpxchg
i'll whip up a strawman patch on head that can be cherrypicked / tested out
by ryan et al
On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald wrote:
> Hey Ryan,
> looking at this closely
> Why isn't CAS usi
Hey Ryan,
looking at this closely
Why isn't CAS using CMPXCHG8B on 64bit architectures? Could that be the
culprit?
Could the issue be that we've not had a good stress test that would create
values that are equal on the 32bit range, but differ on the 64bit range,
and you're hitting that?
Could yo
Then again... I'm having trouble seeing how the spec on page 3-149 of the
Intel manual would allow the behavior I'm seeing:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
Nevertheless, this is exactly the behavior we
I commented on the commit here:
https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b
The problem is that our "cas" routine in SMP.h is similar to the C compiler
intrinsic __sync_val_compare_and_swap, in that it returns the old value.
But it seems we cannot use a comparison
Aha, I understand.
Thanks for the hint!
Gabor
On 1/31/14, Herbert Valerio Riedel wrote:
> On 2014-01-31 at 22:21:09 +0100, Gabor Greif wrote:
>> Unless I missed something big style, -XTypeHoles has been
>> renamed to -XTypedHoles and not removed at all.
>
> fyi,
> http://git.haskell.org/ghc
On 2014-01-31 at 22:21:09 +0100, Gabor Greif wrote:
> Unless I missed something big style, -XTypeHoles has been
> renamed to -XTypedHoles and not removed at all.
fyi,
http://git.haskell.org/ghc.git/commitdiff/235fd88a9a35a6ca1aed70ff71291d7b433e45e4
___
Unless I missed something big style, -XTypeHoles has been
renamed to -XTypedHoles and not removed at all.
Are you sure this patch is valid?
Cheers,
Gabor
On 1/30/14, g...@git.haskell.org wrote:
> Repository : ssh://g...@git.haskell.org/haddock
>
> On branch : master
> Link :
> http:
Dar Akio,
I just noticed that even with your approach, the code for foldl-as-foldr
is not automatically beautiful. Consider this:
I modified the eft function to do to some heavy work at each step (or at
least to look like that):
myEft :: Int -> Int -> [Int]
myEft = \from to -> buildW (myEftFB fr
Dear Akio,
Am Freitag, den 31.01.2014, 16:54 +0900 schrieb Akio Takano:
> > Can you implement build via buildW, so that existing code like
> > "map" [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs)
> > can be used unmodified? But probably not... but that would mean a
> > noti
14 matches
Mail list logo
