On Wed, 01 Oct 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> The results are:
> ARR_LEN = 16 ST MT MT
> N_LOOPS =100USE_TLS
[...]
> total application time: 64.95 100.00 89.30
> Previous MT overhead
Przemyslaw Czerpak wrote:
The only reason I see for binding stack preload with "no tls" is that stack
preload also uses inlined Windows like function to access tls. But I see it
as to separate features stack: stack preload and tls access method
(compiler native or system API)?
When compiler n
On Tue, 30 Sep 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
>>> Perhaps we should use HB_THREAD_STUB or pass pStack parameter to functions.
>> I've just implement it for estack.c and hvm.c.
>> If possible please make tests so we can compare how it effects BCC builds.
> Sorry for long delay,
Hi,
Przemyslaw Czerpak wrote:
Perhaps we should use HB_THREAD_STUB or pass pStack parameter to functions.
I've just implement it for estack.c and hvm.c.
If possible please make tests so we can compare how it effects BCC builds.
Sorry for long delay, I was out of office a little, and I'm not
On Thu, 18 Sep 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> it's possible the goal could be reached, but I'm unable to write inline
> function for tls accessing.
> Perhaps we should use HB_THREAD_STUB or pass pStack parameter to functions.
I've just implement it for estack.c and hvm.c.
I
But if you can create inlined version of above
code for BCC (don't ask me how, I stop seriously using BCC in
DOS days and here some tricks will be necessary) then maybe it
will give enough speed improvement for this compiler.
Hi,
it's possible the goal could be reached, but I'm unable to write
Hi,
Przemyslaw Czerpak wrote:
I guess that if you inline this function then speed of MT Harbour-BCC
programs will be greatly improved. If I understand the above it should
look like (meta code which should be adopted to BCC so it can be inlined):
static __inline__ PHB_STACK hb_stack_ptr( voi
On Wed, 17 Sep 2008, Mindaugas Kavaliauskas wrote:
Hi,
> I've spent some time (well not much, an hour...) to find out how tls works
> on Windows.
> The original idea is based on undocumented (but de facto) fs segment. In
> Win32 both 9x and NT fs segment register points to Win32 Thread informat
Hi again,
Looks that the most expensive is TLS access and it reduce the
performance in BCC builds - the cost of ABI in which VM pointer
is not passed to functions :-(.
We can do three things:
1. add some tricks to reduce TLS access like HB_THREAD_STUB in
xHarbour in hvm.c but it makes
Hi,
Przemyslaw Czerpak wrote:
Maybe BCC does not inline InterLocked*() functions or
they are not as efficient as they can be.
Interlocked*() functions are WinAPI functions. It cannot be inlined.
I know that they are Windows API functions but
MSDN says that each compiler should try to inline
On Tue, 16 Sep 2008, Szak�ts Viktor wrote:
Hi Viktor,
>> 2. we can change used ABI so each Harbour function which may
>> need HVM access will receive pointer to HB_STACK. Quite easy
>> for HB_FUNC() but for internal ones it will force much more
>> jobs.
> One vote for this one.
>
Hi Przemek,
2. we can change used ABI so each Harbour function which may
need HVM access will receive pointer to HB_STACK. Quite easy
for HB_FUNC() but for internal ones it will force much more
jobs.
One vote for this one.
Wouldn't this increase the size of -gc3 compiled ap
On Mon, 15 Sep 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
>> Maybe BCC does not inline InterLocked*() functions or
>> they are not as efficient as they can be.
> Interlocked*() functions are WinAPI functions. It cannot be inlined.
I know that they are Windows API functions but
MSDN says t
13 matches
Mail list logo
