PIM-Programming-In-Spiral-UPMEM-Demo
chapel
PIM-Programming-In-Spiral-UPMEM-Demo | chapel | |
---|---|---|
5 | 26 | |
2 | 1,745 | |
- | 1.3% | |
10.0 | 10.0 | |
over 1 year ago | 1 day ago | |
Python | Chapel | |
Mozilla Public License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
PIM-Programming-In-Spiral-UPMEM-Demo
-
Ask HN: How do I get the most benefit out of my programming language?
I originally started work on [Spiral](https://github.com/mrakgr/The-Spiral-Language) back in late 2016 because I wanted a functional language in which I could program novel AI hardware that hadn't existed at the time, and still doesn't, but it won't be long before it arrives. It took 3 years of full time work to get it to its current standard of quality, and I'd really feel comfortable programming new hardware devices in my favored functional style. I've designed Spiral so it is both extremely powerful, easy to use while being efficient enough to program devices like GPUs that can't even use heap allocation for their objects.
I am not really concerned about what I'll do when I get access to Tenstorrent chips in six months; my personal needs for the language are met. But I would like it if I could spread the language more broadly, make it useful for people other than myself and get people to sponsor my work on it.
Here is the value proposition of Spiral.
It is a high-level functional PL that has some features that other languages don't, but that isn't really the point. On mainstream devices like the x86 ones there are a lot of programming languages that are good, and it would be tedious to use Spiral to compile to such platforms compared to using such languages directly. It is a bit how ReasonML compiles to JS. Back when I tried it I found using Typescript easier to deal with. So that is not where I'd like to go into, though using Spiral would have benefits in certain areas.
Rather, while reading the [CNX blog](https://www.cnx-software.com/) I realized that while consumer facing AI chips are not here yet, there is a lot of hardware development in the embedded space. They are heterogenous architecture. They have GPU and TPUs in addition to CPUs. And these cross platform interactions within the same system is something that existing languages are really poor at tackling.
If you look at Python or C#, for example, you can't really program the GPU on them directly. They are CPU focused, and don't have the right semantics and would be too inefficient to program devices like GPUs directly. The way I've designed Spiral is that you can program the CPU and the GPU and whatever else from within the same language.
It is not suitable for just GPUs, check this [demo out](https://github.com/mrakgr/PIM-Programming-In-Spiral-UPMEM-Demo). I recently did a backend for UPMEM devices, which are the first commercialized Process-In-Memory chips. I've posted the link to this on HN yesterday and on the Reddit embedded sub, but I got zero interest. And this is really a pity because that map kernel I've demoed is actually a big deal. Back when I first started working on Spiral, it took me 1.5 years of full time work to get to the point where I could write a program like that in the language. And without backend nesting of the kind that Spiral offers, it is impossible to write those kinds of programs no matter how skilled one is as a programmer.
The kind of backend nesting I've demonstrated is not something you can do in F#, Python or any of the languages that I know of. I could easily create such backends for many kinds of hardware. And people would benefit from that because unlike the mainstream computing devices, the hardware coming down the pipeline will have poor language support, nothing on the level of what Spiral offers. For the kinds of heterogeneous architectures I am envisioning, the language designs that are good in the CPU-dominant era, will simply not be suited in the heterogeneous era.
I need chances to demonstrate how good Spiral is, but I am not sure how to get them. If I do not get them, the future of computing will be a lot worse off. I wasn't there when Cuda was incumbent so I missed the boat on that, but I'd like it if Spiral became dominant on future computing devices. Not because I was the one who made the language, but simply because no other design is as suited for them.
- Show HN: PIM Programming in Spiral: Upmem Demo
- PIM Programming in Spiral: Upmem Demo
- PIM Programming In Spiral: UPMEM Demo
- PIM (Process In Memory) Programming In Spiral: UPMEM Demo
chapel
-
Introduction to GPU Programming in Chapel
Thanks, @subharmonicon!
While Chapel can run on many different systems, the main goal is making HPC programming much easier. Therefore, we are currently focusing on hardware that you can find in HPC systems (NVIDIA, AMD and Intel). Metal doesn't fall into that category, unfortunately. So far, the name came up infrequently in our discussions IIRC (especially targetting SPIRV), but we haven't heard from any [potential] user who may be interested in it. I would encourage you or anybody else interested in it to create an issue asking for the feature: https://github.com/chapel-lang/chapel/issues/new. Seeing public interest in that direction can change our prioritization.
One thing that I wanted to add that's not in the blogpost is the "cpu-as-device" mode. With that mode, you can use any machine, even one without a GPU, to write applications using Chapel's GPU features. That mode is for those who want to do initial development/debugging on their personal laptops before putting their application on an HPC system. In other words, while you can't use Metal directly, you can still write GPU-enabled applications in your Mac using Chapel, if the end goal is to run it on an HPC system. More details on cpu-as-device: https://chapel-lang.org/docs/main/technotes/gpu.html#cpu-as-...
-
Mojo is now available on Mac
Agreed. Here is a serious contender[0] minus all the hype and the $100M in VC money. You would expect a minimum of interest given how Mojo is received by the community, but not really in practice.
[0]: https://chapel-lang.org/
- Chapel 1.32.0 Released
-
Rust vs. Julia in Scientific Computing
Cray is pushing their own language as well, Chapel.
https://chapel-lang.org/
As for Julia on Cray,
"Julia — The Newest Petaflop Family Language We Have Started to Love"
https://www.avenga.com/magazine/julia-programming-language
> Julia is one of the few languages that are in the so-called PetaFlop family; the other languages are C, C++ and Fortrant. It achieved 1.54 petaflops with 1.3 million threads on the Cray XC40 supercomputer.
-
What languages are we missing on devenv.sh?
https://chapel-lang.org if possible, Nix was also recently mentioned in Chapel Workshop https://chapel-lang.org/CHIUW2023.html https://github.com/twesterhout/nix-chapel
- Chapel: Programming Language for Parallel Computing
-
Getting Past “Ampersand-Driven Development” in Rust
See Val for a possible step into that direction.
https://www.val-lang.dev/
Or how the Chapel language for HPC is going at it,
https://chapel-lang.org/
-
Ask HN: How do I get the most benefit out of my programming language?
I suggest posting to a PLT focused resource, such as http://lambda-the-ultimate.org/
That said, a bit confused about the languages you reference in this context (Python, C#, JS) - didn't see any mention here or at your github repo of languages (some relatively ancient) in this space designed.
Sandia: Programming Languages for HPC [high performance computing] - is there life after MPI?
https://www.sandia.gov/app/uploads/sites/179/2022/04/SOS10-T...
Chapel:
https://chapel-lang.org/
https://en.wikipedia.org/wiki/Category:Array_programming_lan...
-
Twelve Days of Chapel: Advent of Code 2022
We needed the implicit conversion to `uint` in order for the overload resolution rules to make reasonable choices when faced with binary overloads for all of the numeric types. The document I linked talks through the examples. The case we were facing is something that we shared with `C#` -- in `C#` terms, if I make overloads for `f` for all numeric types (see https://github.com/chapel-lang/chapel/blob/main/test/types/coerce/allNumericsBinary.cs if you want to know exactly what I am talking about), then `f( myInt, myUlong )` runs `f(float, float)` which makes no sense. Especially if you care about numerical accuracy or program performance.
-
-🎄- 2022 Day 8 Solutions -🎄-
Code | Blog Walkthrough
What are some alternatives?
zls - A Zig language server supporting Zig developers with features like autocomplete and goto definition
ATS-Postiats - ATS2: Unleashing the Potentials of Types and Templates
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
hacktoberfest-swag-list - Multiple companies go above and beyond for Hacktoberfest, and this repo tries to list them all.
gsoc-organizations - A site for viewing and analyzing the info of the organizations participating in Google Summer of Code.
jmurmel - A standalone or embeddable JVM based interpreter/ compiler for Murmel, a single-namespace Lisp dialect inspired by Common Lisp
hacktoberfest - Hacktoberfest - App to manage the annual open-source challenge, used for the 2019 & 2020 seasons.
tigerbeetle - A distributed financial accounting database designed for mission critical safety and performance. [Moved to: https://github.com/tigerbeetledb/tigerbeetle]
swift-corelibs-foundation - The Foundation Project, providing core utilities, internationalization, and OS independence
ffmalloc
adventofcode - Advent of code solutions
redoc - 📘 OpenAPI/Swagger-generated API Reference Documentation