go / golang and swi-prolog

[Dan]

Hi, 

I just read a great article on go / golang and why its a great language for concurrent programming. 

https://medium.com/@kevalpatel2106/why-should-you-learn-go-f607681fad65

I wonder how prolog compares when it comes to multithreaded programming -- in terms of efficiency; and whether go could be an alternative to C for developing external libraries. 

thanks,

Dan

[Peter Ludemann]

I suspect that Erlang beats Go for concurrent programming.

You can find out more by doing a web search for [erlang whatsapp rick reed] ... Rick Reed wrote the high performance process switching code that Yahoo! used for FreeBSD (similar to "Doors" on SunOS), so if he thinks that Erlang is better than C++ for concurrent programming, I'm inclined to believe him.

As for Go -- it has a fairly nice "channel" design for IPC, with a few caveats such as the possibility of blocking if you don't make the buffer big enough (this might have been fixed more recently.

--
You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.
Visit this group at https://groups.google.com/group/swi-prolog.
For more options, visit https://groups.google.com/d/optout.

[Dan]

Thanks, 

The medium article has a chart comparing Erlang with Go -- on a dimension of performance -- and it seems that Go is, at least along this dimension, considered more performant. 

Dan

[Peter Ludemann]

I would put Erlang far to the right of Go in terms of "beautiful, straight code". (Or, rather, Go should be farther left).

As for concurrency performance; that depends on a lot of factors. I once sped up some concurrent code by about 2 orders of magnitude by nothing more than reducing the number of context switches from conventional threading. I don't know enough about the details of Erlang's and Go's implementations to know whether this would account for Erlang's performance (that is, Erlang gains by its multiprocessing model that (probably) minimizes context switches; but loses because it runs as bytecode on a virtual machine vs Go's native code). 

Also, Go code needs a rewrite/redesign to scale across multiple machines (channels only work within a single (multi-core) machine) -- there's something called Vice, which extends the channel concept across machines, but I don't know its performance vs Erlang.