On Sat, 28 Mar 2009, Mike Evans (Gmail) wrote: Hi,
> Even I don’t have the latest version of Xbase++ but an old one I'm sure > that they lock the application threads to use only one CPU. They have a > way to choose which CPU to use (as an example the less used CPU). AFAIR some MS-Windows API functions it's possible to assign process to single CPU. The problem is that it's not portable solution and it does not have to reduce the execution conditions to the same level as in single CPU systems. If xbase++ authors were making sth like above then it suggests that they had some code used to synchronize threads and designed for single CPU machines where it was guarantied that single memory access cannot be interrupted or create some conflicts due to simultaneous access and they wanted to still use it. But for me it seems to be rather strange idea and it does not have to give expected results. > In older versions they have serious degradation in speed due to interlock > between 2 or more CPUs. This suggests that they use different internal locking code for single and multi CPU machines. Is it really true? > Also they have another speed penalty due to the use of > som.Dll (If I remember correctly is a Visual age compiler dll). They have > made performance analysis and they said that they are thinking to change > C compiler and remove the som.dll. Only with this they said that the speed > benefit it will be from 15% to 30%. We also have similar differences between compilers. F.e. in Windows usually BCC creates one of the slowest code and MSVC one of the fastest and the difference sometimes it's even bigger. > Also about the Dbf speed the problem exist due to classify the underlying > of the record. Probably I'm missing what is the real problem here in xbase++ but I do not see any reason why it has to cause speed overhead. It can be implement with some really minimal static overhead. Anyhow it's not my goal to discuss about it now. I would like to see the real cost of automatic item assign serialization in xbase++ or other protection mechanism they are using to make it MT safe. Of course if it really is MT safe in all cases what I would like to confirm too. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
