Reasons to Love the Field of Programming Languages
42 points by danilafe
42 points by danilafe
Whoah, Chapel's sort performance numbers look insane. What's the secret?
The short answer is "parallelism". This is explained more if you just click "Learn More" off the page you probably saw (leading to https://chapel-lang.org/blog/posts/std-sort-performance/). { EDIT: A corollary is that it probably depends a lot on what computer you run it on, as do almost all benchmarks, but to their credit they actually list some basic machine properties at the bottom of the page. Personally, I would be happier with OS/another microbenchmark-realized memory bandwidth than hardware-specified, but I'm pretty picky about such things. }
EDIT2: On a side-note, in case any Chapel experts swing by, I think it's pretty neat that they include GNU long options style parsing in the language, but is there any way to get boolean flag combining CL-syntax (e.g.. grep -ivfMyFile)?
Certainly the performance depends a lot on the hardware, in this case maybe more so than in others because you get a whole new axis along which systems may vary (capacity for parallel execution). That said, I think the general point is that most of today's hardware does support parallelism, and though the precise speedup from using it might vary, it will be there.
is there any way to get boolean flag combining CL-syntax (e.g.. grep -ivfMyFile)?
I thought it might be possible to get the desired syntax using ArgumentParser, but no cigar. I suspect we don't have this by default for config variables because (among other things) it's an open question how the user should indicate whether they want option combining or not. I agree that this is desirable, so I've opened https://github.com/chapel-lang/chapel/issues/28253 as a feature request.
Of course, Re: amount of HW parallelism varies by several to many orders of magnitude these days, but almost any HW has at least some to be used. 100% agree and never meant to suggest otherwise - just the really wide range.
Anyway, thank you very much for opening the CL-syntax issue, @danilafe. I suppose in a dream world, the binding between the config stuff and the actual CLI syntax would be "pluggable" to some extent (if only at compile-time), but I have zero idea what is hard/easy within the existing Chapel code base. We'll see what can maybe be done.
Lovely written blog post.
The difference between HDL and PL is becoming less over time with open-source work and utilization of PL concepts in HDLs, see for example https://en.wikipedia.org/wiki/Hardware_description_language#HDL_and_programming_languages. As example, current mainstream HDLs do not capture high-level design intent (for faster optimizations etc).
Does Chapel have a concept for hardware-software co-design, for example via targeting SystemC/TLM ? I'd be curious, if you know any languages that attempt this or what you think is possible.
Thank you!
It's an interesting area in the language world. I think it's a natural idea to apply theoretical PL fundamentals to designing an HDL. And so, instances of such applications spring up quite often. I've seen numerous papers outlining HDL designs, and I've stumbled across Clash more than once. On the other hand --- and my experience here is stale by nearly a decade at this point --- (System)Verilog continues to dominate actual FPGA development. So for all that theoretical foundation developed elsewhere, you're still using something that has a very ad-hoc, "get things done" feel. I suppose that's a general concern in PL: we have something like an ivory tower of theory, and a largely disjoint body of practice.
To the best of my knowledge, hardware-software co-design is out of scope for Chapel. I'm also not aware of any languages with such a notion, though I do find it intriguing. Unfortunately, that's as much as I can contribute on that topic :)