I'm running into this situation where my program uses 8.4 GB vram using the opencl backend, but only 5 using the cuda backend (running on different machines)
are they using different kinds of allocators?
They do not interrogate the hardware about its needs in the same way.
Also some sequential use of arrays.
ok
I'll probably try it later. Is everything based on analytical gradients?
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.
A quick look at the wikipedia page for AD tells me that everything is indeed 'analytical', which is nice.
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.
It would have saved me a lot of time if Futhark had this feature a year ago. Really nice to see it coming anyhow.
It tends to have excellent numerical properties; typically as good as the original computation.
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
Wasnt that the intended purpose?
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?
And I guess
futhark literate does the same. I actually didn't give it any thought, and it probably isn't documented.
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...
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
-- |> idcommenting 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.
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.
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