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

Ooops

-> Delphi Xe8

-Michael

In our previous episode, Michael Schnell said:

Seemingly Xe3 provides a parallel loop feature to support fast multi-Core applications

No it does not.

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.

Marco van de Voort wrote

In our previous episode, Michael Schnell said: > Seemingly Xe3 provides a parallel loop feature to support fast > multi-Core applications No it does not.

Xe3 was a typo.
Xe3 seems to. At least they advertize it ....

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.

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 ?

Will the fpc library provide the appropriate classes for doing "TParallel.For" as described ?

-Michael

Michael Schnell wrote

Xe3 seems to. At least they advertize it ....

-> Xe8 seems to. At least they advertize it ....

(Who modifies my messages on the fly ?!?!?!?!? ;-) )

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

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

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

on "patches welcome" once anonymous functions are supported.

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

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

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 :-)

Marco van de Voort 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

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

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.

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

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

"Michael Schnell" wrote

> 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

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 ;-) )

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

In our previous episode, Michael Schnell said:

.. 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.

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