31–40 of 269 posts
What is the terminal used for that demo? https://github.com/HigherOrderCO/Bend does it just skip commands it cannot execute or?
It was actually just me recording iTerm2 with OBS. The theme is Solarized Light. What do you mean by skip commands?
> That's a 111x speedup by doing nothing. No thread spawning, no explicit management of locks, mutexes. We just asked bend to run our program on RTX, and it did. Simple as that. Note that, for now, Bend only supports 24-bit machine ints (u24), thus, results are always mod 2^24.
Ahh, not even 32bit? Hmm, that seems pretty arbitrary for someone not accustomed to gpu's and wanting to solve some problems requiring 64 bits (gravitational simulation of solar system at millimeter resolution could use ~58bit ints for position).
I know the docs say this will be fixed soon, but what is the main reason for restricting number types to 24 bits? I saw in the code that they are wrapper around the 32-bit system number types, so what prevents Bend from changing them to U32(u32) right now?
Congrats on the launch. I know the docs say this will be fixed soon, but what is the main reason for restricting number types to 24 bits? I saw in the code that they are wrapper around the 32-bit system number types, so what prevents Bend from changing them to U32(u32) right now?
Short answer: GPU
Long answer: CUDA
Seriously though. Implementing a full high-level lang in parallel is HARD, so, to simplify it greatly, we made IC nodes 64-bit, which allows us to use native 64-bit atomic operations in many parts of the implementation. Since each 64-bit node has 2 ports, that gives us 32 bits per port. And since we use 3 bits for the tag, that leaves us with 29 bit payloads. We used that space to easily implement unboxed numbers (f24, u24, i24).
That said, we will have (boxed) 64-bit numbers soon! With this foundation in place, adding them is a matter of coding. I just want to have some time to let people use the limited version, find bugs, etc., before I add more stuff.
Looks cool but what's one toy problem that it can solve more efficiently than others?
Here is an example of it summing a huge set of numbers 100x faster than in C. https://github.com/HigherOrderCO/bend/blob/main/GUIDE.md#par...
Running the equivalent C code takes ~2.3 seconds on my machine. Same order of magnitude as bend on the beefy GPU.
Eeek.
I think I have a use for this but I’m realizing that I don’t know how to build a mental model of what is going to parallelize in this system. Surely some algorithms are better and getting chopped up than others - how can I tell what is going on?
You could get some sense of the parallelism by using `/usr/bin/time` and dividing the wall time with the user time.
You could look at the Task Manager / Activity Monitor / htop and see if it's using 800% CPU or whatever.
You could use psrecord (https://pypi.org/project/psrecord/) to get a relatively finegrained CPU+mem usage graph across the duration of the program.
But it would probably still be best to record some sort of stats in the Bend/HVM itself, enabled via a CLI flag. Reductions per ms, sampled across the program duration, or something like that.
I'd be interested in anybody's ideas of what a good metric would be here!
EDIT: CLI flag, not CPU flag