whereas the cpu code only verifies
thats on larger input of course, if the input is more like a few kb like any reasonable source code is its a different story
futhark cpu is a lot slower - mainly because the parsing algorithm i implemented does a few passes, and so its limited by memory throughput
i only tested with a really basic test grammar, which is the standard expression grammar thats given in every text book
so definitely not a good benchmark
I did make a more complex grammar, something that is more representative of a real programming language
The way it works is that for every pair of characters, there is only allowed to be one possible part of a left-most derivation
to check the input, a set of stack changes is generated for every input pair - an array of items that are popped from a stack, and an array of items that are pushed
to verify the input all one needs to do is check whether that is balanced
So the complexity of a parse is related to two things mainly: the size of the input (obviously), and the average amount of stack changes per pair of characters
I was wondering how one would go about flattening it but it seems reasonable.
1 reply
Those lists seem to average around 2 for the simple grammar, and around 3 (with some up to 7) for the larger one
so for example i haven't found a way to parse something like
if <expr> <block> else <block>
whereas
if <expr> <block> itself works fine
Yea. To be clear, this parser generator is from a different research i found, but as far as i know i'm the first to implement it
Note that a default Windows system doesn't even have a C compiler.
its probably even more painful if you also want to use opencl or cuda
1 reply
Well, the multicore backend definitely will not work, because it uses pthreads.
You could always try under WSL or msys2. I've had success with that in the past, when i was still a stubborn windows-using freshman
Since the advent of WSL, I've just told Windows users to use that.
Is it an idea to add a check to the generated opencl whether a device supports the minimum required opencl version?
I have two OpenCL versions installed on my system, one is provided by mesa and only supports up to OpenCL 1.1, while the other one, which i ripped from amdgpu-pro, does support 1.2
unfortunately the mesa one appears first and i sometimes forget to pass
-d. I know its not much to type that, but i think its appropriate if the generated code also checks for it and skips any incompatible devices.
(i set up a build environment for futhark the other day so i'm fine with contributing this myself, but i just want to know if this would be an appropriate thing to add)
Since Mesa might work for some people and in some future, I don't like the idea of blacklisting it. Presumably people who install the Mesa ICD also do it for a reason. The only thing we blacklist is Apple's CPU device, because it is completely dysfunctional, and users cannot get rid of it.
I wasn't suggesting blacklisting, but rather checking whether a target device supports opencl 1.2. I thought i read somewhere that futhark requires opencl 1.2
Ah. In that case it might be something else: when i run under mesa, it complains that cl_khr_fp64 is not enabled for the f64 intrinsic functions.
Apparently that extension was promoted to core-optional in OpenCL 1.2, so thats why mesa is giving me trouble. Apparently all that is needed is a pragma in the OpenCL code, which is still accepted for backwards compat: https://www.khronos.org/registry/OpenCL//sdk/2.2/docs/man/html/cl_khr_fp64.html
Let me check if my device supports it, need to turn on my pc one sec