Good morning Przemyslaw,
I see that it was a full weekend of tests out there :)
Today I was going to try your latest changes to the OS/2 build, but I get this
error during a full rebuild
(E:\repository\harbour-svn\source\vm\vmmt)IF NOT EXIST ..\..\..\lib\os2\gcc md .
.\..\..\lib\os2\gcc
-Messaggio Originale-
Da: Phil Barnett [EMAIL PROTECTED]
A: harbour@harbour-project.org
Data invio: lunedì 6 ottobre 2008 2.54
Oggetto: Re: [Harbour] Harbour website extremely slow
On Sunday 05 October 2008 07:27:32 am Enrico Maria Giordano wrote:
It's already better now.
I
On Sun, Oct 5, 2008 at 11:56 PM, Lorenzo Fiorini
[EMAIL PROTECTED] wrote:
Tomorrow I'll be able to do some tests on servers ranging from Xeon
Dual Processors ( two physical CPUs 4 logical ones ) to Dual Quad
Processors ( 2 physical CPUs 8 logical ones ).
Here is the speedtst --thread=2
On Sunday 05 October 2008 11:18:47 pm Szakáts Viktor wrote:
Great, many thanks.
Just one last comment; so far the daily snapshots were called 'harbour-
svn.tgz'
and 'harbour-svn.zip' (these are linked from the homepage), .bz2 as an
option
is nice, but IMO we should keep .tgz and .zip too.
Hi Phil,
Also, the dailies would IMO better be named as
'harbour-nightly.[zip|tgz|bz2]'.
Great, I've modified the homepage to have all
three, with the new names.
Here is a small patch to avoid the internal
'co' directory in the source archives:
---
...
cd
Hi Phil,
For SVN backups:
rsync -av harbour-project.svn.sourceforge.net::svn/harbour-project/
* .
Do you have a script I can run to do a nightly build?
You can create the most generic binary build by
going into 'harbour' dir of the nightly source,
and running './make_tgz.sh'. The result
2008-10-06 11:17 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/thread.c
! fixed typo in recent modification
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
-Messaggio Originale-
Da: Przemyslaw Czerpak [EMAIL PROTECTED]
A: harbour@harbour-project.org
Data invio: lunedì 6 ottobre 2008 11.17
Oggetto: [Harbour] 2008-10-06 11:17 UTC+0200 Przemyslaw
Czerpak(druzus/at/priv.onet.pl)
2008-10-06 11:17 UTC+0200 Przemyslaw Czerpak
and trying to build hbrun.exe with hbvmmt:
../../../../lib/os2/gcc/hbvmmt.a(garbage.o): Undefined symbol _DosSleep
referenc
ed from text segment
../../../../lib/os2/gcc/hbvmmt.a(garbage.o): Undefined symbol _DosSleep
referenc
ed from text segment
After clear cache starting from blank page load preview main page open
in 15 second from http://harbour-project.org/preview/
Then About page in 3 second
After clear cache starting from blank page load preview main page open
in 12 second from http://harbour-project.org
Similar result internet
2008-10-06 12:38 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbclass.ch
* harbour/include/hboo.ch
+ added SYNC attribute to accepted syntax in class declaration
it allows to compile code which uses this attribute but low
level implementation is not
1) Some of the text is too small.
2) The layout use a fixed font size which can't be change when I set my browser
to a different font size.
3) The SF Logo should be added to each page so page statistics are added to the
Harbour project on SF.
(we use Logo4 on the home page now)
Logo 3
Below are results of
[E:\harbour809mt\harbour\tests]..\bin\hbrun_mt.exe speedtst.prg
--thread=2 --scale --exclude=mem
Strange results, or I am confused ?
factor are around 2 (total 1.90) but computer is SINGLE CPU
AMD Athlon 2200+ 2.0 Ghz, 1 Gb RAM
David Macias
10/06/08 07:08:33 OS/2 4.50
Current Harbour under OS/2 build/run with just one warning:
../../../garbage.c: In function `hb_gc_acquire_lock':
../../../garbage.c:102: warning: implicit declaration of function `DosSleep'
David Macias
On Mon, 06 Oct 2008, David Arturo Macias Corona wrote:
Hi David,
Below are results of
[E:\harbour809mt\harbour\tests]..\bin\hbrun_mt.exe speedtst.prg --thread=2
--scale --exclude=mem
Strange results, or I am confused ?
factor are around 2 (total 1.90) but computer is SINGLE CPU
AMD Athlon
Przemyslaw,
here my numbers with latest speedtst.prg and with my older one (sp.log), to
see if spinlocks give better numbers.
New speedtst with --thread=2 --scale
Best regards.
Maurilio.
David Arturo Macias Corona wrote:
Below are results of
Here with --exclude=mem
10/06/08 15:17:17 OS/2 4.50
Harbour 1.1.0dev (Rev. 9555) (MT)+ EMX GNU C 3.3.5 (32 bit)
THREADS: 2
N_LOOPS: 100
excluded tests: 029 030 023 025 027 040 041 043 052 053 019 022 031 032 054
1 th. 2 th. factor
2008-10-06 15:30 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbthread.h
* harbour/source/vm/thread.c
* harbour/source/vm/hvm.c
+ add numeric HVM thread identifiers to thread structure. Now
HB_THREADID() returns numbers in all OSes
*
Date: Mon, 6 Oct 2008 11:31:17 +0200
From: Massimo Belgrano [EMAIL PROTECTED]
Subject: RE: [Harbour] Harbour website extremely slow
[...]
After clear cache starting from blank page load preview main
page open in 15 second from http://harbour-project.org/preview/
Massimo,
June July August :)
Sorry Marek
I don't undestand
Regard
Massimo Belgrano
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Horodyski
Marek (PZUZ)
Sent: Monday, October 06, 2008 3:40 PM
To: harbour@harbour-project.org
Subject: [Harbour] Harbour website extremely slow
Date:
This is just a test to demonstrate how would the layout of the site
with all the texts and images and for this reason there are some
errors in the content of the site. I will be updating it soon with the
correct content ... good comment on the order of months in the column
of news. ;-)
2008/10/6
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
On Mon, 06 Oct 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
Here is the speedtst --thread=2 --scale --exclude=mem on a Dual Quad Xeon
E5410
running Centos 5.2 i386 ( the server was in use by ~50 users )
Thanks for results.
When other processes are executed then this test will contain also their
Hi all,
What are the implications of using an older C .LIB (eg. ACE32.LIB for
v6.2) with a Harbour/Application that is build using MSVS 2005?
TIA.
Regards,
Randy.
___
Harbour mailing list
Harbour@harbour-project.org
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 pthread
On Monday 06 October 2008 04:46:50 am Szakáts Viktor wrote:
Here is a small patch to avoid the internal
'co' directory in the source archives:
I had to do a little more than that because the compressed files landed in the
right directory, but it's essentially fixed to not have the co/
On Monday 06 October 2008 04:59:18 am Szakáts Viktor wrote:
You can create the most generic binary build by
going into 'harbour' dir of the nightly source,
and running './make_tgz.sh'. The result will be
a .tgz file in that 'harbour' dir. The exact .tgz
name depends on the system, but this
Hi Phil,
On Monday 06 October 2008 04:59:18 am Szakáts Viktor wrote:
You can create the most generic binary build by
going into 'harbour' dir of the nightly source,
and running './make_tgz.sh'. The result will be
a .tgz file in that 'harbour' dir. The exact .tgz
name depends on the system,
Perfect!
Brgds,
Viktor
On 2008.10.06., at 18:43, Phil Barnett wrote:
On Monday 06 October 2008 04:46:50 am Szakáts Viktor wrote:
Here is a small patch to avoid the internal
'co' directory in the source archives:
I had to do a little more than that because the compressed files
landed in
2008-10-06 21:27 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbapifs.h
* include/hbextern.ch
* source/common/hbfsapi.c
* source/rtl/hbfile.c
+ Added hb_fsNameExists() C level function.
+ Added hb_FNameExists() Harbour level function.
; Both will return true
2008-10-06 21:50 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/source/vm/hvm.c
! fixed last commit typo in thread number allocating - all threads
where using 0 number
* harbour/source/vm/thread.c
! fixed return value in recursive call to hb_mutexLock() - was
Hi Przemek,
Thanks for these, I've added them, and will test
them in the next round.
Did you see the Darwin results?
Brgds,
Viktor
On 2008.10.06., at 2:46, Przemyslaw Czerpak wrote:
On Mon, 06 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
I've built Harbour on Darwin with L_USR/C_USR=-arch
2008-10-06 22:24 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* include/hbthread.h
! Committed MT fix to make it compile under Darwin.
Thanks Przemek.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
2008-10-06 22:33 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
* source/rtl/tobject.prg
! Formatting to some old code.
--
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
On Mon, 06 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
Did you see the Darwin results?
Yes, Thank you.
The most visible is the cost of mutexes in reference counters.
If there is no collision then all is executed quite fast:
ST mode (no mutexes at all):
[ T001: x := L_C
Hi Przemek,
Yes, Thank you.
The most visible is the cost of mutexes in reference counters.
If there is no collision then all is executed quite fast:
ST mode (no mutexes at all):
[ T001: x := L_C ]..0.07
MT mode and single thread:
[ T001: x := L_C
Hello Przemek
Here are attached the results on 2 computers with different
number of processors and operating systems.
What I did before compiling speedtst.exe.
1) Issued : make_b32 clean; make_b32; make_b32 install
2) Issued : make_b32_all clean; make_b32_all; make_b32_all install
3) Issued :
2008-10-07 02:57 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/Makefile
+ harbour/include/hbatomic.h
* harbour/include/hbthread.h
* harbour/source/vm/garbage.c
* harbour/source/vm/fm.c
* moved atomic and spinlock functions into hbatomic.h
*
On Tue, 07 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
We will have to add atomic inc/dec assembler inline functions to PPC
builds.
Also to Intel 64-bit builds I guess. (test above was x86/64-bit)
[EMAIL PROTECTED] is not IA-64 (Itanium)
Anyhow in DARWIN you should have libkern/OSAtomic.h
On Mon, 06 Oct 2008, Pritpal Bedi wrote:
Hi Pritpal,
Here are attached the results on 2 computers with different
number of processors and operating systems.
And below are attached those log files.
Thank you very much.
As I can see only Enrico can reach good scalability on Intel and
40 matches
Mail list logo
