[HN Gopher] Petalisp: Elegant High Performance Computing
___________________________________________________________________
Petalisp: Elegant High Performance Computing
Author : mpweiher
Score : 125 points
Date : 2023-07-09 10:08 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fredrikholm wrote:
| 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?
| MarioMan wrote:
| 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.
|
| See: https://en.wikipedia.org/wiki/High-performance_computing
| jackdaniel wrote:
| 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.
| norir wrote:
| Regardless of their skill, they only get one chance to make a
| first impression.
| CodeSgt wrote:
| We don't know if they chose to share it on HN just yet or
| if this post was made by a fan of the project.
| phoe-krk wrote:
| A fan, the author of Petalisp is
| https://news.ycombinator.com/user?id=heisig
| jackdaniel wrote:
| I don't know what do you try to convey. The link is shared
| by a third-party.
| heisig wrote:
| 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.
|
| Feel free to ask me further questions.
| medo-bear wrote:
| This would be an exciting read. Im cretainly looking forward
| to it. Is there a read me for the required infrastructure
| setup in the works?
| heisig wrote:
| 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.
| medo-bear wrote:
| Sorry I should have been more specific. I meant a
| distributed computing system setup
| heisig wrote:
| 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.
| distcs wrote:
| > 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.
| thumbuddy wrote:
| 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.
| moelf wrote:
| the name Petalisp cracks me up, because that's basically what
| Julia is:
|
| 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
| wodenokoto wrote:
| Lisp stat landing page basically sounds like Julia, except they
| "kept" the syntax and it can compile.
|
| I don't know how mature it is, but it's sale pitch really
| speaks to me.
|
| https://lisp-stat.dev/
| nsajko wrote:
| 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.
| vindarel wrote:
| It's a "DSL for stats" and also a Common Lisp library. So
| yes, you have a general-purpose programming language at
| your disposal.
| Archit3ch wrote:
| Also in the "Julia that can compile" family:
| https://lbstanza.org/
| nsajko wrote:
| 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".
| jballanc wrote:
| 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.
| abrax3141 wrote:
| 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.
| ianai wrote:
| Sounds like it's mostly lisp. How mathematically correct and
| proven (in the math sense) is lisp?
| ravi-delia wrote:
| 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
| alecmg wrote:
| without knowing much of either, sounds like petalisp to lisp
| relation is numba to python. Or numba to numpy?
| thumbuddy wrote:
| Do you mean what guarantees does Lisp offer? Not sure what you
| mean.
| [deleted]
| tmtvl wrote:
| If you want to prove your Lisp, you can always boot up ACL2. It
| was used (for example) to formally verify Buchberger's
| algorithm: <https://www.sciencedirect.com/science/article/pii/S
| 074771710...>
| WanderPanda wrote:
| 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
| reikonomusha wrote:
| You would aim to prove properties of the formal semantics
| of a language, but that requires the language be described
| in a formal manner.
|
| Check out "The Definition of Standard ML" to get a sense of
| what a (mostly kosher) formal programming language
| definition might look like.
| bella001 wrote:
| [dead]
| theLiminator wrote:
| There's nothing that makes lisp mathematically more correct.
|
| 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.
| matheusmoreira wrote:
| > 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.
| jackdaniel wrote:
| 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.
| eigenspace wrote:
| This is a nonsense question. It's like asking "how
| mathematically correct and proven is this rock?"
| distcs wrote:
| > Not everyone has the time to learn Common Lisp.
|
| How true is this? I've learnt both CL and Python and it took me
| an order of magnitude less time to learn CL.
| ravi-delia wrote:
| 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.
| peatmoss wrote:
| 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.
| distcs wrote:
| > 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!
| ravi-delia wrote:
| 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.
| magicalhippo wrote:
| > What's your point?
|
| 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.
| shakow wrote:
| > we'd obviously expect basic python to take less time than
| basic CL
|
| That's only obvious if you already know another language.
| IME, Lisp-likes are neither worse nor better than Python-
| likes for beginners.
___________________________________________________________________
(page generated 2023-07-10 23:01 UTC)