Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Troels Henriksen
    @athas
    These are the kinds of sharp edges that make futhark literate a bit of a clumsy tool.
    It's really a hack.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Maybe one day it won't be(to the same extent)
    Troels Henriksen
    @athas
    There's no deep reason this can't be fixed, but it would take some time to define a protocol for how to communicate values of more complex types.
    The C interface actually supports obtaining the raw data (in the binary data format) underlying any opaque value. What would be needed is a description of how those parts map to the high-level type.
    This would be interesting for sum types, but not so hard for records.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    For now as long as I know how it works, it's ok.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    -- > :plot2d { potential=(rs, vs) , probability = (rs, ps) }
    fails with
    unexpected space
    expecting '='
    removing all the whitespace in the record declaration works
    but my guess is that it is not supposed to be whitespace-sensitive
    Troels Henriksen
    @athas
    Ugh, lexer bug. Thanks. I'll get around to fix it.
    Snektron
    @snektron:matrix.org
    [m]
    What size is bool in binary data sets? and what layout do higher ranked arrays have?
    Troels Henriksen
    @athas
    Snektron
    @snektron:matrix.org
    [m]
    i've seen that page, but size of bools and layout of higher ranked arrays doesn't seem to be documented there
    Troels Henriksen
    @athas
    Hm, you're right. I'll have to add it. Bools are bytes, and the values are in row-major order.
    Snektron
    @snektron:matrix.org
    [m]
    (with layout i mean which axis goes where)
    Thanks
    Troels Henriksen
    @athas
    Both things should be fixed now.
    By the way, if you are in the unfortunate situation that you have to work directly with the Futhark data format, but fortunate enough to use Python, consider: https://pypi.org/project/futhark-data/
    Snektron
    @snektron:matrix.org
    [m]
    This is for the output of the lexer generator. For the parser, i just generated a source file, but for the lexer this file is several megabytes and so i can't really do that.
    I can either use some internal format or the Futhark binary data format. I guess the latter adds that i can experiment more easily.
    Thanks for that link though, i'll check out its source and use it for the small helper scripts i made.
    Snektron
    @snektron:matrix.org
    [m]
    are the indexes into the dataset lexographic or co-lexographic?
    i mean is the first value when writing a[x, y] the innermost or outermost axis
    Troels Henriksen
    @athas
    It's row-major order, so lexicographic.
    Snektron
    @snektron:matrix.org
    [m]
    thanks
    Troels Henriksen
    @athas
    Although that's not strictly true. Futhark does not define an in-memory representation. It's whatever the compiler thinks will make your code run faster.
    But when you flatten/reshape arrays, the semantic ordering is considered row-major order.
    Snektron
    @snektron:matrix.org
    [m]
    Do i need to do something to update the tag? I've been compiling Futhark for myself but if i just do pull and stack install the tag doesn't seem to change, and i'm wondering if i'm doing that right
    Troels Henriksen
    @athas
    You mean the one in the version number? The build system doesn't understand the module dependencies for that bit of metaprogramming. Do a stack clean if you want to be sure that it's right.
    Snektron
    @snektron:matrix.org
    [m]
    alright, thanks
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    Ah, one less tab
    Snektron
    @snektron:matrix.org
    [m]
    Yea, matrix and gitter merged a while ago.
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    I know, but my old matrix account had a joke name that felt unsuitable for use in this context. I've never been good at coming up with pseudonyms.
    Snektron
    @snektron:matrix.org
    [m]
    Do like my friend did and use an online hacker name generator, i think he still goes by shadowdestroyer or something
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    That is one way to do it. Since I use this for work I thought I'd just use my name though.
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    Is there any benefit to compiling the compiler to use multiple threads? My compile times are starting to become longer. It's still very acceptable in the grand scheme of things, and I should probably remove some dead code in my libraries, which I guess would speed it up a bit, but waiting around a minute is more than I am used to with Futhark.
    Troels Henriksen
    @athas
    Unless you specifically ask it not to, the Futhark compiler is already compiled as a parallel program (although the benefit isn't that great).
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    Oh, I missed that. Cleaning and waiting it is.
    Troels Henriksen
    @athas
    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.
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    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?
    Troels Henriksen
    @athas
    Not at all, I think it could be parallelised a lot more than it is.
    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.
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    I'd rather have fast code than a fast compiler :)
    Troels Henriksen
    @athas
    Well, that's the idea. Originally my success criteria was for Futhark to be regarded like Stalin Scheme: technically impressive, but not practically useful due to excessive compile times. We've grown more ambitious since then, though.
    Gusten Isfeldt
    @gusten:matrix.org
    [m]
    This is of course only until Snektron implements futhark in futhark.
    1 reply