On Mon, 30 Mar 2009, Szak�ts Viktor wrote:
Hi,
> I didn't want to kill it, just wanted to tweak it for MT.. we're using such
> MT switch for most compilers to force MT friendly runtine/code generation/
> whatever. Isn't this needed for owatcom?
We were discussing about it when OW OS2 port was added.
If you want to set this flag as default then you have to
also enable DL malloc as default memory manager. It will
reduce a little bit the performance in single thread application
but MT once will be usable. The problem is with OS2 builds because
dlmalloc does not support this OS.
So far I haven't found time to check in OpenWatcom source code why the
memory manager used of MT mode is such slow.
> ---
> -bm build target is a multi-thread environment
> ---
> bm (Netware, OS/2, Windows NT only) This option causes the
> compiler to imbed the appropriate multi-thread library name in the object
> file. The macro __SW_BM is predefined if bm is selected.
> ---
I know what it does. And for sure it's good to use it if necessary.
But it will be also good if you will test the results of switching
you are enabling. I know that it's time consuming but in some cases
we also lost information about already tested and updated settings.
Probably now when we do not use CRTL *printf() functions familly
then we do not use any other functions which needs separate MT/ST
versions (except memory allocator) so it should be enough to compile
only hbvm with this switch. Anyhow it's not good practice because
we do not know what exactly this switch does. We should ask on Open
Watcom devel list or look in the source code for details.
> > performance is -5s but I haven't made any real tests here and I only
> > guess that stack calling convention is slower then register one.
> It's definitely slower, but needed for compatible .dll generation
> as far as I understood Andi's mail. Didn't spend time to do
> side-by-side comparison though.
It's only necessary if you want to use OpenWatcom harbour.dll with
other Harbour builds. It's not necessary if you want to use OpenWatcom
harbour.dll with OpenWatcom Harbour builds.
Anyhow if for some reasons you want to make harbour.dll with OpenWatcom
and use it later with other compilers then it's enough to change only
attributes of exported functions and it's not necessary to manipulate
with calling convention of the whole build. Just like you do not have
to change it for static builds. Such option can be set only for DLLs.
Personally I'd prefer to use native for compiler settings.
If I want to make something different then I can use HB_USER_CFLAGS.
Anyhow in this particular case the calling convention options should
be changed extremely carefully. In OS2 builds they were badly interact
when some OS2 16bit API functions were called and we were fighting for
quite long time with GPF in MT mode. Finally Maurilio set it to value
which were playing well OS2 16bit API but in fact we haven't checked
if this can be resolved by local only modification not by global
calling convention change.
Unlike most of other C compiler we are using OpenWatcom comes with
quite big set of own CRTL functions and programmers should carefully
read manuals to check which ones can be separately enabled/disabled
to not cause some bad interactions.
BTW hbmk2 should inherit some of the above flags.
Now when we moved all C compiler flags settings to *.cf files we have
nothing to detect them at runtime. I think that it will be good to
use one common for all compiler make variable with C flags which we
can pass to hbpp and store in header files. Otherwise you will have
problem with keeping hbmk2 synced and it will not be possible to use
it with custom Harbour builds which may needs some special settings,
f.e. calling convention. Not all C compiler settings can be disabled
by setting some opposite options second time.
> > Anyhow here the difference will be probably minor.
> > Without this switches OpenWatcom gives the fastest code in few places.
> > F.e. even ICC is not close to OpenWatcom results in T029 and T030.
> > The overall performance is also quite good. In my tests it was noticable
> > better then BCC or POCC.
> Great, so if you say -bm isn't needed for MT support I can remove it.
> Shall I go for it?
If you plan to leave it in such version then for sure yes. I'd prefer
fully functional and quite fast ST builds then unsable.
Anyhow it is necessary for MT support but it's always good to check what
it does. In this case I'd prefer to enable DLMALLOC as default for
OpenWatcom Windows builds.
Viktor, no offence but it's a problem when you are making some local
tests for only few possible conditions and then you are updating SVN
code to your results which does not have to be representative.
In this case we end with such information in ChangeLog:
- Reverted yesterdays attempt to make owatcom builds faster.
After the change the compilation time went slower, the
binaries got smaller, but execution speed got actually worse.
I've left -oz option removed for win, that's the only
remaining change, plus -5r in os2/dos.
owatcom seems not very useful for production.
> Unfortunately owatcom has the same problem as bcc/pocc: lack
> of support, so some libs had to be disabled due to compile errors
> (libhpdf, hbqt), but I otherwise I have no problem keeping it in first line.
It's not a problem of 1-st, 2-nd, ..., 10-th line.
If developers will not be interested in updating some builds then they
will die. Nothing more nothing less.
But when you are leaving such notes like above then for sure we will
not find anyone to work on it.
People trust you so when you are writing something in the ChangeLog then
you should be sure about it otherwise you are creating myths which very
often exist for years and are hard to revert. Just like old [x]Harbour
build settings and build time configuration/option.
Or this note in the ChangeLog:
% Removed -ko option as it slightly decreases performance in -gc3 mode.
(it's better in -gc[0-2] only)
I know you restored it but just for information and to clarify what Mindaugas
wrote about it because we will have other myth about -ko slowing -gc3 code.
It does not even reduce macro compiler performance in the speedtst.prg
because optimization code is enabled only for expressions which can be
optimized by this flag. In this case there is no such expression.
So the speedtst code is always faster and smaller. But of course it can
be executed slower on some computer. It's the side effect of used CPU
caches in modern computers.
F.e. you can delete some unused function from hvm.c and it may increase
or decrease the performance in some tests on some computers.
Why? Because it will change memory alignment of other code what will
interact with CPU cache usage. But it does not mean that we should try
to tune the Harbour core code for some CPU cache usage in the computer
you are using for tests.
BTW by default macro compiler inherits compile time optimization flags
and settings. It can be disabled by -kr compile time switch.
You can test it using this code:
proc main()
M->VAR:="ABC"
? &("M->VAR+0")
return
try to compile it with with such switches:
1) default switches
2) -ko
3) -ko -kr
HTH.
best regards,
Przemek
ps. I'll update default memory manager and compilation switches in
DOS, Windows and Linux OpenWatcom builds. I do not have OS2 to
make tests so I will not make any manipulations here.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
