Re: [fpc-devel] Xe3 Parallel for
On 05/14/2015 12:28 AM, Marco van de Voort wrote: No, since the that coder decides what he wants to offer up for inclusion, not the community. For obvious reasons, a single person is less able to see the consequences of a design decision than multiple analysts can. So that principle often results in unnecessary failing of basically excellent ideas. http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support Yes. That is a good example of a monologue. Not really, as in this mailing list I have been explicitly requested to write that text. Otherwise I would not have bothered to invest the offer (knowing that rather likely it will not have any consequences). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/13/2015 11:16 AM, Sven Barth wrote: You do know that there exist other synchronisation primitives beside the event queue? And since the TParallel.For itself is a blocking call I highly suspect that they *don't* use the event queue, but TEvent and similar instead. If using other synchronization primitives but the event queue might interfere with e.g. the LCL's Application.ProcessMessages mechanism. IMHO it already is not a nice implementation that the fpc event queue needs to be handled in parallel with the LCL event queue (which is buried within the Windows API when running in Windows, but coded explicitly in Pascal when running in Linux). Creating yet a third potentially parallel active synchronizing mechanism for multi-core support hidden in a library sounds not like a good idea to me. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Am 13.05.2015 11:11 schrieb Michael Schnell mschn...@lumino.de: And for the widgetsets: The VCL was never designed to be cross platform in contrast to te LCL. It would have meant immensely more work for Embarcadero to port the VCL to Mac, Android, etc. than to buy a third part solution and to market that. Of course they could have used the CLX, but there they would have first needed to port it to a more modern Qt version. The Lazarus team (similar as the fpc team) took on with this effort and did an excellent (but tedious and still unfinished) job. This proves that it is possible, but Embarcadero just bought the Firemonkey library instead. Again the LCL was implemented from the ground up to be platform independant. The VCL was not. That is a huge difference in effort necessary to port it. Is it possible? Yes. Is it feasible? Hell, no. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 06:43 PM, Marco van de Voort wrote: Will the fpc library provide the appropriate classes for doing TParallel.For as described ? That will depend on when you submit that patch :-) This of course triggers my standard answer to such wording: It does make sense to first decide whether you want to drink tea or beer before opening either the cupboard or the fridge. Meaning that - regarding the limited resources - a community should first discuss exactly what effort (what kind of implementation in detail) would make sense, before anybody bothers to start coding. I do know that you thing along very different lines (and do provide fantastic work as a result :-) ). But the (IMHO) abysmal design (much too closely following Delphi) of the Unicode support shows the negative result of lacking research before starting coding (see http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) -Michael (more a researcher than a coder ;-) ) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Am 13.05.2015 10:53 schrieb Michael Schnell mschn...@lumino.de: On 05/12/2015 05:39 PM, Sven Barth wrote: Why should that interfere in any kind?! Behind the scenes it's propably using TThread anyway... Because Foreground code (here the calls made by the visible code the user creates to use TParallel) and the background code in the threads that TParallel might create, communicate (i.e. the Thread notifying the foreground code about a state such as ready) via the Event-Queue and for this the foreground code need to call CheckSynchronize(). But CheckSynchronize() needs to be manually done by the user in a pure FPC project. Only with projects using the LCL (or mse-gui or whatever framework), this is done without the user explicitly creating code for this. How else should SW.Stop; in the example work ? OK, TStopWatch.Stop; might call CheckSynchronize() in a loop with a timeout definable as a property of TStopWatch. This hopefully will not interfere with other CheckSynchronize() calls done e.g. by the LCL. You do know that there exist other synchronisation primitives beside the event queue? And since the TParallel.For itself is a blocking call I highly suspect that they *don't* use the event queue, but TEvent and similar instead. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 05:49 PM, Sven Barth wrote: Their own .Net compiler has shown that one can't simply map the Delphi language to the CLR 1:1 and expect something seamless. We see that with FPC's JVM support as well. So using a variant of the language that embeds itself into the framework is a much better approach. ... defying any portability. Hence making the programming system a hoax. Horrible ! Of course fpc is doing a hard fight with the effort to do a write once run everywhere system ( - http://www.lazarus-ide.org/index.php?page=about : Lazarus and Free Pascal strives for write once compile anywhere). But IMHO it's worth the effort. And for the widgetsets: The VCL was never designed to be cross platform in contrast to te LCL. It would have meant immensely more work for Embarcadero to port the VCL to Mac, Android, etc. than to buy a third part solution and to market that. Of course they could have used the CLX, but there they would have first needed to port it to a more modern Qt version. The Lazarus team (similar as the fpc team) took on with this effort and did an excellent (but tedious and still unfinished) job. This proves that it is possible, but Embarcadero just bought the Firemonkey library instead. Firemonkey might be a nice options for projects that (independent of the target device) are suppose to show a floating GUI design. But this should be a decision of the program designer and not forced by lacking features of the programming system. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 05:39 PM, Sven Barth wrote: Why should that interfere in any kind?! Behind the scenes it's propably using TThread anyway... Because Foreground code (here the calls made by the visible code the user creates to use TParallel) and the background code in the threads that TParallel might create, communicate (i.e. the Thread notifying the foreground code about a state such as ready) via the Event-Queue and for this the foreground code need to call CheckSynchronize(). But CheckSynchronize() needs to be manually done by the user in a pure FPC project. Only with projects using the LCL (or mse-gui or whatever framework), this is done without the user explicitly creating code for this. How else should SW.Stop; in the example work ? OK, TStopWatch.Stop; might call CheckSynchronize() in a loop with a timeout definable as a property of TStopWatch. This hopefully will not interfere with other CheckSynchronize() calls done e.g. by the LCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
In our previous episode, Michael Schnell said: On 05/12/2015 06:43 PM, Marco van de Voort wrote: Will the fpc library provide the appropriate classes for doing TParallel.For as described ? That will depend on when you submit that patch :-) This of course triggers my standard answer to such wording: It does make sense to first decide whether you want to drink tea or beer before opening either the cupboard or the fridge. .. which is not appropriate for the question that you asked. Meaning that - regarding the limited resources - a community should first discuss exactly what effort (what kind of implementation in detail) would make sense, before anybody bothers to start coding. No, since the that coder decides what he wants to offer up for inclusion, not the community. But the (IMHO) abysmal design (much too closely following Delphi) of the Unicode support shows the negative result of lacking research before starting coding (see http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support Yes. That is a good example of a monologue. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On Tue, May 12, 2015 at 12:43 PM, Marco van de Voort mar...@stack.nl wrote: IMHO no discussion is necessary besides the bugreport where you added the patch :-) Except for Prism (which is a descendant of pascal syntax) are there any other thread oriented syntax that could be accommodated by FPC? thanks, Dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
In our previous episode, Michael Schnell said: Nonetheless to me it seems rather silly that they offer a dedicated language construct (parallel for / future) with Prism and suggest using another language construct (anonymous method) for exactly the same purpose with Xe8. Prism, as Sven said was by Remobjects, and only inspired by Pascal, and undoubtedly they simply tacked on a common .NET/c# feature there. I never saw much synergy in Prism with either FPC or Delphi. Regarding fpc, I am aware that anonymous method had been discussed here. I did not take a deeper look into same. IMHO no discussion is necessary besides the bugreport where you added the patch :-) Is / will the syntax be the same as with Delphi ? Of course, we are a delphi compatible Will the fpc library provide the appropriate classes for doing TParallel.For as described ? That will depend on when you submit that patch :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Xe3 Parallel for
Seemingly Xe3 provides a parallel loop feature to support fast
multi-Core applications
try
// counts the prime numbers below a given value
Tot:=0;
SW:=TStopWatch.Create;
SW.Start;
TParallel.For(2,1,Max,procedure(I:Int64)
begin
if IsPrime(I) then
TInterlocked.Increment(Tot);
end);
SW.Stop;
Memo1.Lines.Add(Format('Parallel For loop. Time (in milliseconds): %d -
Primes found: %d', [SW.ElapsedMilliseconds,Tot]));
except on E:EAggregateExceptiondo
ShowMessage(E.ToString);
end;
So they did not use the Prism syntax (parallel for / future), but (again)
introduced something new incompatible to everything.
Will fpc follow ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Am 12.05.2015 13:45 schrieb Michael Schnell mschn...@lumino.de: TParallel.For(2,1,Max,procedure(I:Int64) This is a class method parameterised with D2009 anonymouse method, not a language construct. If you read the release manifest well, they talk about a parallel library, not paralel language extensions. I did not claim that it's a brand new language construct (or anything else), I just said feature. If the code snippet I mentioned is compilable even with D2009, only the library is new. Nonetheless to me it seems rather silly that they offer a dedicated language construct (parallel for / future) with Prism and suggest using another language construct (anonymous method) for exactly the same purpose with Xe8. They don't /own/ Prism. They merely license it, so what the Oxygene developers do and what the Delphi developers do are two different things. Regarding fpc, I am aware that anonymous method had been discussed here. I did not take a deeper look into same. Is / will the syntax be the same as with Delphi ? At least in mode Delphi, yes. Will the fpc library provide the appropriate classes for doing TParallel.For as described ? If I remember correctly we already have something similar somewhere among our supplied units for quite some time. In the end I suppose that support for that TParallel class will be based on patches welcome once anonymous functions are supported. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Ooops - Delphi Xe8 -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 02:21 PM, Sven Barth wrote: They don't /own/ Prism. They merely license it, so what the Oxygene developers do and what the Delphi developers do are two different things. IMHO it's really silly that they provide different Pascal Dialects and Widget frameworks for different targets such as CIL (-Prism), Windows (-VCL), Mobile (Firemonkey only). fpc /Lazarus is a lot more portability friendly on that behalf, even if there is still a lot work in progress (several targets, and conceptually questionable (Unicode support - supposedly not worse than with Delphi). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 02:21 PM, Sven Barth wrote: In the end I suppose that support for that TParallel class will be based on patches welcome once anonymous functions are supported. OK. As this is a kind of thread support, I assume that it might interfere or be related with with the CheckSynchronize() mechanism (for making use of the TThread.Synchronize() and TThread.Queue() based Event queue. (This is why I monitor the threading related stuff an Delphi and other locations). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Am 12.05.2015 15:27 schrieb Michael Schnell mschn...@lumino.de: On 05/12/2015 02:21 PM, Sven Barth wrote: In the end I suppose that support for that TParallel class will be based on patches welcome once anonymous functions are supported. OK. As this is a kind of thread support, I assume that it might interfere or be related with with the CheckSynchronize() mechanism (for making use of the TThread.Synchronize() and TThread.Queue() based Event queue. (This is why I monitor the threading related stuff an Delphi and other locations). Why should that interfere in any kind?! Behind the scenes it's propably using TThread anyway... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Am 12.05.2015 15:44 schrieb Michael Schnell mschn...@lumino.de: On 05/12/2015 02:21 PM, Sven Barth wrote: They don't /own/ Prism. They merely license it, so what the Oxygene developers do and what the Delphi developers do are two different things. IMHO it's really silly that they provide different Pascal Dialects and Widget frameworks for different targets such as CIL (-Prism), Windows (-VCL), Mobile (Firemonkey only). There is nothing silly here. Their own .Net compiler has shown that one can't simply map the Delphi language to the CLR 1:1 and expect something seamless. We see that with FPC's JVM support as well. So using a variant of the language that embeds itself into the framework is a much better approach. And for the widgetsets: The VCL was never designed to be cross platform in contrast to te LCL. It would have meant immensely more work for Embarcadero to port the VCL to Mac, Android, etc. than to buy a third part solution and to market that. Of course they could have used the CLX, but there they would have first needed to port it to a more modern Qt version. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
