Re: [fpc-devel] Light weight threads for FPC
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 support of the RTL), IMHO this should be done in a way that the user optionally can feed PC arrays with the same syntax. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 getting the right data to the right calculation is then a severe bottleneck. In the first Linux clusters of yore, the switching equipment was the only part that wasn't the cheapeast that Dell had to offer :_) Thus: If planning an implementation of parallelism in the language itself (with support of the RTL), IMHO this should be done in a way that the user optionally can feed PC arrays with the same syntax. That would need also management of data, not just code execution points, so IMHO that is out of the question. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 threads (requesting for a thread pool at least in Windows) this percentage might be rather low, for normal Threads somewhat larger. IMHO we should consider PC arrays as well. Here this percentage of course is a lot larger (transferring parameters and results through a Network), but here we might have a huge number of processors. My goal is more humble: To use recent multi cores more easily. Too humble, IMHO, changes to the language should be very well considered. :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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. Count of available processors, a parameter list for the processors (e.g. speed), a penalty estimation for starting an executor (small for lightweight threads, high for cluster machines), ...) Moreover the library of course holds the code to create thread pools, assign tasks to threads, transport parameters to the thread, retrieve results from an executor, etc. A first implementation of course should just provide (light weight) threads (supposedly with a thread pool at least in Windows). Maybe the only primary tuning parameter being the count of CPUs. But it should be done in a way, 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 maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 on executors is defined. It should work according to a set of parameters (e.g. Count of available processors, a parameter list for the processors (e.g. speed), a penalty estimation for starting an executor (small for lightweight threads, high for cluster machines), ...) Moreover the library of course holds the code to create thread pools, assign tasks to threads, transport parameters to the thread, retrieve results from an executor, etc. A first implementation of course should just provide (light weight) threads (supposedly with a thread pool at least in Windows). Maybe the only primary tuning parameter being the count of CPUs. But it should be done in a way, that it can be extended to more sophisticated parameters and finally to cluster controlling, just by enhancing the library code. For clusters there is already a de facto standard: MPI. It works with FPC. IMHO, all this should not impose any problems for the implementation with light weight threads. AFAIK OpenMP and MPI work well together and are separate. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 some documentation I wrote on the subject: http://www.eternallines.com/microthreads/doc.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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_extensions. (And about the interface the libraries offer to the user) Here an as broad as possible range of ways to do parallel processing should be allowed - hiding the details (i.e. if using MPI or OpenMP or something else) should be hidden in the implementation in the library in a way as transparent as possible to the user. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 fibers are no option for the kind of light weight threads requested by the OP. Unfortunately, Windows' fiber implementation has severe limitations. No wonder :) To get around this I created a library that does real light-weight fibers. I suppose as they run in a single system thread they are no option for the kind of light weight threads requested by the OP. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 implemented (in the libraries), but only about how they are presented by _language_extensions. (And about the interface the libraries offer to the user) Here an as broad as possible range of ways to do parallel processing should be allowed - hiding the details (i.e. if using MPI or OpenMP or something else) should be hidden in the implementation in the library in a way as transparent as possible to the user. I agree, that the library should be implemented open minded. 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. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 multiple processors. So using fibers are no option for the kind of light weight threads requested by the OP. Unfortunately, Windows' fiber implementation has severe limitations. No wonder :) To get around this I created a library that does real light-weight fibers. I suppose as they run in a single system thread they are no option for the kind of light weight threads requested by the OP. Is there really much difference between what Windows terms a fiber and what Modula-2 etc. terms a coroutine? A thread is little more than a preemptively-scheduled coroutine, and it's always seemed slightly perverse to define fibers in terms of threads rather than the other way round. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 presented by _language_extensions. (And about the interface the libraries offer to the user) Here an as broad as possible range of ways to do parallel processing should be allowed - hiding the details (i.e. if using MPI or OpenMP or something else) should be hidden in the implementation in the library in a way as transparent as possible to the user. I think that modifying the language to incorporate MPI would be extremely difficult and would be so near the bleeding edge of computer science that the next person to do it would design something equally good but utterly different. As I understand it MPI is generally used to pass a result vector between nodes, at that point determining the extent of the vector and when it's ready for transfer is going to be highly application-specific i.e. a library issue. Looking elsewhere in this thread, I believe that the number of CPUs can be got as part of the thread-affinity API which I believe would be of use in TThread, at worst if you set the affinity to 0x you get back a vector showing which CPUs actually exist. However an interesting issue is that on some architectures the list of available CPUs can have holes in it, e.g. I've got a system here with CPUs 0, 1 4..15 available. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] ASM on Win64
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 idea to trust information posted here often more than two years ago. The information about the Win64 target that I found at http://www.freepascal.org/docs.html is either incomplete or missing completely.) I am in particular interested in: 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 obvious? 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? Does it, like MSVC++, *only* support that calling convention? smime.p7s Description: S/MIME Cryptographic Signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ASM on Win64
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 obvious? The option -a, not -A (and -al if you want Pascal + assembler source). 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? Does it, like MSVC++, *only* support that calling convention? Afaik, yes. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Light weight threads for FPC
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 start to implement this (some kind of parallel keyword) any tome soon. OTOH, doing _explicit_ multithreading (and thus multiprocessing with OS support) and integrate this in a more Delphi-Language like way than TThread can be done with no or (for a little bit more straight forward use) with just a little support from the language itself. That is why I suggested the EventThread / ThreadEvent paradigm. (which of course is not light weight). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ASM on Win64
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 something obvious?
The option -a, not -A (and -al if you want Pascal + assembler source).
Thanks, adding just -al without a parameter gave me an *.s file
containing to the asm output for the Lazarus project file.
Not sure if this is the right place to ask, but how do I produce *.s
files for the other units in the project? I suppose adding
{$output_format (something)} at the top of the unit should do the trick,
but I can't get that to work either.
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ASM on Win64
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 calling convention? Yes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ASM on Win64
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
combinations. Am I missing something obvious?
The option -a, not -A (and -al if you want Pascal + assembler source).
Thanks, adding just -al without a parameter gave me an *.s file
containing to the asm output for the Lazarus project file.
Not sure if this is the right place to ask, but how do I produce *.s
files for the other units in the project? I suppose adding
{$output_format (something)} at the top of the unit should do the trick,
but I can't get that to work either.
Just make sure that the unit gets recompiled, either by doing a build
all, removing the existing ppu or making a change in the source.
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ASM on Win64
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
