futhark/Lobby

Gotta go fast!

Troels Henriksen

@athas

Depends on your definition. It works fine with records and tuples, and you can have maps on top. But it'll be a week or two before we can handle most parallelism.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

tuples are fine, in my case anyway

I'll probably try it later. Is everything based on analytical gradients?

Troels Henriksen

@athas

What do you mean?

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Maybe the word is different in english, but I mean like D(sin x) -> cos x

not using numerical diffrentiation

I mean you could use (f(x+h)-f(x) )/h numerically

My understanding of AD is that it works based known gradients of the 'basic' functions at compile time. And the compiler makes an expression of the gradient of the composed function.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

But I don't know if that's the case for all cases.

A quick look at the wikipedia page for AD tells me that everything is indeed 'analytical', which is nice.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

It's mostly just fancy use of the chain rule as far as I can tell.

Orestis

@omhepia:matrix.org

[m]

Well its much more than that. Finite difference are incredibly less accurate and much more prone to numerical error.

And by numerical I mean the limited accuracy of computing machines as well as discretization errors.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Mostly at least. I guess there are some edgecases.

It would have saved me a lot of time if Futhark had this feature a year ago. Really nice to see it coming anyhow.

Troels Henriksen

@athas

AD is not numerical differentiation, but neither is it completely analytical. It is regarded as a mix. Operationally, it's analytical gradients at the primitive, combined with the chain rule.

It tends to have excellent numerical properties; typically as good as the original computation.

Snektron

@snektron:matrix.org

[m]

I spent some more time optimizing and improving the parser stuff, on a 2080 TI it now parses and constructs an inverted parse tree in 401us for a 5.1 KB input, 28ms for 18 MB and 143 ms for 92 MB. For reference, the cpp parser which only validates the input requires about 19us, 62ms and 334ms respectively (running on a Ryzen 3700X), so thats pretty promesing :)

The grammar i tested with is relatively simple, though that shouldn't have a lot of impact

Troels Henriksen

@athas

I still think Futhark is an odd choice for a parser, but I am happy whenever it is faster than C++.

Snektron

@snektron:matrix.org

[m]

Beats writing cuda/opencl by hand

Wasnt that the intended purpose?

Troels Henriksen

@athas

Indeed! And soon it will also beat writing gradients by hand.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Does Futhark have a specified 'endianess'? I came to think of it in the context of image encoding, as done in futhark literate. I wanted to do a similar interpretation of []u32 in Haskell, but the library I used read the pixel values in big-endian order. This was of course easy to fix, but is this behaviour hardware dependent?

Troels Henriksen

@athas

Futhark assumes that the host and device will have the same endianness. The binary data format always uses little endian.

And I guess futhark literate does the same. I actually didn't give it any thought, and it probably isn't documented.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Ok, I guess it's probably a non-issue in most cases since most modern hardware is either little-endian or bi-endian. I think the Haskell library read it as a byte-array of rgbargba... and since I don't think about endianness that often this gave me some rather confusing results...

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

I think I've encountered this before but wasn't bothered enough to report it. Unless it is by design for some reason, I think I've found a parsing error, that I assume would be relatively easy to fix.

let a = 0i32
     -- |>  id

commenting the second line results in a parsing error, this appears to be the case for the |> operator in particular, not + for example. I find it annoying when I comment a filter for example. A second -- removes the error.

Troels Henriksen

@athas

That is because -- | starts a documentation comment.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Ah, so that's why. a bit unfortunate, since |> is a pretty common start of a line

Troels Henriksen

@athas

Just put the line comment further to the left. This is intentional behaviour based on my Haskell experience, where you might accidentally put in doc comments in invalid places (GHC doesn't care), but then the doc generation tool will issue a parse error.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

So it's specifically one space?

Troels Henriksen

@athas

Yes.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Ok that makes it easier to deal with

Troels Henriksen

@athas

If the parser was less bad at reporting errors, it would tell you explicitly that a doc comment marker cannot be put there.

But Happy does not make it particularly easy to report nice errors.

Now that the grammar has stabilised, I've been wondering whether we should re-implement the parser with Megaparsec.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

Yes, I think for slightly wider adoption, better parser errors would be high priority

With good error messages, now with futhark literate I think it could actually be pretty good for general engineering students.

A decent linear algebra package would probably also be necessary

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

In my experience very few tasks actually required IO beyond getting plots and some numbers, so the pure nature of Futhark would not be an issue

munksgaard

@munksgaard:matrix.org

[m]

2021: The year of general purpose Futhark!

omhepia

@omhepia:matrix.org

[m]

just saw the nice performance bumps for scatter_2/3d. nice work. is there any possibility to see something like this for rotates?

Troels Henriksen

@athas

How so? maping rotate should be optimal.

Orestis

@omhepia:matrix.org

[m]

if it is then it's great :-D

(i have no complains about performance i was just wondering if some of the magic behind scattering in 2/3d could be applied to rotating in 2/3d

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

It's been a while since I looked at the accumulators branch. Are there any new intrinsics or other changes I should know of? The ones I know of are acc, scatter_stream, hist_stream, and acc_write.

Troels Henriksen

@athas

No, those are the ones.

Gusten Theodor Isfeldt

@Gusten_Isfeldt_gitlab

I am a bit confused by this error:

Cannot apply "reduce_by_index_stream" to "interaction" (invalid type).
Expected: *acc [n](((f32, f32, f32), (f32, f32, f32)), tââ) -> bââ

          -> *acc [n](((f32, f32, f32), (f32, f32, f32)), tââ)
Actual:   (acc: *acc [kââ](((f32, f32, f32), (f32, f32, f32)), f32)) -> ((i64,
                                                                          i64),
                                                                         (i32,
                                                                          i32,
                                                                          i32))
          -> *acc [kââ](((f32, f32, f32), (f32, f32, f32)), f32)

Would consume variable "potential", which is not allowed.

from the code

let associatedInteraction [n] potential box (coordinates:[n](v3,quaternion)) associations =
191     let interaction [k] (acc: *acc ([k](ft, f32)))  ((i, j), jump) : (*acc ([k](ft, f32)))
    =
192         let cI = coordinates[i]
193         let cJ = triadMap f32.i32 jump |> mvMult box |> translate coordinates[j]
194         let (ftI, ftJ, p) = particleInteraction potential cI cJ
195         in write (write acc i (ftI, 0)) j (ftJ, p)
196     let ne = (zeroFT, 0)
197     let (fts, ps) = reduce_by_index_stream
198             (replicate n ne)
199             (\(ft1, p1) (ft2, p2) -> (addFT ft1 ft2, p1 + p2))
200             ne
201             interaction
202             |> unzip
203    in (fts, f32.sum ps)

potential is just a function

Where communities thrive

People

Repo info

Activity