I think that modifying the language to incorporate MPI would be
extremely difficult and would be so near the bleeding edge of computer
science
I assume that language support for any kind of parallel processing is
hard to do That is why some days ago I said that I don't think that
anybody will
Michael Schnell wrote:
For clusters there is already a de facto standard: MPI. It works with
FPC.
AFAIK OpenMP and MPI work well together and are separate.
Right now my concerns are not about how and what features should be
implemented (in the libraries), but only about how they are presen
Michael Schnell wrote:
David Butler wrote:
A big difference between threads and fibers in Windows is that threads
are preemtively scheduled, while fibers are co-operatively scheduled.
That sounds very logical.
I gather cooperative scheduling is not possible when distributing the
work on multi
But light weight threads only work fast, when each thread has equally
fast access to all resources. This is not the case for distributed
memory.
Right you are. The language and the library interface should of course
support this as an option.
-Michael
__
On Mon, 17 Dec 2007 11:58:15 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
>
> > For clusters there is already a de facto standard: MPI. It works
> > with FPC.
> >
> >
> > AFAIK OpenMP and MPI work well together and are separate.
> >
> Right now my concerns are not about how and what fea
David Butler wrote:
A big difference between threads and fibers in Windows is that threads
are preemtively scheduled, while fibers are co-operatively scheduled.
That sounds very logical.
I gather cooperative scheduling is not possible when distributing the
work on multiple processors. So using
For clusters there is already a de facto standard: MPI. It works with
FPC.
AFAIK OpenMP and MPI work well together and are separate.
Right now my concerns are not about how and what features should be
implemented (in the libraries), but only about how they are presented by
_language_ext
A big difference between threads and fibers in Windows is that threads are
preemtively scheduled, while fibers are co-operatively scheduled.
Unfortunately, Windows' fiber implementation has severe limitations.
To get around this I created a library that does real light-weight "fibers".
See here
On Mon, 17 Dec 2007 09:41:43 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
> IMHO the language itself might be enhanced for parallel processing.
>
> The implementation should be done in the RTL (or supposedly rather a
> special library). Here the methods of distributing potentially
> parallel
IMHO the language itself might be enhanced for parallel processing.
The implementation should be done in the RTL (or supposedly rather a
special library). Here the methods of distributing potentially parallel
tasks on "executors" is defined. It should work according to a set of
parameters (e.g
Yes, for HPC you need a lot of tuning parameters.
Supposedly the most important tuning parameter of course is the count of
usable CPUs, the next important being the predicted percentage of the
effort to start a thread regarding the runtime the thread needs to
complete. For "lightweight thr
> Regarding the heavy load you are planning here:
>
> When thinking about "lightweight threads" to make use of multiple
> _CPUs_, wouldn't it be viable to consider splitting the tasks across
> multiple _PCs_ as well ?
Well, there is the problem of data. I'm not a cluster expert, but I do know
t
Regarding the heavy load you are planning here:
When thinking about "lightweight threads" to make use of multiple
_CPUs_, wouldn't it be viable to consider splitting the tasks across
multiple _PCs_ as well ?
Thus: If planning an implementation of parallelism in the language
itself (with supp
Hello all,
> Has someone already created a unit for light weight threads?
>
> Something like: Create a group of 4 threads named 0,1,2,3 and execute a
> procedure/method?
Indy for Lazarus [1] has a fibers implementation.
--
Best Regards,
Steve Howe
[1] http://www.indyproject.org/Sockets/fpc/index
> What do you mean by "light weight threads" ? How can it get "lighter"
than TThread,
>that offers close to no built-in "comfort"-functionality ?
TThread (and BeginThread) are quite heavy for small tasks, not because
of the Pascal code, but because of the OS overhead involved in creating,
star
On Fri, 14 Dec 2007 17:11:15 +
Mark Morgan Lloyd <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
>
> > When starting a procedure 100 times, the pool will "add" 100 tasks
> > and wake up the sleeping threads. The threads will then process the
> > tasks. There is no guarantee that a task w
Mattias Gaertner wrote:
When starting a procedure 100 times, the pool will "add" 100 tasks and
wake up the sleeping threads. The threads will then process the tasks.
There is no guarantee that a task will run in a specific thread. If a
task fetches a small task, it will start earlier with the ne
>
> > > You still can implement such thread pools on top of OpenMP(I) (or
> > > similar APIs), if you need to get much lighter. ;)
> >
> > Afaik there are threadpool classes in Indy, and they work.
>
> Thanks. I will take a look.
Please keep me informed, I'll have to do something like this so
On Fri, 14 Dec 2007 15:13:57 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner schrieb:
> > See the OpenMP specs for more possible tuning parameters.
> > The pool can be extended by some of these abilities later, but for
> > now I only need a simple pool to demonstrate/test FPC
On Fri, 14 Dec 2007 12:40:41 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > You still can implement such thread pools on top of OpenMP(I) (or
> > similar APIs), if you need to get much lighter. ;)
>
> Afaik there are threadpool classes in Indy, and they work.
Thanks. I will take
On Fri, 14 Dec 2007 11:44:43 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Has someone already created a unit for light weight threads?
>
> Is there really an issue about tthread overhead, or are you searching
> for really lighter threads ? Fibers/clone/rfork etc.
Basically I'm s
Mattias Gaertner schrieb:
> See the OpenMP specs for more possible tuning parameters.
> The pool can be extended by some of these abilities later, but for now
> I only need a simple pool to demonstrate/test FPC with parallel
> algorithms.
Such a thread pool can get rather tricky: first, you need s
On Fri, 14 Dec 2007 12:36:51 +
Mark Morgan Lloyd <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
> > On Fri, 14 Dec 2007 10:29:59 +0100
> > Michael Schnell <[EMAIL PROTECTED]> wrote:
> >
> >> Mattias Gaertner wrote:
> >>> Has someone already created a unit for light weight threads?
> >>>
Mattias Gaertner wrote:
On Fri, 14 Dec 2007 10:29:59 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
What do you mean by "light weight threads" ? How can it get "lighter"
than TThread, that offers close t
> You still can implement such thread pools on top of OpenMP(I) (or
> similar APIs), if you need to get much lighter. ;)
Afaik there are threadpool classes in Indy, and they work. Also there is a
start of fiber support, but it was not finished.
___
fpc-
Windows has built-in support for user-space scheduled threads. They're
called fibers (multiple fibers are bound to one thread; the OS
schedules threads and you pick which fiber runs).
Ahh. I did not know this.
So adding a UseFibers" property for the windows implementation of
TThread might
On Friday 14 December 2007 11:46, Mattias Gaertner wrote:
> For many parallel algorithms you don't
> need events, priority or synchronize. But you need to easily and fast
> start a set of threads with IDs 0..N.
Ok, so you're mostly caring about the thread creation overhead, it
seems.
So yes, h
On 14 Dec 2007, at 11:44, Michael Schnell wrote:
No, TThread is either heavy or middle-weight, according to the
definitions at
http://whatis.techtarget.com/definition/0,,sid9_gci814910,00.html
Of course it would be possible to include a multitasking scheduler
in the RTL to avoid any syste
Mattias Gaertner schrieb:
> On Fri, 14 Dec 2007 10:29:59 +0100
> Michael Schnell <[EMAIL PROTECTED]> wrote:
>
>> Mattias Gaertner wrote:
>>> Has someone already created a unit for light weight threads?
>>>
>> What do you mean by "light weight threads" ? How can it get "lighter"
>> than TThread
On Fri, 14 Dec 2007 10:29:59 +0100
Michael Schnell <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
> > Has someone already created a unit for light weight threads?
> >
> What do you mean by "light weight threads" ? How can it get "lighter"
> than TThread, that offers close to no built-in
No, TThread is either heavy or middle-weight, according to the
definitions at
http://whatis.techtarget.com/definition/0,,sid9_gci814910,00.html
Of course it would be possible to include a multitasking scheduler in
the RTL to avoid any system calls and share any resources. (AFAIK, for
Linu
> Has someone already created a unit for light weight threads?
Is there really an issue about tthread overhead, or are you searching for
really lighter threads ? Fibers/clone/rfork etc.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://l
On Friday 14 December 2007 10:20, Florian Klaempfl wrote:
> I think some thread pool class is more important, it would be
> basically the same as above
>
> for i := 0 to 3 do
> Handle[i] := TTask(ThreadPool.QueueTask(Func {tThreadFunc},
> @FuncArg[i]));
>
Mattias Gaertner wrote:
Has someone already created a unit for light weight threads?
What do you mean by "light weight threads" ? How can it get "lighter"
than TThread, that offers close to no built-in "comfort"-functionality ?
-Michael
___
fpc-
Vinzent Hoefler schrieb:
> On Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
>> Has someone already created a unit for light weight threads?
>>
>> Something like: Create a group of 4 threads named 0,1,2,3 and execute
>> a procedure/method?
>
> for i := 0 to 3 do
>Handle[i] := tThread
On Friday 14 December 2007 09:37, Felipe Monteiro de Carvalho wrote:
> On Dec 13, 2007 7:55 PM, Mattias Gaertner <[EMAIL PROTECTED]>
wrote:
> > Has someone already created a unit for light weight threads?
>
> I don't know much on the subject, but Is TThread heavy? What are the
> disadvantages of u
On Dec 13, 2007 7:55 PM, Mattias Gaertner <[EMAIL PROTECTED]> wrote:
> Has someone already created a unit for light weight threads?
I don't know much on the subject, but Is TThread heavy? What are the
disadvantages of using it?
thanks,
--
Felipe Monteiro de Carvalho
_
On Thursday 13 December 2007 19:55, Mattias Gaertner wrote:
> Has someone already created a unit for light weight threads?
>
> Something like: Create a group of 4 threads named 0,1,2,3 and execute
> a procedure/method?
for i := 0 to 3 do
Handle[i] := tThreadId(BeginThread (Func {tThreadFunc},
Has someone already created a unit for light weight threads?
Something like: Create a group of 4 threads named 0,1,2,3 and execute a
procedure/method?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailma
39 matches
Mail list logo
