Hi,
I didn't mean C compilers MM are better. I just proposed to try for
example nedmalloc in MT. Somewhere I've found that libc's malloc is
based on ptmalloc, and nedmalloc claims to be faster than ptmalloc.
So, we can try nedmalloc for tests that gives bad results for
dlmalloc.
I've p
Przemyslaw Czerpak wrote:
here are some words about dlmalloc and multi-thread:
Thread-safety: NOT thread-safe unless USE_LOCKS defined
When USE_LOCKS is defined, each public call to malloc, free,
etc is surrounded with either a pthread mutex or a win32
spinlock (depending o
On Mon, 06 Oct 2008, Mindaugas Kavaliauskas wrote:
Hi Mindaugas,
> here are some words about dlmalloc and multi-thread:
> Thread-safety: NOT thread-safe unless USE_LOCKS defined
>When USE_LOCKS is defined, each public call to malloc, free,
>etc is surrounded with either a pthrea
Przemyslaw Czerpak wrote:
Looks that there in no important difference between DL-MM and BCC-MM in
real MT programs in your system. DL has a little bit better performance.
In my test in Linux DL-MM in MT mode was killing the performance
in MT+ test in comparison to default SUSE malloc when in ST m
Hi Przemek,
Przemyslaw Czerpak ha scritto:
On Sat, 04 Oct 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
Many thanks for your results.
Looks that there in no important difference between DL-MM and BCC-MM in
real MT programs in your system. DL has a little bit better performance.
In my te
On Sat, 04 Oct 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
Many thanks for your results.
Looks that there in no important difference between DL-MM and BCC-MM in
real MT programs in your system. DL has a little bit better performance.
In my test in Linux DL-MM in MT mode was killing the p
Hi Przemek,
Przemyslaw Czerpak ha scritto:
On Fri, 03 Oct 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
Here my test:
Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
L2 Cache Size: 3072 Kb, Bus: 200 Mhz
4 GB RAM, Vista Ultimate 32bit
Standard Build:
set C_USR=-DHB_FM_STATISTICS_OFF
set HB_B
On Fri, 03 Oct 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
> Here my test:
> Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
> L2 Cache Size: 3072 Kb, Bus: 200 Mhz
> 4 GB RAM, Vista Ultimate 32bit
> Standard Build:
> set C_USR=-DHB_FM_STATISTICS_OFF
> set HB_BUILD_ST=
I would like to ask you
On Fri, 03 Oct 2008, Francesco Saverio Giudice wrote:
Hi Francesco,
> Here my test:
> Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
> L2 Cache Size: 3072 Kb, Bus: 200 Mhz
> 4 GB RAM, Vista Ultimate 32bit
> Harbour Terminal: Windows native console
> Harbour 1.1.0dev (Rev. 9542)
> Windows Vista 6.0.60
Hi Przemek,
Przemyslaw Czerpak ha scritto:
To Windows users:
I'm very interested in MS-Windows results from real multi CPU machine.
Does anyone have such computer and can test it?
Here my test:
Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
L2 Cache Size: 3072 Kb, Bus: 200 Mhz
4 GB RAM, Vista Ul
On Fri, 03 Oct 2008, Enrico Maria Giordano wrote:
Hi Enrico,
>> To Windows users:
>> I'm very interested in MS-Windows results from real multi CPU machine.
>> Does anyone have such computer and can test it?
> Yes, I have an Intel Core 2 CPU 6320. Can you briefly summarize the steps
> required to
On Fri, 03 Oct 2008, Maurilio Longo wrote:
Hi Maurilio,
> You're using mutexes for critical sections, in OS/2 there is a
> DosEnterCritSection() call which stops task switching until after a
> DosExitCritSection() is called.
This is only terminology problem. In OS2 API CRITICAL SECTION means
pea
Przemyslaw Czerpak wrote:
> The results are much worse then in my Linux box.
> It can be caused be few reasons:
> 1. the cost of task switching is probably much higher in OS2 then
>in Linux because it has to reload memory descriptors for each
>thread - it's forced by TLS format.
I don't kno
-Messaggio Originale-
Da: "Przemyslaw Czerpak" <[EMAIL PROTECTED]>
A: "Harbour Project Main Developer List."
Data invio: venerdì 3 ottobre 2008 18.23
Oggetto: Re: [Harbour] hb_threadID()
To Windows users:
I'm very interested in MS-Windows results fr
On Fri, 03 Oct 2008, Maurilio Longo wrote:
> And the winner is :)
> they're slower than before. a lot!
> I attach two files, speedtst.log which is built with -gc3 and hbvmmt and
> speedtstmt.log which is built with the same options but started with a
> parameter so that it runs with several thr
And the winner is :)
they're slower than before. a lot!
I attach two files, speedtst.log which is built with -gc3 and hbvmmt and
speedtstmt.log which is built with the same options but started with a
parameter so that it runs with several threads.
Best regards.
Maurilio Longo wrote:
> Ok,
>
Ok,
found it, I had to move main() as first procedure in file.
Maurilio.
--
__
| | | |__| Maurilio Longo
|_|_|_|| farmaconsult s.r.l.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/list
Przemyslaw,
I was going to try new speedtst, but even if it builds ok, it does not start,
there is no error, no exception, no output.
It simply exits.
Any idea?
Maurilio.
Przemyslaw Czerpak wrote:
> On Fri, 03 Oct 2008, Maurilio Longo wrote:
>
> Hi Maurilio,
>
>>> In -gc[0-2] mode each threa
On Fri, 03 Oct 2008, Maurilio Longo wrote:
Hi Maurilio,
> > In -gc[0-2] mode each threads makes:
> > if( ! --uiPolls )
> > hb_inkeyPoll();
> > in main HVM loop. Simple hack even acceptable in ST programs is killing
> > the performance in ST ones. Important is not hb_inkeyPoll() cal
And I did a full comparison, here we go
MT my speedtst modified to use two threads, -gc3
55.2
MT original speedtst, -gc3
65.07
MT original speedtst, no gc options, so -gc0
71.4
ST original speedtst, no gc options, so -gc0
52.2
Maurilio.
--
__
| | | |__| Maurilio Long
Hi Przemyslaw,
Przemyslaw Czerpak wrote:
> And I've got the answer. At least on my computer it's a hardware issue.
> In -gc[0-2] mode each threads makes:
>
> if( ! --uiPolls )
> hb_inkeyPoll();
>
> in main HVM loop. Simple hack even acceptable in ST programs is killing
> the perfo
Pritpal,
Sorry, I was not clear enough, on OS/2 threads are numerated like this,
xbase++ was born on OS/2 and probably mutuated such numbering from the OS.
Best regards.
Maurilio.
Pritpal Bedi wrote:
> Maurilio
>
>
> Because I'm used to use a thread id which is a number, this is the way i
Przemyslaw Czerpak wrote:
>
> But you haven't explained why numeric value is better then pointer.
Because when you print it it is more 'natural' or easy to the eye than a
0x03938474 or something like that.
That said, you're the master here, I did not want to introduce inconsistencies
in the way t
On Thu, 02 Oct 2008, Przemyslaw Czerpak wrote:
> Harbour in practice does not use any of such mutexes. Only some few small
> peaces of code are covered by them and it's small chance that two threads
> will be serialized. The cost of setting/releasing mutexes is the same for
> one and two threads so
Maurilio
Because I'm used to use a thread id which is a number, this is the way it
works on OS/2 and xbase++ on win32 and I did not find something similar in
current code.
Perhaps you are misunderstood of Xbase++ thread implementation.
ThreadID() function in Xbase++ always returns the
Hi folks,
Why you cannot use hb_threadSelf()?
Because I'm used to use a thread id which is a number, this is the
way it
works on OS/2 and xbase++ on win32 and I did not find something
similar in
current code.
Not all OSes have to support numeric thread ID. If you need number
then we w
On Thu, 02 Oct 2008, Maurilio Longo wrote:
Hi Maurilio,
> > Why you cannot use hb_threadSelf()?
> Because I'm used to use a thread id which is a number, this is the way it
> works on OS/2 and xbase++ on win32 and I did not find something similar in
> current code.
Not all OSes have to support nu
Hi Przemyslaw,
Przemyslaw Czerpak wrote:
> Why you cannot use hb_threadSelf()?
Because I'm used to use a thread id which is a number, this is the way it
works on OS/2 and xbase++ on win32 and I did not find something similar in
current code.
> It also returns valid identifier which is compatible
On Thu, 02 Oct 2008, Maurilio Longo wrote:
Hi Maurilio,
> I've added this little function to my copy of vm\thread.c, I attach it here so
> that Przemyslaw and/or Viktor can have a look at it and also because I'm not
> at ease with branching and so I don't know where to commit this change.
> -
Okay, the numeric type of return values very important...
PS: Sorry for bad english!
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Renato,
thanks, I've changed it to return 0, but a I think, see discussion with
Viktor, that it should be '1'.
Best regards.
Maurilio.
Vailton Renato wrote:
> Hi!
>
> I would like to make one small suggestion:
>
> ---8<-
> HB_FUNC( HB_THREADID )
> {
> #if defined( HB_M
Viktor,
yes, I had to log in to sourceforge, now it seems I was able to commit.
Thanks.
Maurilio.
Szakáts Viktor wrote:
> A bit later yes, but if you didn't commit since
> a long time, it's more probable that you have
> to first login to sf.net homepage and change
> you password, because they'v
A bit later yes, but if you didn't commit since
a long time, it's more probable that you have
to first login to sf.net homepage and change
you password, because they've reset them
a while ago (due to some security leaks).
After changin pw, SVN login should work.
Brgds,
Viktor
On 2008.10.02., at
Hi!
I would like to make one small suggestion:
---8<-
HB_FUNC( HB_THREADID )
{
#if defined( HB_MT_VM )
PHB_THREADSTATE pThread = ( PHB_THREADSTATE ) hb_vmThreadState();
if( pThread )
hb_retnl( pThread->th_id );
else
#endif
hb_retni( 0 );
}
--->8---
Viktor,
can you confirm that I have write rights on svn since I get a 401
authorization required trying to commit.
Best regards.
Szakáts Viktor wrote:
>
> On 2008.10.02., at 13:48, Maurilio Longo wrote:
>
>> Szakáts Viktor wrote:
> IMO, zero for main thread is alright.
I think it shou
On 2008.10.02., at 13:48, Maurilio Longo wrote:
Szakáts Viktor wrote:
IMO, zero for main thread is alright.
I think it should be 1 (one) given that the first thread I create
has a
threadid of 2 and so on.
This way it something doesn't seem to be right indeed.
I'd think, the first thread
Szakáts Viktor wrote:
>>> IMO, zero for main thread is alright.
>> I think it should be 1 (one) given that the first thread I create has a
>> threadid of 2 and so on.
>
> This way it something doesn't seem to be right indeed.
>
> I'd think, the first thread (above main one) should get ID #1, seco
Szakáts Viktor wrote:
I see no problem with this code. You can just simply
commit it to the trunk (as usual).
Ok, I'll try in a while.
Okay.
I,ve also noted that thread 1 has a threadid of 0 (zero) while the
other
threads have the correct id, maybe this is a minor glitch to
correct.
IM
Hi Viktor,
Szakáts Viktor wrote:
> I see no problem with this code. You can just simply
> commit it to the trunk (as usual).
>
Ok, I'll try in a while.
>> I,ve also noted that thread 1 has a threadid of 0 (zero) while the other
>> threads have the correct id, maybe this is a minor glitch to corr
Hi Maurilio,
I've added this little function to my copy of vm\thread.c, I attach
it here so
that Przemyslaw and/or Viktor can have a look at it and also because
I'm not
at ease with branching and so I don't know where to commit this
change.
---8<-
HB_FUNC( HB_THREA
Hi,
I've added this little function to my copy of vm\thread.c, I attach it here so
that Przemyslaw and/or Viktor can have a look at it and also because I'm not
at ease with branching and so I don't know where to commit this change.
---8<-
HB_FUNC( HB_THREADID )
{
#if defin
41 matches
Mail list logo
