Hi Przemek,
> 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.
Could you enable DLMALLOC for owatcom? [ I don't want to mess it up ]
[ I see you committed most of the things along these lines. Hereby thanks
and sorry for some double thoughts in this mail. ]
> 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.
A quick check today revealed that it doesn't change generated machine code,
but it will link against the MT C RTL instead of ST one plus I see a symbol
in
the .obj named __imthread. I didn't investigate what it does or how it's
used.
> > > 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.
The idea is that harbour.dlls are interchangeable (I think this is a major
point in .dlls), so we should allow for this definitely. [ BTW, owatcom
.dll
support still doesn't work for other reasons. ]
> 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.
It would be better indeed, but I have no idea how to tweak exported
function attributes. We can remove this once this is set. Maybe it
already is, someone should check. [ or maybe I will with new rev. ]
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.
Hm, and that leads me to the point that os2/owatcom.cf was added by
me by copying one of the existing copies, so the settings there are
*almost surely wrong*. It would need OS/2 users to tweak it, test it or
just to set those good looking settings you mention above.
> 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.
Yes, I was thinking about something like this, for me it would be many
times important to retrieve the default settings of a given build, and
currently there is no way to do it (also for default Harbour flags). Such
information could be included in speedtst output even. If you could
lay the infrastructure for this, I would finish it.
Since every file/lib can have different settings, we should keep this
effect on current minimum level in the future.
> 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.
Please do it.
> 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:
Well I know, but I only have two hands and 24 hours a day, so
please nobody expect me to do extensive tests with dozens of
compilers with tens of different flag combinations and becoming
an expert of every details. I'm trying my best, but this is impossible.
I'm no owatcom user, so this is my humble attempt to do something
about experienced bad performance, while trying to sync things
and fix things I happen to find along the way. I do these thing in
the hope that someone is interested and will tweak it further,
corrections and more insight is always welcome and in fact essential.
It happens along the way that there isn't a straight road towards
the end result, but since we're in development it's somewhat normal.
All in all, I hope owatcom users will take care of their compiler.
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.
There wasn't a huge crowd before my comment either. Unfortunately :(
My latest attempts were the last efforts to get owatcom out of the bad
reputation. Overall though - and after dealing with lots of compilers lately
-
I see that we should focus on MinGW and MSVC.
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.
Well, for me it did actually slow down the _end result_. What can I say.
It was not a random process, it was not a sudden peak, it was measured,
and repeatable. I don't didn't look into the result details, which was a
mistake, luckily Mindaugas gave an explanation pointing to these. Later
I've used the details to find out the real nature of MinGW 4.3.3 from 4.3.2
"slowdown", which was actually a speedup if you consider each test
individually.
> 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.
Yes, that may well be true. Please correct me if I send wrong conclusions,
I'm not offended, just please don't question what I *see* on screen in
general :)
> 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
Which means it makes code less compatible with Clipper, which
means we should also use -kr for Harbour builds? Question: Should we?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
