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
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 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
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
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
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 that
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
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
19 matches
Mail list logo
