I should have said "streaming" rather than "serial". True Parallelism is a
long way off in the future , but a form of parallelism can be had using
multiple CPU cores and hard affinity as described in the excellent article.
http://www.ibm.com/developerworks/linux/library/l-affinity/index.html#downl
On 2017-05-05 14:27, Brian wrote:
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.
Isn't the speed of serial (so slow) that it would be overkill to
dedicate a Cpu to it?
The information about using affinity with Linux was only posted so anyone
who was interested could use it , and was not intended as an addition to
Free Pascal.
Regrading the previous comment about the hardware buffering the data , one
still must do something with the data in user space. The choic
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
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 sou
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 th
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 exist
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-preemptiv
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
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 *de
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 proce
Am 14.04.2017 09:23 schrieb "Michael Schnell" :
>
> 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 proc
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
pro
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
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
para
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, a
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
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
> s
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 kn
>> On Mar 31, 2017, at 5:32 PM, Michael Schnell 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
>>
> On Mar 31, 2017, at 5:32 PM, Michael Schnell 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
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
On 30.03.2017 18:29, Jon Foster wrote:
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.
Threading is the way parallelism can be achieved using a "standard"
programming language a
> On Mar 31, 2017, at 3:55 PM, Gary Doades wrote:
>
> However, multiple independent compute units must be required for *true*
> parallelism. On a single processor any tasks running at the same time is just
> an illusion, normally created by the OS in time slicing between tasks based
> on cert
> On Mar 31, 2017, at 4:38 PM, Tony Whyman
> 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,
> i
On 31/03/17 09:55, Gary Doades wrote:
However, multiple independent compute units must be required for*true*
parallelism. On a single processor any tasks running at the same time is just
an illusion, normally created by the OS in time slicing between tasks based on
certain criteria (priority
> I would offer the following definitions:
> - Parallelism is a (design) concept for expressing collateral actions in
> which the processing order of the actions is unspecified. They may take place
> serially or
> contemporaneously in real time, or a mixture of the two.
> - Threads are an impl
The problem I have with this thread (no pun intended) is that it is not
comparing like with like. As demonstrated by many of the replies,
Parallelism and Threads are not the same thing.
I would offer the following definitions:
- Parallelism is a (design) concept for expressing collateral actio
> On Mar 30, 2017, at 3:06 PM, Michael Schnell wrote:
>
>>
>> Huh, ok, but why parallelism is better and how to do it with fpc ?
>>
> Parallelism within a process always is based on threads.
>
> AFAIK, fpc does not (yet) provide a more convenient abstraction for
> parallelism (such as parall
On 29.03.2017 20:57, fredvs wrote:
Huh, ok, but why parallelism is better and how to do it with fpc ?
Parallelism within a process always is based on threads.
AFAIK, fpc does not (yet) provide a more convenient abstraction for
parallelism (such as parallel loops) than TThread.
-Michael
__
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 i
On 30/03/17 08:00, Mark Morgan Lloyd wrote:
Finally, I suggest that you look at least briefly at
https://en.wikipedia.org/wiki/Vector_Pascal which appears to have some
quite good stuff in it.
Quoting from manual section 5.4.
Future machines like the Larrabee will have considerably wider
SIMD
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
> On Mar 30, 2017, at 4:25 AM, fredvs wrote:
>
>>
>> how software parallelism ( in the sense of true simultaneous execution )
>> in a single process without using ( OS dependent ) threads can be achieved
>> ?
>
> Huh, it is exactly was I do not understand...
Look at an OpenCL tutorial for m
Parallelism is what hipster Node programmers do, threads are everything
else.
/jk
--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://refi64.com
On Mar 29, 2017 1:57 PM, "fredvs" wrote:
> Hello.
>
> Some developers treat me as dinosaur because I use
@Karoly Balogh (Charlie/SGR)
Perfect, I have now all the arguments to defend the "Dinosaur Threading"
choice.
Thanks.
Fre;D
-
Many thanks ;-)
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Threading-vs-Parallelism-tp5728018p5728025.html
Sent from the
Hi,
On Wed, 29 Mar 2017, fredvs wrote:
> > besides hardware parallelism,
>
> Is it possible, with fpc, to assign one processor (if multi) for a
> thread and say to the system to use this one only for the thread ? But
> maybe it will gives more problems than solutions.
Yes, it's called thread/pro
> besides hardware parallelism,
Is it possible, with fpc, to assign one processor (if multi) for a thread
and say to the system to use this one only for the thread ?
But maybe it will gives more problems than solutions.
Fre;D
-
Many thanks ;-)
--
View this message in context:
http://free
> I would not pay too much attention to what these developers are saying.
Excellent idea, I will do the same ;-)
> how software parallelism ( in the sense of true simultaneous execution )
> in a single process without using ( OS dependent ) threads can be achieved
> ?
Huh, it is exactly was I
Hi,
On 29/3/2017 11:15 μμ, Michael Van Canneyt wrote:
< snip >
Showing nicely that parallelism in a single process implies threads.
I would not pay too much attention to what these developers are saying.
besides hardware parallelism, how software parallelism ( in the sense of
true simultane
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 arti
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/C
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 ?
Thanks.
Fre;D
-
Many thanks ;-)
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Threading
Bee wrote:
It might be the case, I'm not sure. In my case, sometimes my app (fcgi)
couldn't create a new requested thread, but at other times it created
successfully. It happened randomly which gave me enough headaches to
find what caused the problem. Such case didn't happen on windows.
http:/
In the end (with a few posts to the mailing list), we found out that
if a task (thread) is quick or not very CPU intensive, Linux prefers
to give them longer timeslices instead of constantly switching
threads. That was the only thing I noticed, but other than that, I use
threads (although little a
On Mon, Oct 20, 2008 at 7:22 AM, Bee <[EMAIL PROTECTED]> wrote:
> Are there any specific things that need to be concerned regarding threading
> on posix platform (linux, mac, etc)? Especially their differences with
> windows platform.
Under Linux the thread scheduler works quite different to Windo
Hi all,
Are there any specific things that need to be concerned regarding
threading on posix platform (linux, mac, etc)? Especially their
differences with windows platform.
I'm now experimenting with ExtPascal. It works fine on windows but it
got some problems on posix platforms. Sometimes I
> Hi,
> How good is the threading support in Free Pascal? I'm using 2.1.1. I
> haven't used threading before under FPC and am about to revamp an
> in-house application to support mutliple threads. I don't want to
> start the app and then find out that there is some major stability
> issues with
> How good is the threading support in Free Pascal? I'm using 2.1.1. I
> haven't used threading before under FPC and am about to revamp an
> in-house application to support mutliple threads. I don't want to
> start the app and then find out that there is some major stability
> issues with thread
Hi,
How good is the threading support in Free Pascal? I'm using 2.1.1. I
haven't used threading before under FPC and am about to revamp an
in-house application to support mutliple threads. I don't want to
start the app and then find out that there is some major stability
issues with threading
On 06 Aug 2006, at 11:30, Jason P Sage wrote:
Does anyone have any suggestions on where I should really start
with making
threads etc in a manner that will allow one code base but work on
at least
win32 and Linux?
http://www.freepascal.org/docs-html/rtl/classes/tthread.html
Jonas
__
On 8/6/06, Jason P Sage <[EMAIL PROTECTED]> wrote:
Does anyone have any suggestions on where I should really start with making
threads etc in a manner that will allow one code base but work on at least
win32 and Linux?
There is a tutorial here:
http://wiki.lazarus.freepascal.org/index.php/Mult
Does anyone have any suggestions on where I should really start with making
threads etc in a manner that will allow one code base but work on at least
win32 and Linux?
I'm trying to make an application that is more or less acting like a daemon,
that waits for a message from another process, and ta
@Vincent
thanks for your detailed reply :)
@All
Vinzent Hoefler wrote:
On Wednesday 12 July 2006 11:34, Andreas Berger wrote:
save and restore the floating point unit. I will need to do this for
FPC, so if someone knows how to save and restore the FPU, I would
apreciate the help.
F(
On Wednesday 12 July 2006 11:34, Andreas Berger wrote:
> save and restore the floating point unit. I will need to do this for
> FPC, so if someone knows how to save and restore the FPU, I would
> apreciate the help.
F(X)SAVE/F(X)RSTOR
The X-Versions are more efficient, but only available on newe
On 12 jul 2006, at 13:00, Vinzent Hoefler wrote:
"sched_yield()"? Seems to be POSIX, so I suppose it's available on
most
Unices.
Indeed also exists on Mac OS X.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freep
Since Dos can have multiple ways of multitasking (it could e.g. also plug in
to DV or Win3.x or TopView via int 2FH etc) this model seems advisable to me.
I assume you are implementing a basic fixed timeslicer? What are you going
to use it for btw? This because DV/X (which is free nowadays) a
On Wednesday 12 July 2006 11:10, Marco van de Voort wrote:
> > > > spinning loops on Mac OS X, so maybe sleep(0) is the same.
> > >
> > > Do you know a correct way of doing this on *nix?
> >
> > "sched_yield()"? Seems to be POSIX, so I suppose it's available on
> > most Unices.
>
> Yes, and not so
> > > spinning loops on Mac OS X, so maybe sleep(0) is the same.
> >
> > Do you know a correct way of doing this on *nix?
>
> "sched_yield()"? Seems to be POSIX, so I suppose it's available on most
> Unices.
Yes, and not so recent ('93) that it is risky. At least FreeBSD seems to have
it.
_
On Wednesday 12 July 2006 10:57, Tomas Hajny wrote:
> I certainly don't know a general solution for *nix. However, even old
> "single-task" DOS provides such a function and it's a great help that
> can be provided by programmer to scheduler in the underlying OS, so
> *nix systems should provide su
On Wednesday 12 July 2006 09:58, Marco van de Voort wrote:
> > On 12 jul 2006, at 11:25, Marco van de Voort wrote:
> >
> > sleep(0) is quite bad, because it may not necessarily give up any
> > timeslice. At least very short nanosleeps seem to be implemented as
> > spinning loops on Mac OS X, so may
Marco van de Voort wrote:
>> On 12 jul 2006, at 11:25, Marco van de Voort wrote:
>>
>> > I doubt it. Note that it also probably needs enhancing of the
>> > threadinterface with a giveuptimeslice functionality, something for
>> > which
>> > now sleep(0) is abused.
>>
>> sleep(0) is quite bad, becaus
> On 12 jul 2006, at 11:25, Marco van de Voort wrote:
>
> > I doubt it. Note that it also probably needs enhancing of the
> > threadinterface with a giveuptimeslice functionality, something for
> > which
> > now sleep(0) is abused.
>
> sleep(0) is quite bad, because it may not necessarily give
On Wednesday 12 July 2006 09:15, Tomas Hajny wrote:
> Well, multitasking <> multithreading. I'm not sure if DV or Win 3.x
> provide special multithreading support for DOS applications...
Nope, not really (at least for Win3.x). There are some services to aid
multi-tasking-aware applications at th
Marco van de Voort wrote:
>> Marco van de Voort wrote:
.
.
>> However, it certainly depends on whether a general solution (not
>> requiring special support like DV, etc.) is really feasible and
>> practical.
>
> I doubt it. Note that it also probably needs enhancing of the
> threadinterface with
On 12 jul 2006, at 11:25, Marco van de Voort wrote:
I doubt it. Note that it also probably needs enhancing of the
threadinterface with a giveuptimeslice functionality, something for
which
now sleep(0) is abused.
sleep(0) is quite bad, because it may not necessarily give up any
timeslice.
> Marco van de Voort wrote:
> > me.
> > I assume you are implementing a basic fixed timeslicer? What are you
> > going
> > to use it for btw? This because DV/X (which is free nowadays) afaik gives
> > you preemptive scheduling on Dos.
>
> Well, multitasking <> multithreading. I'm not sure if DV
Marco van de Voort wrote:
>> >> I need to implement some simple threading in a DOS application I am
>> >> writing with FPC. What I need to know is the following:
>> >>
>> >> 1) Does FPC protect it's stack or can I allocate memory from the heap
>> >> and point SS and ESP to it for the threads stack.
> >> I need to implement some simple threading in a DOS application I am
> >> writing with FPC. What I need to know is the following:
> >>
> >> 1) Does FPC protect it's stack or can I allocate memory from the heap
> >> and point SS and ESP to it for the threads stack.
> >>
> >
> > I believe
I need to implement some simple threading in a DOS application I am
writing with FPC. What I need to know is the following:
1) Does FPC protect it's stack or can I allocate memory from the heap
and point SS and ESP to it for the threads stack.
I believe the latter is correct (except th
On 11 Jul 06, at 15:14, Andreas Berger wrote:
> I need to implement some simple threading in a DOS application I am
> writing with FPC. What I need to know is the following:
>
> 1) Does FPC protect it's stack or can I allocate memory from the heap
> and point SS and ESP to it for the threads st
I need to implement some simple threading in a DOS application I am
writing with FPC. What I need to know is the following:
1) Does FPC protect it's stack or can I allocate memory from the heap
and point SS and ESP to it for the threads stack.
2) If the stack is protected, how do I allocate s
On 26 nov 2004, at 21:02, Paul Davidson wrote:
fpc 1.9.5 [2004/11/26] Darwin 10.3
And for the record: it's the same under Linux/x86, it's not Darwin or
Mac OS X specific. But I have no idea whether the behaviour is correct
or not.
Jonas
___
fpc-pascal
It works under Delphi/Windows. If that has any weight?
On Nov 26, 2004, at 15:13, Jonas Maebe wrote:
On 26 nov 2004, at 21:02, Paul Davidson wrote:
fpc 1.9.5 [2004/11/26] Darwin 10.3
And for the record: it's the same under Linux/x86, it's not Darwin or
Mac OS X specific. But I have no idea wheth
74 matches
Mail list logo
