[fpc-pascal] Threading vs Parallelism ?

[Lukasz Sokol]

On 12/04/17 12:54, Lars wrote:
> On Wed, March 29, 2017 4:26 pm, fredvs wrote:
>> @Karoly Balogh (Charlie/SGR)
>>
>>
>> Perfect, I have now all the arguments to defend the "Dinosaur Threading"
>> choice.
>>
>> Thanks.
>>
>>
>> Fre;D
>>
> 
> Methinks that programs should be designed or programmed in such an
> abstract way that you do not care or know whether multiple processes are
> being used, IPV mechanisms, or threads... I.e. you write your program in
> such a way that it could take advantage of multi cpus or gpus or whatever,
> using anything from threads to actual proceses, and your program is so
> high level that you dont care ... Then if you have a performance issue
> because the underlying low level details didnt work, there may be some
> setting to tweak as a last resort. Kind of like how theoretically you
> could use sqldb at a high level without knowing which database
> implementation you are using underneath
> 
> I think Erlang, and errrrr, golang are trying to look at the problem this
> way too. You may also check Rob Pike youtube talk about concurrency. This
> is an open area of computing science still being worked on. Also, how
> would quantum computers deal with threading and would you even need
> threads, or would a single quantum cpu be so powerful that there would be
> little need to thread things off separately...
> 

I think it depends on what you're trying to program:
some applications (like HPC/scientific, networking, rendering) need time to
complete their calculations (even if it 'only' needs uploading data to 
hw accelerator as in rendering recently) and if you need also interactivity
on them, you have no choice but do some kind of multitasking.
And then there is the problem of (certain) GUI functions not being thread-safe,
or, only working properly if called from the same context. Not limited to GUI too,
some 3rd party libraries come with this kind of warnings too.

> It would be interesting to see if TProcess could be used in fpc, or
> assignstream, to mimmick thread programming but instead of threads a
> process is used , and you still can program in a thread like way or some
> high level way. SimpleIPC comes close but it's more like sending a
> message, not calling a procedure as normal. Each pascal procedure or C
> function is like a mini program itself, so why couldn't each procedure be
> a separate EXE program if you wanted it to be...
> 
In principle it would probably let you do as you want. Only a lot of
'grassroots' required for a 'single procedure program' to be multitasked
that way and communicate through IPC. Signal to noise 
(amount of user code to amount of plumbing code) ratio 
here would be really awful... even if the IPC was really basic
and self contained in a unit, or library (maybe only better if
communication happens over shared-library* or the ubiquitous netlink of sorts)

* of course, if through 'shared library' you have also to ensure all the elements use
the same library ALWAYS.

> In OOP its harder to think this way as an object is many procedures
> attached to a struct/record
> 
> Another idea is that each unit file could be a separate exe or thread , or
> each class/object could be a separate exe and you design the program so
> that each object does its own work in a separate exe then communicates
> with some other main exe
> 
The clue is in 'commumnicates' really here: what you need communicated and
what communication framework you want to use for that. 

> Likely in order to understand any of these creative ideas, which could be
> bad ideas, one will need some THC or good weed

Nah, but I need to go replenish my caffeine about now ;)

-L.