[fpc-devel] Russian locale information not compatible with FPC locale variables

[Marco van de Voort]

> Marco van de Voort schrieb:
> > 
> > Read this and the reactions, and weep:
> > 
> > http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voort+multicore#289008199451755a
> 
> I don't agree on the point that good mt support is a matter of the 
> framework. _Really_ good multithreading support is a matter and must be 
> a matter of the language as well and in several years and must be as 
> common as while or for loops.

Note that I already hinted on the duality. Performance vs ease of use. You
more or less specify the performance angle, for newly written code for
people with heavy calculation that generally know what they are doing. I
think that is the rarer case in practice. 

But the other side is not about perfecting lineair algorithm with a bit of
multithreading. I'm talking about what to do from the perspective of the avg
Delphi/FPC user. And most of them don't have really intensive calculating
loops, outside maybe some minor encryption/compression code that they never
wrote themselves in the first place.

It is not a simple linear algorum that needs updating with a bit of manually
instrucmented threading. 

The problem of "ease" is just that multithreading from scratch is too hard
or too time consuming as a programming model for most. Specially with a
single threading GUI (and maybe here and there GUI api), and the ad-hoc way
they throw together programs.

And they desperately turn to the tools makers (CG and us) to "fix" that,
because Intel promised them heaps of extra performance due to the multicore
revolution. So preferably they want us toe wave a magic wand and that their
old crusty VCL code ridden with timers, COM objects, external libs and the
like is suddenly fully multithreading and scales with number of cores.

Without a totally new design paradigm that is harder, and without a careful
tuning to avoid the threaded loop being slower than the single core one.

And that is IMHO not realistic. So the cure you are suggesting is for a
different problem, and for a happy few that also can handle manual threading
fine.

And then I think better frameworks is a better solution then optimizing
loops OpenMP style, because you won't even notice the speed up of that in
the avg app. 

> Currently, multithreaded programming is like programming spaghetti basic.
> A good framework is comparable to at least the try to program structured
> with line numbered basic but it is not forced by the language. The
> compiler must know about parallism.

Personally I hope we get it tomorrow. For me it would mostly work, since at
work I really do dataprocessing in a fairly linear way. But that isn't the
avg users case as far as I can see.