Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Snektron
    @snektron:matrix.org
    [m]
    so definitely not a good benchmark
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Do you think your algorithm would scale to something more complex?
    Snektron
    @snektron:matrix.org
    [m]
    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
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Interesting. It's such an odd thing to do on a GPU.
    1 reply
    I was wondering how one would go about flattening it but it seems reasonable.
    1 reply
    Snektron
    @snektron:matrix.org
    [m]
    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
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    I don't quite understand why it doesn't work, but I guess that means you have some work left to do.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    @Gusten_Isfeldt_gitlab Futhark on Windows is almost guaranteed to be troublesome, since we don't test it there.
    Note that a default Windows system doesn't even have a C compiler.
    Snektron
    @snektron:matrix.org
    [m]
    its probably even more painful if you also want to use opencl or cuda
    1 reply
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Hmm, I'll just tell them to use Linux then. Pretty sure they can do that.
    But regular C-code shouldn't be that bad right?
    2 replies
    Troels Henriksen
    @athas
    There is no deep reason it shouldn't work. It just isn't tested.
    Well, the multicore backend definitely will not work, because it uses pthreads.
    snektron
    @snektron:matrix.org
    [m]
    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
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    In this case, purely sequential code would be ok, since it's mostly proof of concept
    Troels Henriksen
    @athas
    You still need a C compiler.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Yes, I realize that. How can people tolerate this?
    Troels Henriksen
    @athas
    No clue. I the notion of "SDKs", that Windows development is apparently based on, to be mildly offensive.
    Since the advent of WSL, I've just told Windows users to use that.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    I've had some colleagues use WSL and they had ridiculous issues with things like file permissions.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    (They are chemists, so I can't blame them... that much.)
    Troels Henriksen
    @athas
    Indeed. They do not know better. You must show them the right path. This is the way.
    1 reply
    Philip Lassen
    @philass
    In order to get the Javascript/WASM to run with the test suite, would I also need to implement a js equivalent of values.py?
    Troels Henriksen
    @athas
    I suppose so, but you only need the binary format, which is trivial.
    snektron
    @snektron:matrix.org
    [m]
    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)
    Troels Henriksen
    @athas
    Futhark doesn't require more than 1.1, I think. Mesa is probably defective for other reasons. I've certainly never managed to get it to work.
    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.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    I think I wrote that somewhere because we only test on 1.2 devices, but looking at the OpenCL spec, I don't think we actually use anything past 1.0 yet.
    Snektron
    @snektron:matrix.org
    [m]
    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.
    Troels Henriksen
    @athas
    Oh. Yes. Probably Mesa does not support double precision. Futhark does have code that tries to only include the double precision parts of the runtime system when the program needs it, but I'm not sure we test that code path anymore.
    Snektron
    @snektron:matrix.org
    [m]
    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
    Troels Henriksen
    @athas
    That pragma should be inserted by the compiler.
    Snektron
    @snektron:matrix.org
    [m]
    hm, mesa does report the device supporting cl_khr_fp64
    Troels Henriksen
    @athas
    Mesa has lied to me before. For example, it claimed to support OpenCL, but whenever I tried to run a kernel, my system would reboot.
    Snektron
    @snektron:matrix.org
    [m]
    wow
    doing a quick search in the generated c code after compiling with futhark opencl does not yield any cl_khr_fp64
    Troels Henriksen
    @athas
    Interesting. That would imply that the compiler doesn't think your program uses f64, but still includes parts of the supporting code. That's a very likely bug to creep in.