Petalisp: Elegant High Performance Computing
github.com
github.com
Elegant High Performance Computing
# Performance [benchmarks?]
Coming soon!
This is someone's project that is still in development. The person who posted this on HN and the person who created this project are not same. The benchmarks will become available when they will become available.
See: https://en.wikipedia.org/wiki/High-performance_computing
As you may have seen on the commit history, a lot of exciting things have happened over the last few months. However, there are also a few stupid performance bugs left, so I am delaying the release of any performance numbers until those have been fixed. Otherwise, I fear that people will simply misinterpret the results.
Nevertheless, I can already state that the single-core performance of Petalisp programs is exactly like that of a C program - simply because Petalisp compiles its programs to C when possible. (Although I also have that long-term agenda of using sb-simd to reach that performance in pure CL some day.)
In addition, Petalisp is quite good at automatically parallelizing programs, and we already have most of the infrastructure for distributed and heterogeneous computing in place.
I will write a more detailed post for the HN crowd once I have reliable performance numbers and once I finished writing the documentation.
Feel free to ask me further questions.
About the required hardware - anything that runs SBCL or CCL can also run Petalisp.
To the best of my knowledge, shared memory approaches have been mostly abandoned in the HPC community. It seems none of the codes that went hybrid MPI+OpenMP for example, ever saw substantial performance benefit over pure MPI. At least not enough to justify the increased code complexity. If you search for "hybrid MPI/OpenMP" on Google Scholar you'll see most results are 10-20 years old.
Part of the reason for this is that on modern CPU cores with the amount of cache available, you typically want to keep at least something like 200 000 degrees of freedom per core. That's e.g. a 36^3 grid for u,v,w,p if you're doing fluid mechanics. Then the amount to communicate per core is just 8% of the total data. Furthermore you can easily do other work like compute auxiliary variables while you are waiting on communication.
I will also say that it feels a bit weird to call something "peta-" and "HPC" if using more than one socket is relatively far off into the future. For the randomly-wandering PhD students out there, it would be nice to tell them this up front in the Readme :)
This is no special casing. Most of that code will also be used for the distributed parallelization. I agree with your remarks on hybrid MPI+OpenMP, and, in fact, Petalisp doesn't use shared memory anywhere, but always generates ghost layers and explicit communication.
> I will also say that it feels a bit weird to call something "peta-" and "HPC" if using more than one socket is relatively far off into the future. For the randomly-wandering PhD students out there, it would be nice to tell them this up front in the Readme :)
I can do that. But let me explain the rationale for naming Petalisp this way: I wanted to create a programming language that is novel, and that has the potential to scale to petaflop systems. And I wanted to create a robust implementation of that language. I think I have achieved the former part, but the latter simply takes time.
Final remark: Good HPC practice is always to get single core performance right, then getting multicore performance right, and then scaling up to multiple nodes. Anything else is an enormous waste of electricity.
There's a trend where projects are marketed as 'blazingly fast', yet when benchmarked fall several orders of magnitude behind near optimal solutions. It's a knee jerk reaction of mine to call out when statements around performance are made without benchmarks.
Looking forward to seeing more about this project! I learned to program with CL way back when, makes me happy to see when people are working on big projects in it. Cheers!
How true is this? I've learnt both CL and Python and it took me an order of magnitude less time to learn CL.
That's only obvious if you already know another language. IME, Lisp-likes are neither worse nor better than Python-likes for beginners.
I don't understand your point. The time to learn Python for someone who knows Python is 0, obviously. But then the time to learn CL for someone who knows CL is also 0. What's your point?
I wanted to find out whether others who have learnt both Python and CL also find CL easier to learn than Python like I did.
Your answer tries to be clever but ignores my actual question!
Perhaps that the number of people who already know Python is significantly larger than those who already know CL?
For example, the intro to programming classes that physicists take (ie those that might end up writing HPC code) at the University I went to has been Python-based for well over a decade.
Though I had exposure to Python before various lisps, I see most lisps as simpler to learn than Python. But I also see the Python ecosystem as easier to StackOverflow your way to something that does the task at hand. But this is just, like, my opinion.
I've also taught and watched teaching of roughly the same data science curriculum to total novice Python programmers and total novice R programmers (R being very lispy). The R classes pretty much universally run laps around the Python classes. Again, just anecdata, because the Python classes tended to be attended by hard sciences people (e.g. physics) while the R classes tended to be attended by social scientists. From that experience, I have a hypothesis that either 1) R is easier for beginners than Python, 2) the R ecosystem is better for quantitative research science, or 3) social scientists are smarter than physicists.
1. Peta - https://www.hpcwire.com/off-the-wire/julia-joins-petaflop-cl...
2. Lisp - https://discourse.julialang.org/t/cas-benchmarks-symbolics-j...
Julia has a lisp origin story, see also: https://github.com/JeffBezanson/femtolisp
I don’t know how mature it is, but it’s sale pitch really speaks to me.
> Lisp-Stat is a domain specific language (DSL) for statistical analysis and machine learning. It is targeted at statistics practitioners with little or no experience in programming.
A lisp dialect called XLisp was developed by David Betz in the 1980's. (AutoCad's original AutoLisp was forked from this.) A Luke Tierney wrote a statistical package for it called XLispStat, and in 1990 that same author wrote a book on it called "LISP-STAT: An Object-Oriented Enironment for Statistical Computing and Dynamic Graphics".
This Lisp-Stat looks like a distro of packages for Common Lisp, with a base project that unifies them.
This is just a backbone for array computations, at a lower level than numpy. It's more about JIT-compilation of a small handful of operations than math overall
It might be easier to write correct code in (emphasis on the might).
You could say lisp is more elegant though, as everything is an expression and the language is homoiconic.
There's degrees of truth to this. For example, most production lisps will compile functions to native code instead of storing the literal list of expressions. It's easy to manipulate lisp code before that happens but there's certainly a point where the homoiconicity is sacrificed.
Check out "The Definition of Standard ML" to get a sense of what a (mostly kosher) formal programming language definition might look like.