Threading vs Parallelism ?

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Ryan Joseph

> On Mar 31, 2017, at 4:38 PM, Tony Whyman <[hidden email]> wrote:
>
> For example, this distinction is very important in matrix algorithms. When operating on two matrices to produce another, the operations on each cell can be identified as n x m parallel actions at design time. At deployment time, it is often desirable to have a scalable implementation that can use anything from 1 to n x m processors to do the job. Thus you can have a design that identifies parallelism leading to an implementation that can non-parallel, partly or wholly parallel (in real time) depending on the size of the matrices and the number of processors available.

That’s a good candidate for parallelism but you need an API like OpenCL to implement it properly so you can access the actual hardware required. From the little time I spent with OpenCL you really don’t want to (or shouldn’t) be intentionally designing your programs like this unless you have a real need for “true” parallelism with multiple compute units.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Michael Schnell
In reply to this post by Tony Whyman
On 31.03.2017 10:18, Tony Whyman wrote:
> Neither of the above implies multiple CPUs or processing units.
Regarding the view of the application (disregarding execution speed) or
of the application programmer, there is no difference between real
("Hardware")  and virtual (e.g. threads) parallelism. These dirty basics
need to be handled by the software and hardware infrastructure.

The use of real (e.g. multi CPU) parallelism that the application allows
for being divided into multiple parallel "Threads". his fact given
Hardware parallelism can speed up the execution, while even virtual
parallelism allows for improving the latency of definable parts the
application.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Ryan Joseph

> On Mar 31, 2017, at 5:32 PM, Michael Schnell <[hidden email]> wrote:
>
> Regarding the view of the application (disregarding execution speed) or of the application programmer, there is no difference between real ("Hardware")  and virtual (e.g. threads) parallelism. These dirty basics need to be handled by the software and hardware infrastructure.
>
> The use of real (e.g. multi CPU) parallelism that the application allows for being divided into multiple parallel "Threads". his fact given Hardware parallelism can speed up the execution, while even virtual parallelism allows for improving the latency of definable parts the application.

I’m not understanding how parallelism could apply to anything besides breaking down a task so that it can run on multiple hardware compute units.

Why would you ever break a task into 100 threads when you could just run it one thread?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Gary Doades

>> On Mar 31, 2017, at 5:32 PM, Michael Schnell <[hidden email]> wrote:
>>
>> Regarding the view of the application (disregarding execution speed) or of the application programmer, there is no difference between real ("Hardware")  and virtual (e.g. threads) parallelism. These dirty basics need to be handled by the software and hardware infrastructure.
>>
>> The use of real (e.g. multi CPU) parallelism that the application allows for being divided into multiple parallel "Threads". his fact given Hardware parallelism can speed up the execution, while even virtual parallelism allows for improving the latency of definable parts the application.

> I’m not understanding how parallelism could apply to anything besides breaking down a task so that it can run on multiple hardware compute units.

> Why would you ever break a task into 100 threads when you could just run it one thread?

"Events".

One gets into the grey area of threads and "processors". As an example you could divide a program into two threads, one reading and one writing. Immediately after issuing a write request, you could start reading the next item in a separate thread before the write is complete. This works because the I/O subsystem is mostly independent so that the OS can schedule another thread (or process) which is not waiting for the I/O subsystem to reply. Using only a single thread, the whole program has to wait for the I/O write to finish before starting the next read.

In this way a single process on a single "processor" (at least CPU) can interleave tasks to speed up the overall performance of the application. This could be extended to a myriad of cases of course.

Hence the recent upsurge in "async" routines, which only works if used properly of course.

Cheers,
Gary.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

noreply
In reply to this post by fredvs
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...

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 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

Likely in order to understand any of these creative ideas, which could be
bad ideas, one will need some THC or good weed
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

noreply
In reply to this post by Mark Morgan Lloyd-5
On Thu, March 30, 2017 1:56 am, Mark Morgan Lloyd wrote:

> On 29/03/17 22:30, fredvs wrote:
>
>> @Karoly Balogh (Charlie/SGR)
>> Perfect, I have now all the arguments to defend the "Dinosaur
>> Threading"choice.
>> Thanks.
>>
>
> I'd second Charlie's point, and add that a very small change to a
> system's layout, e.g. a DIMM on a NUMA node going dodgy and being excluded
> at boot, can have a drastic effect if process or interrupt affinity has
> been locked down inadvisedly.
>
> Another thing to take into account is that when many people mention
> parallelisation they're thinking of something like OpenMP, which in
> practice is built on top of threads and processes and obviously introduces
> substantial overhead. It's good for large jobs carefully designed,
> particularly on very large datasets.
>
> Some languages were designed with at least some measure of
> parallelisation in mind. I'd highlight in particular APL,

What about Erlang..  Errrrrr
But I have not so much interest in dynamic typed languages so have done
little research on it.
Been meaning to experiment with APL or learn more about it too.

Those languages that have special symbols or require a special keyboard I
am sure turn lots of people off.

This email could go into fpc other i suppose
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

noreply
In reply to this post by Michael Schnell
On Fri, March 31, 2017 4:32 am, Michael Schnell wrote:

> On 31.03.2017 10:18, Tony Whyman wrote:
>
>> Neither of the above implies multiple CPUs or processing units.
>>
> Regarding the view of the application (disregarding execution speed) or
> of the application programmer, there is no difference between real
> ("Hardware")  and virtual (e.g. threads) parallelism. These dirty basics
> need to be handled by the software and hardware infrastructure.
>
> The use of real (e.g. multi CPU) parallelism that the application allows
> for being divided into multiple parallel "Threads".


 Or processes? If unix could just make processes even lighter weight or
faster loading, I might avoid threads and just use processes... Or use
some abstract tool that does not require I even know what is being used
under the hood...
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Giuliano Colla
In reply to this post by fredvs
Il 30/03/2017 00:26, fredvs ha scritto:
> Perfect, I have now all the arguments to defend the "Dinosaur Threading"
> choice.

When I'm charged of not using the most cool and new technology, my
favourite argument are the tombstones. They're made out of stone, which
is a stone-age technology. But, as nothing more suitable has been found
for that purpose, the stone-age technology survives. Up to now it turns
out to be the most appropriate technology for that application.

The best course is always to pick up the most *appropriate* technology,
as opposed to the one most *modern* or *fashionable*. There are
applications where parallel computing is the best solution, and
applications where parallel computing is useless.

My main line is on industrial process control. You must react in
real-time to "events". A multi-threading approach, with threads
activated by events, gives a performance which you can't achieve with
any other technique. But if you attempt to apply our event-driven
approach to optimize a matrix calculation you'll miserably fail.

Just my 2c

Giuliano


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

noreply
In reply to this post by Jon Foster
On 2017-03-30 11:29, Jon Foster wrote:

> On 03/29/2017 01:15 PM, Michael Van Canneyt wrote:
>>
>>
>> On Wed, 29 Mar 2017, Dimitrios Chr. Ioannidis via fpc-pascal wrote:
>>
>>> Hi,
>>>
>>> On 29/3/2017 9:57 μμ, fredvs wrote:
>>>> Hello.
>>>>
>>>> Some developers treat me as dinosaur because I use threads in place
>>>> of
>>> doing
>>>> parallelism.
>>>>
>>>> Huh, ok, but why parallelism is better and how to do it with fpc ?
>>>
>>>   a nice article I've found long ago when I was researching the same
>>> topic "Threading/Concurrency vs. Parallelism" is the following :
>>>
>>> http://tutorials.jenkov.com/java-concurrency/concurrency-vs-parallelism.html 
>>>  and I tried the multithreadprocslaz package in Lazarus :
>>>
>>> http://wiki.freepascal.org/Parallel_procedures
>>
>> Showing nicely that parallelism in a single process implies threads.
>> I would not pay too much attention to what these developers are
>> saying.
>>
>>
> Either I'm dense, which is entirely possible, or the author of that
> article didn't do a good job of making his point, even assuming he had
> one.
>
> Thinking about this a bit more I would say that "threads" are a means
> (vehicle) to achieve parallelism. I think that in the majority of
> programming contexts they are synonymous. But I can think of other
> contexts where they may not be: Say animating a film. You have 1000
> computers generating frames to be assembled into a final sequence. The
> process of dispatching each frame render is most likely not going to
> be done with the OSes thread call, but through a networked work queue
> of some sort (ala Torque or something). So you have the "task"
> (rendering the movie) being worked on in "parallel" via a networked
> job dispatch mechanism.
>

Or modify the film format...

Example: create a 10 hour video that is composed of 100 files.

You have 100 computers, or 100 threads, or, 100 processes..Each computer
creates 1 file.
The video is composed of 100 files but is really just a single video.

You open up VLC to play the video, and it opens 100 files, but the end
user just opens a single file that links to each of these 100 files.

This could be the stupidest ridiculous parallel video creation technique
ever. I'm not sure...
Or it could be an idea...



> Or the case of using "make -j ..." which "forks" multiple jobs
> (compile, link, ...) in parallel based on a dependency tree.
>
> I say threading is parallelism, even if just one form of it. The other
> methods of parallelism I mentioned here could also be done in FPC with
> the appropriate code.

What about the difference between parallelism vs concurrency?

Rob Pike has some videos on it and meetup events discussing it on
youtube.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

el_es
In reply to this post by noreply
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.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Michael Schnell
In reply to this post by noreply
On 12.04.2017 14:09, Lars wrote:
> If unix could just make processes even lighter weight or
> faster loading, I might avoid threads and just use processes...
in Unix/Linux processes are not less "light" then threads. You can
create a process by "fork". no "Loading" involved. it just creates the
process. If you want to have the new process execute any code that is
not shared with the you need to do another system call to replace the
code with the new one. Moreover even if "loading" new code - in case
another process already runs this file, no actual loading  takes place,
either, as the memory management just uses the code page already in RAM.

This definitively is as light as it gets.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Free Pascal - General mailing list

Am 14.04.2017 09:23 schrieb "Michael Schnell" <[hidden email]>:
>
> On 12.04.2017 14:09, Lars wrote:
>>
>> If unix could just make processes even lighter weight or
>> faster loading, I might avoid threads and just use processes...
>
> in Unix/Linux processes are not less "light" then threads. You can create a process by "fork". no "Loading" involved. it just creates the process. If you want to have the new process execute any code that is not shared with the you need to do another system call to replace the code with the new one. Moreover even if "loading" new code - in case another process already runs this file, no actual loading  takes place, either, as the memory management just uses the code page already in RAM.
>
> This definitively is as light as it gets.

A process definitely is less "light" than threads even on Unix systems: a process has its own address space (even if it shares all pages with its parent process) and also structures keeping track of the used resources (e.g. open file descriptors). A thread does not need all this as it always shares the same address space and the same resources.
Why do you think the concept of threads was introduced in Unix? Early Unix systems only had processes.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Michael Schnell
On 14.04.2017 09:36, Sven Barth via fpc-pascal wrote:
>
>
> A process definitely is less "light" than threads even on Unix
> systems: a process has its own address space
>
Not really true (see below).
>
> Why do you think the concept of threads was introduced in Unix? Early
> Unix systems only had processes.
>
Because if you do something that is usually called "Thread" you _want_
shared memory in the same address space, not because of that being
"light" but because the way you want to handle your memory based objects
in your user code needs this.

In fact the "real" difference between Threads and processes (i.e. the
Kernel knows that a processing entity is supposed to be a "Thread"
associated with other threads of a process) in Linux only had been
introduced with the "Native POSIX Thread Library" ("NPTL") ->
https://en.wikipedia.org/wiki/Native_POSIX_Thread_Library. Before NPTL,
you just used processes for your threads telling the system that for the
new thread you wanted a shared address space.

Again (AFAIK) NPTL had not been introduce to make threads "lighter" but
to allow for threads behaving in a decently POSIX compatible way (e.g.
the threads of a process getting only a common share of time slices).

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Mark Morgan Lloyd-5
On 20/04/17 07:00, Michael Schnell wrote:

> Again (AFAIK) NPTL had not been introduce to make threads "lighter" but
> to allow for threads behaving in a decently POSIX compatible way (e.g.
> the threads of a process getting only a common share of time slices).

In any event, processes on unix are *defined* as owning resources-
memory, handles and so on- while threads only manage control flow. I
believe that MS also have "fibers" which are non-preemptive threads.

If somebody wants to define a new kind of thread, something even
lighter-weight, they're going to need a new name: inverting
well-accepted precedence is not an option.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Marco van de Voort
In our previous episode, Mark Morgan Lloyd said:
>
> In any event, processes on unix are *defined* as owning resources-
> memory, handles and so on- while threads only manage control flow. I
> believe that MS also have "fibers" which are non-preemptive threads.

They are not really threads. They must be scheduled within threads.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx

from the article they don't seem to have that many advantages, except to
convert existing manual m:n scheduling apps.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Mark Morgan Lloyd-5
On 20/04/17 09:00, Marco van de Voort wrote:
> In our previous episode, Mark Morgan Lloyd said:> > In any event, processes on unix are *defined* as owning resources- > memory, handles and so on- while threads only manage control flow. I > believe that MS also have "fibers" which are non-preemptive threads.
> They are not really threads. They must be scheduled within threads.
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx
> from the article they don't seem to have that many advantages, except toconvert existing manual m:n scheduling apps.

Which effectively makes them coroutines, but since they're MS-only
they're nonportable. Which is more or less where Ryan started off the
other thread.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Marco van de Voort
In our previous episode, Mark Morgan Lloyd said:
> > They are not really threads. They must be scheduled within threads.
> > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx
> > from the article they don't seem to have that many advantages, except toconvert existing manual m:n scheduling apps.
>
> Which effectively makes them coroutines, but since they're MS-only
> they're nonportable.

What exactly makes them coroutines? Maybe that they  implement a local stack
concept.  But you still would have to integrate that with FPC (exception
handling, stack checking), so at the basic level it only saves some asm
switching contexts.

But maybe the OS support for stack switching makes things like keeping SEH
working easier. (not that that is enabled by default for 32-bit windows x86)

> Which is more or less where Ryan started off the
> other thread.

It suddenly occured to me that that piece of code is compatible to nothing
in FPC, since the only likely target in FPC (win32 x86) doesn't use SEH.
There is a define to enable it though ( -dTEST_WIN32_SEH )
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Mark Morgan Lloyd-5
On 20/04/17 10:22, Marco van de Voort wrote:
> In our previous episode, Mark Morgan Lloyd said:> > They are not really threads. They must be scheduled within threads.> > https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661(v=vs.85).aspx> > from the article they don't seem to have that many advantages, except toconvert existing manual m:n scheduling apps.> > Which effectively makes them coroutines, but since they're MS-only > they're nonportable.
> What exactly makes them coroutines? Maybe that they  implement a local stackconcept.

Yes, exactly. Which I think is an abstraction that FPC doesn't have.
Even Turbo Pascal interrupt handlers worked within the same stack, as
distinct from TopSpeed's IOTRANSFER() which switched.

> But you still would have to integrate that with FPC (exceptionhandling, stack checking), so at the basic level it only saves some asmswitching contexts.

It's interesting that coroutines (Modula-2, perhaps others) precede
exceptions etc. (C++?). It might turn out that in practice they /have/
to be implemented first, otherwise the amount of doctrine that grows up
around exceptions makes the job implausible.

> But maybe the OS support for stack switching makes things like keeping SEHworking easier. (not that that is enabled by default for 32-bit windows x86)
>> Which is more or less where Ryan started off the > other thread.
> It suddenly occured to me that that piece of code is compatible to nothingin FPC, since the only likely target in FPC (win32 x86) doesn't use SEH.There is a define to enable it though ( -dTEST_WIN32_SEH )

I think I said at the time that he should be looking at (an equivalent
of) fibers.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Brian
In reply to this post by fredvs
Affinity

If a thread is dedicated to say , polling a serial or Ethernet port which has a high input data rate , then dedicating one CPU to that task/thread is useful.

 (Hard Affinity) with multi-core CPU's is to dedicate a specific core to a task (thread) and just poll the input memory mapped source. This works very well.

http://www.ibm.com/developerworks/linux/library/l-affinity/index.html#download

These Linux API functions set the affinity for processes :

    sched_set_affinity() (for altering the bitmask)
    sched_get_affinity() (for viewing the current bitmask)

These functions set the affinity for threads :

     pthread_setaffinity_np (pthread_t thread, size_t cpusetsize,  const cpu_set_t *cpuset);
     pthread_getaffinity_np (pthread_t thread, size_t cpusetsize,  cpu_set_t *cpuset);

They are very simple to translate into Free Pascal

Brian
Reply | Threaded
Open this post in threaded view
|

Re: Threading vs Parallelism ?

Marco van de Voort
In our previous episode, Brian said:
> Affinity
>
> If a thread is dedicated to say , polling a serial or Ethernet port which
> has a high input data rate , then dedicating one CPU to that task/thread is
> useful.

Well, the driver actually does the hardware, so it is already buffered for
userland ?

> They are very simple to translate into Free Pascal

Please provide patches in the bugtracker then. Linux calls go into the
"linux" unit, pthreads into the pthreads unit, which is general *nix, but
with an include per OS
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123