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
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
that
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
, that it can be extended to more sophisticated parameters
and finally to cluster controlling, just by enhancing the library code.
IMHO, all this should not impose any problems for the implementation
with light weight threads.
-Michael
___
fpc-devel
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 tasks
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
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
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
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 features should be
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
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
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
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
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]
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},
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 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 using
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] :=
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-devel
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]));
for i
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, that offers close
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
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
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
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,
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
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 a
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 with
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 to no
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?
What do you
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 some
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
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.
___
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 soon too.
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
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 will run in
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,
starting
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
38 matches
Mail list logo
