[HN Gopher] The joy of concurrent logic programming
___________________________________________________________________
The joy of concurrent logic programming
Author : aarroyoc
Score : 88 points
Date : 2021-11-07 13:52 UTC (9 hours ago)
(HTM) web link (www.call-with-current-continuation.org)
(TXT) w3m dump (www.call-with-current-continuation.org)
| Syzygies wrote:
| "Especially today, where CPU designers have run out of ideas"
|
| I wonder how many readers made it past the formatting, only to
| stop reading here?
| dang wrote:
| Please don't pick the most provocative thing in an article and
| then copy it into the threads to complain about it. The most
| provocative thing is nearly always something shallow and barely
| (if at all) related. This leads to shallow/indignant
| discussions, which are the opposite of what we're going for
| here.
|
| It would be much better to find the most
| interesting/surprising/meaty thing and start a thread with
| that.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
|
| (Also, re formatting - see
| https://news.ycombinator.com/newsguidelines.html: " _Please don
| 't complain about website formatting, back-button breakage, and
| similar annoyances. They're too common to be interesting.
| Exception: when the author is present. Then friendly feedback
| might be helpful._"
|
| p.s. Your comments are usually excellent--thank you!
| Twisol wrote:
| What's wrong with the formatting? Plain text has a lot going
| for it. (I remember when most/all GameFAQs guides were text
| files just like this -- not to mention the Super Metroid guide
| [0] that manually justified every paragraph _via word choice._
| )
|
| [0] https://gamefaqs.gamespot.com/snes/588741-super-
| metroid/faqs...
| cylon13 wrote:
| On mobile it looks terrible. The lines will wrap and then a
| few words later there's a forced line break.
| Twisol wrote:
| That's a reasonable criticism. It works better in Reader
| View (because you can scale the font down, at least in
| Firefox), but I have to rotate to landscape as well.
| avgcorrection wrote:
| > What's wrong with the formatting?
|
| It messes up Firefox reader mode.
|
| I myself have gotten complaints from other people when using
| linebreaks in Github comments because their device renders
| them.
| matheusmoreira wrote:
| Yeah. GameFAQs guides had perfect usability. Now they're
| multipage HTML documents and searching is impossible.
| Sometimes the "guide" consists of nothing but YouTube links.
| carapace wrote:
| I kept reading but I did have a "hey, that's kind of unfair"
| reaction at that line. It's not their fault that the speed of
| light is a hard limit, eh?
|
| There's a chicken and egg problem with compilers and languages
| on the one side and machines architectures and instruction sets
| on the other, it's not easy breaking the mold. (GPUs are a
| counter-example perhaps?)
|
| CPU designers can't all be Ivan Godard (
| https://hackaday.com/2013/08/02/the-mill-cpu-architecture/
| https://millcomputing.com/ ) or Chuck Moore (
| https://en.wikipedia.org/wiki/Charles_H._Moore#Hardware_desi...
| http://www.greenarraychips.com/ ) eh?
| Syzygies wrote:
| > It's not their fault that the speed of light is a hard
| limit, eh?
|
| If you're at Intel, you not likely to see this as a calm
| period bereft of ideas, while Apple silicon has made such
| strides. New ideas, or simply a rebalancing of familiar
| ideas, can make significant progress against the same
| physics.
| [deleted]
| bidirectional wrote:
| Seems like a pretty innocent, tongue-in-cheek comment?
| convolvatron wrote:
| actually its a pretty substantive and spot-on comment. the
| cpu people have been trying _really_ hard to make existing
| workloads run faster.
|
| but the software people have known for 50 years that
| concurrency was going to be necessary to go further..but it
| was never really a good time.
|
| maybe we can finally start looking at other programming
| models instead of wasting so much time and getting such
| crappy reliability and performance out of thread-and-lock?
| PaulHoule wrote:
| My concern is how you batch things.
|
| If you pass single operations between threads you will run
| slower, not faster because of the synchronization overhead.
|
| Whenever I parallelize something I build batching in from the
| beginning. Most other people seem to think it is an optimization
| you can do later but the way I see if if your goal is to get any
| speed up at all batching is essential.
| Jtsummers wrote:
| > This implementation additionally can distribute pools of
| parallel processes over native OS level threads, thus taking
| advantage of multicore architectures. Locking overhead should
| be small, as data is normally not shared among processes
| executing on different threads.
|
| From: http://www.call-with-current-
| continuation.org/fleng/fleng.ht...
|
| It seems the author has taken this into account, it's not a 1:1
| mapping of processes to OS threads.
| anonymousDan wrote:
| Yeah I agree but as the sibling said if you are not in a
| distributed setting and have an N:M threading model the
| overhead can be low enough it's often not such an issue. But
| otherwise I'm a little unclear whether concurrent logic
| programming supports e.g. asynchronous comms with pipelined
| requests. If not I guess to some extent you could do it at the
| application level?
| Siira wrote:
| This is simply not true if the overhead is much smaller than
| each one operation. But I agree that batching matters.
| PaulHoule wrote:
| For my current side project I am making collages out of
| images I took with my DSLR. I like to use expensive scaling
| algorithms because I'll have to look at the result when I am
| done.
|
| For this the natural 'batch' is one image and that justifies
| the overhead easily.
| marcle wrote:
| This is a very interesting article.
|
| The author notes: "There is a compiler for KL1 to C available
| [2], which seems to work, but suffers from bit rot." Note that
| Ueda and colleagues have been updating this software (KLIC): see
| https://www.ueda.info.waseda.ac.jp/software.html for details.
| Ueda's work on LMNtal is also very interesting.
| triska wrote:
| Definitely an interesting read! I have a few comments about the
| following paragraph specifically, because the potential of
| convenient string processing is so essential to logic
| programming:
|
| _" As in Prolog, strings are lists of character codes which
| makes them automatically suitable for stream processing. Apart
| from avoiding the tedious duplication of list and string
| manipulation operations, this allows for efficient, asynchronous
| handling of streams of characters, so the extra space needed for
| lists is partially balanced by manipulating them in a lazy
| manner, one piece at a time, by communicating processes."_
|
| In Prolog, the meaning of double-quoted strings depends on the
| value of the Prolog flag double_quotes. Only if it is set to the
| value _codes_ are double-quoted strings interpreted as lists of
| codes. However, a much better setting is the value _chars_ , and
| then double-quoted strings are interpreted as lists of 1-char
| _atoms_. For example, with this setting, we have:
| ?- "abc" = [a|Ls]. Ls = "bc".
|
| This is the default value in all of the three newest Prolog
| systems: Scryer Prolog, Tau Prolog and Trealla Prolog. It was
| also the original interpretation of strings in the very first
| Prolog systems, Prolog 0 and Marseille Prolog, which were
| designed for natural language processing. Lists of characters
| ensure that strings are very readable, also when emitted in their
| canonical representation. For example, Scryer Prolog yields:
| ?- write_canonical("abc"). '.'(a,'.'(b,'.'(c,[])))
| true.
|
| The mentioned advantage of "avoiding the tedious duplication of
| list and string manipulation operations" in this way can hardly
| be overstated: It is massive, because everything one knows about
| lists carries over directly to strings, including common
| predicates such as append/3, length/2 and reverse/2 which even
| beginning Prolog programmers universally know, and the ability to
| _generalize_ arbitrary elements by using logic variables at
| desired positions, obtaining partially instantiated terms such as
| "all strings of length 3" which can be specified symbolically as
| [_,_,_]. In addition, lists are especially conveniently reasoned
| about with Prolog's built-in grammar mechanism, definite clause
| grammars (DCGs), tailor-made for generating and parsing sequences
| and therefore also strings. And further, "the extra space needed
| for lists" can be avoided with a compact internal representation
| of lists of characters, i.e., encoding them as sequences of raw
| bytes, using UTF-8 encoding. This efficient representation is
| currently already implemented in Scryer Prolog and Trealla
| Prolog.
| Twisol wrote:
| Concurrent constraint programming is especially interesting to me
| -- Saraswat's ideas about a general constraint store (versus the
| Herbrand domain Prolog is usually instantiated over) are
| genuinely fascinating to me. I see the relatively recent work on
| LVars as an example of where that flexibility really pays off.
| OliverM wrote:
| The author doesn't mention it but Concepts, Techniques and Models
| of Computer Programming by Haridi & Van Roy teaches concurrent
| logic programming (as part of a tour through a wide variety of
| programming models, including logic programming, stateful
| concurrency, and constraint programming). It's a great
| introduction to the paradigm. The full text is available online:
| https://www.info.ucl.ac.be/~pvr/VanRoyHaridi2003-book.pdf
| jhoechtl wrote:
| They use Mozart as the programming language of choice.
|
| The book is a much underappreciated gem
___________________________________________________________________
(page generated 2021-11-07 23:01 UTC)