Elegant High Performance Computing
# Performance [benchmarks?]
Coming soon!
I've seen quite a few elegant and within-an-order-of-magnitude-of-semi-optimized-C CL programs throughout the years, but can one make such a statement without benchmarks? What do we mean by high performance?
Petalisp author here. I apologize that the README is somewhat lacking, but it wasn't me who posted this on HN.
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.
Thank you for responding. I wrongfully assumed that this was posted by yourself, if I had taken the time to understand that it was posted by someone else I wouldn't have made such a remark.
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!
I am not sure what you mean by "required infrastructure setup". Installing Petalisp is a single call to (ql:quickload :petalisp) - assuming you have Quicklisp installed. If you also have a C compiler available, and an executable named cc pointing to that compiler, Petalisp will use that to speed up your codes further.
About the required hardware - anything that runs SBCL or CCL can also run Petalisp.
Thanks for clarifying. I will definitely write down the specifics of setting up distributed computing once it works. However, support for distributed computing will still take some time. The current step is to iron out all the remaining issues of parallelizing within one CPU socket.
I'm very curious why you've chosen to go down the route of special casing on parallelizing within one socket, which I take to mean some form of shared memory paradigm?
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 :)
> I'm very curious why you've chosen to go down the route of special casing on parallelizing within one socket
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.
> I've seen quite a few elegant and within-an-order-of-magnitude-of-semi-optimized-C CL programs throughout the years, but can one make such a statement without benchmarks? What do we mean by high performance?
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.
In this context, High Performance Computing (HPC) refers to a computing paradigm where high-performance computers work on a distributed problem (e.g., supercomputers), not the actual performance of this code generator. All it means here is that it generates parallel, distributed code intended for use by HPC platforms.
While I'm not using Petalisp I can attest that Marco is known for delivering high quality software with a strong focus on performance. I suspect that the phrase "Coming soon!" means exactly that - when he'll make them they will be published.
I also share this concern. I hope it at least beats out naive implementations of these algorithms, but I wouldn't be surprised if it was far from SOTA or standard tooling.
I’ve thought many times - like literally every time I use Tf - that I should hack a Lisp interface to it. But, of course, PotAU, I never get a round twit.
Setting aside the fact that naively we'd obviously expect basic python to take less time than basic CL, there's plenty of people who are already working in python. So time to learn python (remaining) is 0, compared to non-zero for CL.
> So time to learn python (remaining) is 0, compared to non-zero for CL.
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!
I definitely found Python easier to learn, although now I find common lisp easier to use (Commas are terrible, and for what- infix syntax?). But in terms of why the README might say that not everyone has time to learn common lisp, my point was that it's just an obvious truism that more language bindings increases the potential userbase. To someone who already knows python, python bindings make using Petalisp that much easier. To someone who doesn't know Python, well then they can pick up Python or CL at their leisure.
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.
For everyone who has only ever seen a Python, plus a language or two that Python has shared a common ancestor with, Python is self-evidently the platonic ideal of an easy language.
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.
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.
Doesn't seem like a general purpose programming language:
> 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.
The "Julia that can compile" characterization is misleading, because Julia is based on LLVM-backed compilation (a Julia interpreter exists as a user package, however it's used only for debugging). I'd restate that as "Julia without the power of run-time on-demand compilation". Although your point was probably more in the direction of "Julia but it's trivial to get it statically compiled".
Getting Julia to statically compile is not even that hard anymore. I think people are merely turned off by the lack of a (consistent, well supported) story around distributing Julia apps as single, statically-compiled binaries.
Maxima is implemented in Common Lisp. The language features full numeric tower with bignums and rationals - generally it is a very good language for number crunching.
Depends on the implementation, but SBCL has all the usual suspects to decent precision. The standard specifies branch cuts and such, and I've never heard any complaints.
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
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.
How do you even prove a language? I can't even imagine how that would work. Do you maybe have a pointer on where this rabbit hole starts? The one you provided seems more like a deep pocket than an entrance
