Przemyslaw Czerpak wrote:
which can use it) so there is no simple answer. Without modifications
in core HVM code but changing only HVM stack functions it reduce
the speed of PCODE evaluation over twice in my Linux box.
As I said the most important problem is caused by the fact that
we are using very similar to Clipper API which forces using TSD/TLS.
In few years when new hardware will be commonly used and compilers
will support it the problem should be smaller and we can try to
create single library because the overhead will not be such big.
Hi,
I'm not the MT guru, but just have an idea. In current implementation we
need access TLS for most of many Item and Extend API functions:
hb_param(), hb_itemReturn(), hb_par*(), hb_ret*(), etc. The exception is
some base Item API functions which does not access parameters and does
not return value: hb_itemNew(), hb_itemGet*(), hb_itemSet*().
For example, if we have harbour level function implemented in C, and we
need to access 5 parameters of the function and return a value, we'll
need 6 times to get STACK pointer from TLS, because every hb_par*(),
hb_ret*() is independent and needs STACK to do its job.
What if extend Harbour API functions by set of MT "compatible" version
of the functions? I.e. hb_mtpar*( HVM* pVM, int iParam, ... ), etc.
HB_FUNC( AAA )
would be preprocessed to
void HB_FUN_AAA( HVM* pVM )
If function code uses old style hb_par*(), it will work OK, but it will
be slower in MT mode. Number of hb_par*(), hb_ret*() and some hb_item*()
functions is not very big, and writing MT version is easy
(straight-forward passing of pVM to other API calls).
What is expected time penalty of additional parameter in hb_mt*() in
comparison to TLS access?
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
