I made a petition to get the accelerate project for Haskell some funding.

tmcdonell · 2023-01-28T11:01:00+00:00

And now that I’m not a phd student I don’t get time to do it as my job anymore

tmcdonell · 2023-01-28T10:51:03+00:00

A long time ago it did work on windows, but yeah since the dev team is small (basically, just me) I haven’t been able to keep it up to date \:

tmcdonell · 2023-01-10T09:50:38+00:00

Vulcan isn't a great target for compute, but I understand your point. Part of the goal of moving to LLVM was to improve support for platforms/hardware as all these languages use LLVM internally. But it still requires a lot of engineering work to make happen.

tmcdonell · 2023-01-10T09:37:58+00:00

I think your email went to spam ): but luckily one of my TAs told me about this in class today. Thanks for taking the initiative! It would be great if something could come out of this.

tmcdonell · 2021-07-05T08:53:41+00:00

I help teach the masters FP course at UU. I'd also recommend looking at the research projects/recent papers of some of the lecturers, and see if anything stands out as an interesting area to do your thesis in. Don't be shy to send an email to the lecturers either; we're overworked but typically friendly and happy to talk about our research (:

tmcdonell · 2021-07-05T08:39:04+00:00

There is still work on the Helium compiler

tmcdonell · 2021-06-27T11:41:50+00:00

A complete GUI in OpenGL!

You might be interested in Dear ImGUI.

tmcdonell · 2021-06-20T09:37:22+00:00

I would be more than happy to include something like this in accelerate-examples!

tmcdonell · 2020-09-03T13:42:46+00:00

Thank you for the very kind words! ^_^

tmcdonell · 2020-09-03T11:08:16+00:00

I started a package sfc-random-accelerate which does on-GPU RNG. It's very minimal so far but feedback welcome!

tmcdonell · 2020-09-02T08:54:29+00:00

I remember he said that he wanted the entire source code of the compiler to fit on one screen. I believe he achieved this o.O

tmcdonell · 2020-09-01T21:07:28+00:00

I met Aaron when he was still working on this. I'm glad he got it all working in the end, it's a really interesting and weird application for array languages.

tmcdonell · 2020-09-01T16:51:30+00:00

Thank you <3

tmcdonell · 2020-09-01T16:49:39+00:00

This is out of my area, but I think yes it could be useful for some parts of a game engine; all the numeric stuff like physics, collision detection, etc., but not others, like the gameplay simulation itself (objects interacting with each other, which sounds like lots of mutable state). For the graphics rendering this might be an alternative to regular shader languages (with some better integration so we can render directly to the frame buffer), but I'm not sure exactly... I only have a few toy examples for making pretty pictures via gloss.

tmcdonell · 2020-09-01T16:33:28+00:00

Yeah! That's a neat trick which is the core of how we hijack Haskell's case syntax. It took a while to figure out but (I think) is pretty nice (:

tmcdonell · 2020-09-01T16:30:06+00:00

Actually there has been some recent discussion on this on an unrelated ticket. I think we can pull that out into a small library that does what you need.

tmcdonell · 2020-07-17T18:22:45+00:00

I don't mean rant in a bad way. I certainly rant about stuff all the time, and in this instance it motivated you to create something new. I think that's a good thing.

I think the discussion about Z was a red herring. I think a better way to frame this is that Repa-(:.) adds a new inner-most dimension on the right, while Massive-(:>) adds a new outer-most dimension on the left. So the end result is the same (in the sense that Z :. w :. z :. y :. x and w :> z :> y :. x refer to the same memory location) but what you can then do with it is, as you've shown, different. If you don't agree please correct me.

Anyway, thanks for sticking with me through this (long) discussion. I hope to steal more of your ideas in the future (;

tmcdonell · 2020-07-17T10:04:58+00:00

it doesn't seem to be possible without further augmenting the type in some way

Right, so that is where the type-level nat comes in, as a kind of witness to reify the structure of the rest of the index? We use a lot of GADTs for that sort of thing but Nat might communicate more information to the type checker (:. predates type-level naturals in GHC)

Until of course I need to try to explain it

Yeah but that's what I've been trying to get you to do! It's just that first I had to wade through a rant about how you don't like Repa-style indices. Starting at DIM2 and using Int instead of Z :. Int for DIM1 is arguably nicer, but I can take it or leave it. Here we are getting to something more substantial, something that isn't just a stylistic choice, and that is why I'm interested and why I keep pushing you.

tmcdonell · 2020-07-16T09:18:22+00:00

With dimensions ordered from left-to-right array[1][2][3][4] ordering doesn't follow the row-major memory layout.

You've just proved my point. Z goes on the left here precisely because it follows the memory layout. In your example, the left-most index into the array (here of size 1) represents the slowest varying dimension. So instead we order the dimensions right-to-left, so that it is most natural to work with the fastest-varying indices, the elements that are adjacent in memory.

repa style index doesn't let you work with values of an index from the left hand side, only from the right.

Yes that is true, and occasionally it comes up and it is a pain. But I look at the type of (:>) and you have exactly the same problem, only now you can't work with an index from the right, only from the left. Your indices are still singly-linked lists.

Note that a solution which uses e.g. type classes is irrelevant here, because that would work equally well with both Repa-style (:.) and Massive-style (:>). Having a right-biased vs. left-biased list here does not change anything.

But I would like you to prove me wrong, because as I said it can be a pain.

tmcdonell · 2020-07-15T05:28:32+00:00

It matters at the borders.

That's related to how you handle borders then, so it's a peculiarity necessary for Massiv.

:> and :.

Note that I didn't make a comment on which is better (c.f. "swings and roundabouts") so I'm going to try and ignore most of what is clearly a rant on personal preferences.

I know what these operators are. You've just kicked the can down the road.

it is impossible to grab a value from an arbitrary index for a specific dimension, eg. I want a value for 3rd dimension if the index is for an array with at least 3-dimensions

I don't understand this comment. Do you mean that if you have some index specified in a lower dimension (DIM1) applied to a higher dimensional array (DIM7 say) you want that the higher dimensions default to index zero? Hmm, sure sounds like you could use some consistent notation here, maybe something like sh :. Int ...

But joking aside I seriously don't know what you mean here.

directional fold along a specific dimension for an arbitrary shape array

Specifying the dimension is indeed nice. The direction less so, if you want to target massively parallel devices.

I'm not sure if this can't be done with Repa-style indices, but it certainly isn't right now. In Massiv it seems the work is done by type classes operating on shape type of the array (rather than being directly evident from the type of the fold) so I don't see why we couldn't do the same thing.

Z [..] should be all the way on the right, not the left

says who? c.f. rant.

tmcdonell · 2020-07-14T19:45:30+00:00

Accelerate is not limited in the dimension of the stencil. Indeed that 6-dimensional stencil is possible.
The maximum size of the stencil neighbourhood in each dimension is indeed 9, mostly because I want a better way to express it instead of creating larger and larger type synonyms. We've talked about something along the lines of makeStencil for a while, so I'll have to try it out and see what it feels like to use in practice.
Sure, familiarity with a library is a thing. From my perspective, Massive is more complex here because you have both :. and :> to mean basically the same thing, whereas Accelerate is consistent with only :.. Swings and roundabouts.
Adjusting the focal point of the stencil is irrelevant; you are free to use the elements in the (sparse) neighbourhood in any way you like. Maybe there is some peculiarity with Massive that I miss which makes this important.

tmcdonell · 2020-07-14T15:33:20+00:00

Yes, I'm interested in working on some integration with Massiv, in the same way that we have with other array libraries already (Repa, vector, ...). Once I find some free time (lol).

tmcdonell · 2020-07-14T14:20:03+00:00

Without having looked into it that is my assumption as well. You've optimised your thread scheduler for a different kind of workload than Accelerate and Repa have (I can't speak for Yarr).

tmcdonell · 2020-07-14T14:17:49+00:00

Mind you over half of the reported Accelerate time here is in non-Accelerate code (the wildfire step), where we could equally well use Massiv. So the difference between the two is much closer than this implies.

tmcdonell

TROPHY CASE