Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
The reason is that the cache coherency algorithms don't scale. This again is a software problem. If the task to do allows it the software needs to be written in a way that the cache coherency is not disturbed. BTW all super-computers feature thousands of CPUs, but of course this is not simple SMP. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Op Thu, 31 Jul 2008, schreef Michael Schnell: The reason is that the cache coherency algorithms don't scale. This again is a software problem. Cache coherency algorithms are implemented in hardware. If the task to do allows it the software needs to be written in a way that the cache coherency is not disturbed. Easier said than done, because threading always involves multiple cores operating in the same address space, which means the cores need to communicate which core has which page in cache. BTW all super-computers feature thousands of CPUs, but of course this is not simple SMP. Like I said, the HPC world did move to distributed memory with message passing years ago and is not using threading. Threading simply didn't scale enough. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Daniël Mantione wrote: Easier said than done, because threading always involves multiple cores operating in the same address space, which means the cores need to communicate which core has which page in cache. They don't care about pages. They only care when writing to shared memory (to keep other caches consistent). This is on cache line level, e.g. 32 bytes for PPC usually, 128 bytes on Intel. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On Thu, 31 Jul 2008 11:02:28 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Before we discuss endless about useless stuff, I'll make a proposal for a first addition: support of the synchronized keyword. It does no more than protecting a procedure automatically by a critical section so only one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized This means that all classes synchronize against one critical section. Do you mean one global crit sect per class (and descendants) or one global crit sect for all classes? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Will this also allowed for methods? Besides saving the typing of endless try ... finally statements and the initialiation of the unnamed critical sections, it creates also slightly better code because the LeaveCriticalSection call can be inside the implicit exception frame which is created anyways. Any suggestions about doing it better? BTW: I'll ignore comments like nobody needs this, I need it :) I like it. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Mattias Gaertner schrieb: On Thu, 31 Jul 2008 11:02:28 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Before we discuss endless about useless stuff, I'll make a proposal for a first addition: support of the synchronized keyword. It does no more than protecting a procedure automatically by a critical section so only one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized This means that all classes synchronize against one critical section. Do you mean one global crit sect per class (and descendants) Per class. The question is if it's possible to do this per class instance too. or one global crit sect for all classes? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Will this also allowed for methods? Yes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Per class. The question is if it's possible to do this per class instance too. To me Per class does not seem appropriate at all. Per instance in fact seems to make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Micha Nelissen schrieb: Florian Klaempfl wrote: Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; Any suggestions about doing it better? How to avoid deadlocks? Indeed, I'am open to any suggestions :) Just an idea: maybe a global call tree analysis with a call tree attributed with critical section information can find potential deadlocks? If a synchronized class is calling another synchronized class ... :-S. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Florian Klaempfl wrote: Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock That's not so good example since now it's almost gone. That suggests this synchronized keyword would be deprecated in a few years as well ;-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
synchronous class [Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables]
IMHO per class may create some problems? but maybe I am just overlooking something? TBar =class( TFoo ) end synchronized class; Let's say TFoo was declared in another unit, and TFoo was not declared Synchronized. Then TFoo code can be entered by anyone at any time. Even if a thread is in TBar. How would one make sure, that a base class, knows about all classes that inherit from it? Neither can you say the baseclass must also be synchronous class, because ultimately there always is TObject. and TObject does not want to be Synchronous class, or all Create/destroy would be in critical sections? It my be possible to work around, this, but it would probably create a ig overhead, as every method one very class would have to perform checks at runtime. Similar for instance wide protection. Regards Martin Michael Schnell wrote: Per class. The question is if it's possible to do this per class instance too. To me Per class does not seem appropriate at all. Per instance in fact seems to make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock And since that time they are working to get rid of it. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: synchronous class [Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables]
Martin Friebe wrote: IMHO per class may create some problems? but maybe I am just overlooking something? TBar =class( TFoo ) end synchronized class; Let's say TFoo was declared in another unit, and TFoo was not declared Synchronized. Then TFoo code can be entered by anyone at any time. Even if a thread is in TBar. How would one make sure, that a base class, knows about all classes that inherit from it? Why does it need to know? Base classes can't access the fields of inherited classes anyway. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Micha Nelissen schrieb: Florian Klaempfl wrote: Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock That's not so good example since now it's almost gone. That suggests this synchronized keyword would be deprecated in a few years as well ;-) Come one, it's not that hard to understand :): synchronized might allow the same way of working: first, you work with big locks, later to add more fine granulated ones. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Per instance would mean to need an algorithm to automatically define a new Mutex when creating an instance. So maybe the TSynchronizedObject that might be the parent of all class(...) synchronized will define a TSynchronizedObject.Create that creates a Class-common or a system wide Mutex, while the create in a child class can modify this behavior to the use of an instance variable as the Mutex to have a per-instance protection. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
one thread can enter it. But I want to extend it. First, it can be applied also to classes and object: tmyclass = class(...) synchronized A class protected by a sync object is a monitor. Several other languages have this as a first class citizen. TMyClass = Monitor (xxx) This means that all classes synchronize against one critical section. For the straight case this is ok, but what about virtual methods ? Further, it allows an additional symbol to be given procedure p;synchronized mycriticialsection; it must be of the type System.TRTLCriticalSection and the procedure will be synchronized against this critical section. Besides saving the typing of endless try ... finally statements and the initialiation of the unnamed critical sections, it creates also slightly better code because the LeaveCriticalSection call can be inside the implicit exception frame which is created anyways. Any suggestions about doing it better? BTW: I'll ignore comments like nobody needs this, I need it :) For methods or classes? I think single classes with an own syncobj are the rare case? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On 31 Jul 08, at 10:49, Graeme Geldenhuys wrote: On Thu, Jul 31, 2008 at 12:11 AM, Vinzent HĂśfler [EMAIL PROTECTED] wrote: a desktop system with hundreds of processors in the next few years or so. Practical benchmarks these days have shown, that a Quad-Core gains almost nothing compared to a cheaper Dual-Core in most practical circumstances. That's probably due to the currently available software all being single threaded. I remember back in the day when I used OS/2. Even though it ran on a single core system, it felt a lot more responsive that todays OS's, because most apps and the OS + WPS used multiple threads extensively. Quicker visual feedback played wonders to the illusion that it was fast. Now with todays multi-core systems it will not simply be an illusion. Well, one of the points with OS/2 is that the OS handles thread (and process) switching rather efficiently (without burning too many resources just on doing this); something not necessarily true for other operating systems including their most recent versions. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Hi Joost, Actually the trend started probably ~10-15 years ago with the DSP processors. Then along came Transmeta, and the Itanium, then there ware the GPUs including from NVidia, and there is PlayStation 3. They all use this type of approach. The first massive multicore I am aware of is the new Sparc http://en.wikipedia.org/wiki/UltraSPARC_T1 and http://en.wikipedia.org/wiki/UltraSPARC_T2 from SUN. Intel actually is playing a bit of a catch-up game. The shared memory however has worked perfectly for the DSPs for many years, so it has for the Itanium, Crusoe, the GPUs, and PlayStation. The future is not likely to be in faster systems, but in more cores. This seems to be the consensus lately among the processor architects. Intel already demonstrated 100+ core processor last year. This year we expect the first 16 core processors to hit the market ( 8 HT cores), and the direction is very clear. Any compiler vendor, or developer, should at least be paying attention ;-) . With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Joost van der Sluis [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wednesday, July 30, 2008 8:23 AM Subject: Re: [fpc-devel] Russian locale information not compatible withFPClocale variables This is only usefull if you have really, really, much cores. As Intel indeed propagates? And how do those threads handle othe resources? (memory?) I think this is the far-away future. Intel is only pressing this because they are scared that in a few years they can not improve PC speed as fast as they could before. They have to do/scream something. But time will tell? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Hi John, This is just a discussion. There is no real need for something like this at the moment yet, and probably you should really just keep an eye on what CodeGear and the other vendors are doing and follow their lead ;-) . It is very likely we will start to see more and more of this stuff in the coming years, but we will see. With best regards, Boian Mitov Mitov Software http://www.mitov.com - Original Message - From: Lee, John [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wednesday, July 30, 2008 8:42 AM Subject: RE: [fpc-devel] Russian locale information not compatible withFPClocale variables Because it's so simple we could then announce that we support parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did come along eg in Delphi or some other of the languages mentioned, we could take a view as to whether we'd support it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Boian Mitov wrote: among the processor architects. Intel already demonstrated 100+ core processor last year. This year we expect the first 16 core processors to hit the market ( 8 HT cores), and the direction is very clear. Any compiler vendor, or developer, should at least be paying attention ;-) . I think it's the world upside down. Intel should be engineering stuff we want, not the other way around. If we compiler/application developers don't develop multithreaded programs then they can't sell their expensive processors anymore. Seems wrong to me ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Russian locale information not compatible withFPClocale variables
Wasn't suggesting no sync - just trying to say let's keep it very simple so we can do it quickly, but not, in words of mr E too simple! I yield to the gurus re how simple it can be w/o it not being usable. J [...] Because it's so simple we could then announce that we support parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did come along eg in Delphi or some other of the languages mentioned, we could take a view as to whether we'd support it. Sorry, but adding parallelism into the language without providing proper synchronization primitives sounds kind of stupid to me. But to add some more food to the discussion: For asynchronous or something similar I would require it to be scoped: procedure RunningMultiCore; procedure Task1; asynchronous; begin ... end; procedure Task2; asynchronous; begin ... end; var i : Integer; begin begin // Task scope Task1; for i := 1 to 1000 do Task2; end; // If we get here, Task1 and 1000 Task2's are finished. // Evaluate results... end; Alas, there's no way to declare sort of block-local variables... but this at least allows for finer grained parallelism without to many hassles (when and where to decide of some routine has finished, was it started at all before and such things). Coarse grain parallelism could be handled the usual way via TThread class Co. Of course, there's the problem with core-utilization (how many subroutines are allowed to run parallel? etc.pp.), but as those are mostly runtime decisions, there should either be some API to control the behaviour or the compiler/OS should decide as they seem fit. And the main problem: To evaluate any results, you need some memory being accessed by the parallel tasks, which brings us back to the initial objection: There's no sense in doing that without also providing proper synchronization primitives. volatile or atomic keyword, anyone? -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Op Wed, 30 Jul 2008, schreef Boian Mitov: Hi Joost, Actually the trend started probably ~10-15 years ago with the DSP processors. Then along came Transmeta, and the Itanium, then there ware the GPUs including from NVidia, and there is PlayStation 3. They all use this type of approach. The first massive multicore I am aware of is the new Sparc http://en.wikipedia.org/wiki/UltraSPARC_T1 and http://en.wikipedia.org/wiki/UltraSPARC_T2 from SUN. Intel actually is playing a bit of a catch-up game. The shared memory however has worked perfectly for the DSPs for many years, so it has for the Itanium, Crusoe, the GPUs, and PlayStation. The future is not likely to be in faster systems, but in more cores. This seems to be the consensus lately among the processor architects. Intel already demonstrated 100+ core processor last year. This year we expect the first 16 core processors to hit the market ( 8 HT cores), and the direction is very clear. Any compiler vendor, or developer, should at least be paying attention ;-) . It is extremely important to note the number of cores cannot scale endlessly. The limits of SMP based systems were discovered in the HPC world more than 10 years ago. 64 or 128 cores seems pretty much the limit, few machines with more cores have been produced. The reason is that the cache coherency algorithms don't scale. You get too much traffic between processors. This is already visible with eight socket Opteron systems today, the performance is disappointing, despite the very good NUMA-style design of the Opteron processor. In fact, we are getting close to the limits. With AMD's announcement of the 12 core Magny Cours processor, we would have 96 cores in an 8 socket machine. I have to see this happen and I am sceptical it will perform. Quad socket may well limit for this processor. The HPC world did move from SMP systems to clusters, distributed memory systems. Multi-threading was replaced by message passing, and there we are today, Roadrunner has been built, the first 1 petaflops computer. The end of message passing has now been announced, it for sure we won't be able to do exaflops with passing. Still, this is not very relevant for us desktop users. What would be interresting for us, is what will happen on the desktop. What will happen if we can afford 100+ cores in our desktops? Will our desktops become clusters with an interconnect network? Now, of course, many people are still coding single threaded applications. Parallelizing is a need for the future. But know that the multi-core race won't last as long as the megahertz race, whatever cpu manufacturers tell you about 100+ core processors. We may already be about halfway at the moment. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On 30 Jul 2008, at 16:35, Boian Mitov wrote: The future is not likely to be in faster systems, but in more cores. This seems to be the consensus lately among the processor architects. It's the consensus between the marketing departments of various processor manufacturers, because that's what they're delivering now and in the short term future. As shown by Amdahl's law, just adding more and more cores stops getting you significant performance gains fairly soon (even if 95% of your code is perfectly parallelisable). See e.g. http://en.wikipedia.org/wiki/Amdahl's_law Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
On 30 Jul 2008, at 16:35, Boian Mitov wrote: The future is not likely to be in faster systems, but in more cores. This seems to be the consensus lately among the processor architects. It's the consensus between the marketing departments of various processor manufacturers, because that's what they're delivering now and in the short term future. As shown by Amdahl's law, just adding more and more cores stops getting you significant performance gains fairly soon (even if 95% of your code is perfectly parallelisable). See e.g. http://en.wikipedia.org/wiki/Amdahl's_law Well, try http://en.wikipedia.org/wiki/Gustafson's_Law for a comparison. And don't forget, despite the name, those are not laws, not even theories. See, Moore's Law turned out to be wrong after all. ;) Of course, you're right in the general case. Personally, I seriously doubt that we will see a desktop system with hundreds of processors in the next few years or so. Practical benchmarks these days have shown, that a Quad-Core gains almost nothing compared to a cheaper Dual-Core in most practical circumstances. Of course, that's what the processor architects are trying to change here. But considering the majority of desktop users, what would an e-mail program or word-processor gain from 64 cores? 99% of the time it's idling anyway... Vinzent. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
