If you compile with
-v the compiler will give time deltas for various parts of the compiler pipeline, and then maybe you can figure out what is taking so long. My guess (because this is always the answer) is the aggressive inlining, which can massively blow up the program. If you are careful, you can put #[noinline] attributes on large functions that are called in multiple places.
But you have to be careful, because the compiler cannot handle function calls in awkward places (specifically, inside code that it wants to put on GPUs), and it's not yet able to ignore
noinline attributes that would cause errors in code generation.
It will never result in silent failures, though.
I guess this is pretty low priority, but is there potential for more thread utilisation in the compiler, or is the process inherently very single threaded?
One problem is that parallel Haskell isn't very effective for the kind of pointer-chasing code you find in a compiler (the GC isn't good enough), but we could probably do better than we currently are.
But the main performance problem is the naive inlining policy. I think significant gains could be made just by making that a bit smarter.
It will never be a fast compiler, though.
And algorithmically, the Futhark compiler isn't doing anything ludicrous like Stalin is. The most dubious thing we have is a general policy of writing passes that generate excessive code, then afterwards apply a heavy-duty simplifier to shrink it again. That means every single pass doesn't have to care about producing minimal code, but it does slow down compile times.
Yes!
Its main trick is intense (and super expensive) control flow analysis to aggressively monomorphise and unbox values.
i did not realize i needed to have something like that in my life
Of course, in Futhark it should be called the thorn ( ᚦ) operator.
2 replies
That's why I've started using
& in Haskell! It's probably not idiomatic, but it is nicer than $ imo.
I did some preliminary testing for the lexer VS flex, flex reaches about 150-180 MB/s depending on the compiler, on my Ryzen 3700X. Running futhark on a RTX 2080 TI yielded about 5 GB/s, though i cant actually double check since my uni broke that machine. On my RX 580 it does about 650 MB/s, and futhark c does about 80 MB/s.
The latter can probably be explained by the large lookup table i use, which isn't very cache friendly of course.
I don't think its physically broken, but my faculty has been messing with these machines ever since the start of this academic year.
1 reply
I haven't tried other flex alternatives, although the name (fast lexical analyzer generator) would lead me to believe that it should be decently competitive. Its gnu software though, so its methods may be dated by now.
This isn't even a cluster system. There are just a few machines you can use as student, and another few you can use as staff. All fair-use, although that wont stop students from running R programms that run for several months and require 700GB of memory <grumble>
Up until recently students could log into staff machines so i had just been using those.
Every once in a while a machine breaks magically and usually its fixed within a few hours but not this machine i guess
Is it intentional that
(a).b is an invalid module expression? I guess its kind of weird, but i'm trying to import a parametric module and apply it simultaneously
so i have something like
a.fut:
module a (T: integer) = {
let add (a: T.t) (b: T.t): T.t = a + b
}and then in b.fut:
module a_u8 = (import "a").a u8(x).y is a special expression in the term language (because x.y is handled as a single lexeme), and I guess we just never added it similarly to the module language.
Just curious; what does the 'bikeshed' label mean? It's only on the AD issue as far as I can tell?
Based on this: http://bikeshed.org/
And regarding mailing lists, I sure wish they had that functionality sometimes
Second link does not work for me
I shall check the archives
Hello everyone :). I'm new to GPU programming and futhark but I want to try to speed up a rendering process of points. And would like some input on how it could be handled. I have a large set of 2d points where each coordinate is a float32. I want to "rasterize" these points and then count how many of them are visible. I understand I essentially have to implement a rasterization algorithm. However I'm wondering if this can be done efficiently at all on a GPU. Essentially I seem to have 2 choices. Either loop through every point and set the correspondin cell to 1. Or loop through the grid and check whether each cell contains at least a single point. But option 1 has concurrent write access to the grid which afaik is bad. And option 2 is slow because it's hard to determine whether a point falls into a cell.
Are there any other ways to attack this?
In fact I don't really need a final image. I just want to see have the number of cells which contain at least a single point.