I found this old mail on the swi-prolog mailing list archive about threads. It poses an interesting question: is multi-threading slower than single-thread?
Of course, since this mail is from 2002, it is utterly out of date when it comes to limitations of the current implementation and anyone referring to it to document shortcomings will be a moron.
Adrian Holzwarth said : “I’d guess that a swi-prolog with multi-threading running on a single-cpu-machine cannot run faster than a single threaded version. If you want to split the work to be done you need a second (or more :)) cpu to bother. Worse, otherwise you are creating overhead with dividing the work into pieces and managing the mess. And the lonesome single CPU has to do *all* the computing anyway, successive.”
Sebastian Sardina replied: “Indeed I do not expect the multi-threading version to run faster, but just equivalent if I do not use multi-threads at all. I understand that, but say you don’t do anything fancy: you just run a regluar Prolog program like the 9-queens example. So the problem is: why the multi-threading version of Prolog running a single thread is slower than the single-thread version of Prolog running the same single thread program?”
Jan Wielemaker also replied: “Right now the difference is neglectable on single-CPU Windows machines. The only remaining problematic area is dynamic code on Linux SMP machines that can be upto about 50% slower. Synchronization cannot be avoided here as the current implementation says dynamic code is fully shared between threads.”
He continues to say something that certainly has caught my attention: “It is one of these most frustrating aspects of performance tuning: sometimes you *know* the program is smaller and has to perform fewer steps, so it *must* be faster but measuring turns out it is in fact slower.”
Good for thesis: do you think it is useful, how does it fit with real examples, where do you think the API is not elegant/incomplete, what do you (eventually expect), are there relevant de-facto standards that should be considered, etc.
