Athas

41 ms·

301.
by Athas 7y ago
There are many things I like here. I'd like more information on how they intend to integrate sizes into a Hindley-Milner type system (particularly the dynamic sizes), since that is something I am struggling with myself[0]. [0]: https
302.
by Athas 7y ago
Dex looks very different from Julia, particularly in the type system. Julia is fundamentally similar to a cleaned-up Matlab or R, with some extra tricks on top (e.g. multiple dispatch and macros), and a very good and polished implementatio
303.
by Athas 7y ago
It depends on what you consider a "complex kernel". Futhark is only for regular non-recursive data parallelism, but I'll argue that something like a genetic algorithm that does calibration of market parameters in the Heston
304.
by Athas 7y ago
You are right that it's interesting to compare Futhark-on-GPU with X -on-GPU for various values of X . In most of our academic work, that is what we do. However, in practice, X -on-GPU where X is not Futhark is rare, because GPU
305.
by Athas 7y ago
There is also a comparison against HotSpot, which is a hand-written GPU program (albeit imperfectly). Futhark does not outperform expertly hand-optimised GPU code, but most of the GPU code found in the wild is hardly expertly hand-optimised
306.
by Athas 7y ago
The biggest problem would be the absence of recursion, but a recursion-free subset of Elm (with a different standard library) would be straightforward.
307.
by Athas 7y ago
Honestly, I would expect the main reason my wc is faster is that mmap()ing the file and then reading it in a huge chunk is about as fast as the kernel's IO can go. GNU wc cannot do this in general because it's supposed to work on
308.
by Athas 7y ago
> Would it be possible to use Futhark to rewrite the APL implementation instead of the Haskell one? That would make an interesting comparison. Sadly, from what I can see, the APL version makes use of so-called nested arrays in the '
309.
by Athas 7y ago
That's a good point, but the -O3 doesn't actually do a whole lot here. I recompiled the Futhark-generated C code with just -O and performance was unchanged. If you look at the generated C code, there isn't really a lot to d
310.
Beating C with Futhark Running on GPU(futhark-lang.org)
114 points by Athas 7y ago|85 comments
311.
by Athas 7y ago
Last time I did APL programming I was a bit bothered by the performance implications of some of the standard loopless programming styles. In particular, it's hard to nest loops. As an example of the implications, consider computing th
312.
by Athas 7y ago
You are always at the mercy of the compiler, unless you use intrinsics or assembly directly (and then it's debatable whether what you are writing is really "C"). C compilers are pretty good, but there are things they cannot
313.
by Athas 7y ago
I used Wayland with GNOME on my X250 laptop around 2016-2017. It worked indistinguishably from X11, including automatically connecting to external displays. Now I use Wayland with sway on my home desktop with a 5k display, and it also wor
314.
by Athas 7y ago
I really like these machines. Unfortunately, I'm in Europe, where they seem to be harder (or riskier) to get hold of. I suppose I should also try to think of something reasonable to do with them, given their cost...
315.
by Athas 7y ago
I always found the use of "enum" for things that are not really enumerable in a useful way to be very confusing. Or are Rust "enum"s enumerable in some subtle way that I don't recognise? Is it just some vestigial
316.
by Athas 7y ago
While I don't know that much about deep learning, last year I had a student who did, and he implemented a deep learning library in Futhark, a parallel functional language. Performance was decent on the small networks we ended up with,
317.
by Athas 7y ago
It's good that Turing gets put on a banknote - and about time. However, the concept art in that article is really ugly. I'm not that familiar with British banknotes - are they usually that messy looking? Every piece of text is i
318.
Futhark by Example(futhark-lang.org)
2 points by Athas 7y ago|0 comments
319.
Futhark 0.12.1 released – now with sum types(futhark-lang.org)
2 points by Athas 7y ago|0 comments
320.
by Athas 7y ago
That sounds like a good idea. It would also give cities more incentive to keep the like lanes well maintained (even in bike-friendly cities, bike lanes are usually less well maintained than motorways). One problem is that bike lanes are o
321.
Ray Tracing in One Weekend in Futhark(github.com)
6 points by Athas 7y ago|0 comments
322.
by Athas 7y ago
I haven't read the paper yet, but I think it's exactly about differentiating (semi-)arbitrary functions written in a conventional-ish programming language.
323.
by Athas 7y ago
Recommending papers I have read: - Rebuilding Racket on Chez Scheme (experience report) . A very applied and very readable report on an impressive project to re-target a significant existing compiler. Especially recommended if you normally
324.
Towards Size Types in Futhark(futhark-lang.org)
1 points by Athas 7y ago|0 comments
325.
by Athas 7y ago
These pictures are wonderful. Far better than the soulless CGI renderings found in most textbooks!
326.
by Athas 7y ago
The Oberon system has drivers in, well, Oberon (which is a high-level Pascal successor with garbage collection). Low-level memory access is done through magical peek/poke functions, in which all the dirtyness is concentrated (and thes
327.
by Athas 7y ago
> I think CS and EE may need to de-emphasize conferences and try to improve journals. I agree. Both because it may lead to a more reasonable working pace (we have the Internet for low-latency dissemination anyway), but also because the
328.
by Athas 7y ago
I remember when this was a significant problem but with the rise of UTF-8 it is less so (even if that is strictly against the letter of the spec, it works fine in practice). Are there languages where the 510 bytes per message are a signifi
329.
by Athas 7y ago
+1 for patat. If you can live with its limitations, it is by far the most pleasant presentation writing experience I know of.
330.
by Athas 7y ago
I have not been able to inspect the code (dead links), but from the description of their approach, they do not depend on anything particularly fancy from CUDA. An OpenCL implementation seems just as feasible.

More ›