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
> 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
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
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
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
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
_language_ext
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
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
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 multi
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
Hello everyone,
Before asking too many questions already answered, is there any
comprehensive up to date documentation of asm usage for the Win64 target?
(Yes, I have googled the archive of this list, but since the compiler is
still under active development, I didn't think it might be a good
On 17 Dec 2007, at 15:32, Henrick Hellström wrote:
1. Since there is no CPU debug window in Lazarus Win64, I tried the
-A option, but it doesn't seem to work with the compiler bundled
with Lazarus Win64. I tried -aASW, -AASW and a couple of other
combinations. Am I missing something obviou
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
Jonas Maebe wrote:
On 17 Dec 2007, at 15:32, Henrick Hellström wrote:
1. Since there is no CPU debug window in Lazarus Win64, I tried the
-A option, but it doesn't seem to work with the compiler bundled with
Lazarus Win64. I tried -aASW, -AASW and a couple of other
combinations. Am I missing
Henrick Hellström schrieb:
> Jonas Maebe wrote:
>>
>> On 17 Dec 2007, at 15:32, Henrick Hellström wrote:
>>
>>> 1. Since there is no CPU debug window in Lazarus Win64, I tried the
>>> -A option, but it doesn't seem to work with the compiler bundled with
>>> Lazarus Win64. I tried -aASW, -AASW and a
Henrick Hellström schrieb:
>
> 2. I couldn't find information about the calling convention under Win64
> on the documentation page. Does FPC support the unified MSVC++ calling
> convention for Win64 that is very similar to Register+stack frames?
Yes.
> Does
> it, like MSVC++, *only* support tha
Henrick Hellström schreef:
Jonas Maebe wrote:
On 17 Dec 2007, at 15:32, Henrick Hellström wrote:
1. Since there is no CPU debug window in Lazarus Win64, I tried the
-A option, but it doesn't seem to work with the compiler bundled with
Lazarus Win64. I tried -aASW, -AASW and a couple of other
but how do I produce *.s
files for the other units in the project?
I added "-l" in the "project -> compiler settings -> other -> user
defined settings" memo (I run the German language version of Lazarus here).
Now any compiled unit created a .S file.
-Michael
20 matches
Mail list logo
