On Sun, 09 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> I just did what you requested :-)
Sorry it was my fault.
I thought you still compares -bm overhead. In Windows builds we can use
DL malloc so it can be eliminated. Of course if it exists.
best regards,
Przemek
_
>Just a small question. What to you want to compare? :-)
>You are running two different test for ST and MT mode.
>They execute different code with different conditions.
>It's not expected that above results will be equal or
>similar.
>I thought that you wanted to compare the difference between
>ha
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> >Try to rebuild Harbour with HB_FM_DL_ALLOC and USE_DL_PREFIX macros,
> >f.e.:
> > set C_USR=-DHB_FM_DL_ALLOC -DUSE_DL_PREFIX
> >and recompile Harbour. Then compare speed results for both modes.
> Not so much difference:
> hbru
> I've also teststed 1.7a in Linux and WINE and it works correctly.
> The native Linux build does not work due to missing functions and
> some typos in header files. In spare time I'll try to collect my
> local OW patches and send them to OW devel list.
>> hbrun_st.exe speedtst.prg
>> ---
On Sat, 08 Nov 2008, David Arturo Macias Corona wrote:
Hi David,
> OpenWatcom in Windows does not fail with multithread
I've also teststed 1.7a in Linux and WINE and it works correctly.
The native Linux build does not work due to missing functions and
some typos in header files. In spare time I'
- Windows XPPro SP2
- OpenWatcom 1.7a
- Make GNU for Win32
- Current Harbour
Przemek:
OpenWatcom in Windows does not fail with multithread
hbrun_st.exe speedtst.prg
--
[ total application time: ]67.08
[ total real time: ]
