RELEASE on March, 1st !!!

[Marc-Antoine Parent]

Le 04-02-13, à 11:39, Konstantin Popov a écrit :

>
>>> 1. performace issues [with gcc3]
>>>    It looks like we can solve them for some platforms (intel), at
>>>    least temporarily - and hoping that the future gcc release will be
>>>    better. The things are "all right" out-of-box for other ones
>>>    (e.g. apple). DO I SEE IT RIGHT?
>>
>> As for Apple, I can say that there was a substantial drop in 
>> efficiency
>> between gcc 2.95 and 3.1. _some_ of that was regained with 3.3, but I
> Could you quantify that "substantial drop"?
> Recently, as we discussed the performance issues with gcc3, you said
> that gcc 2.95.* was faster without saying "substantially". If I
> remember right.

Original ozbench: (mozart 1.2.4, gcc 2.95)
nrev            : 16530
tak_normal      : 9050
tak_thread      : 4420
fd_simple       : 13720
compiler_simple : 4690
diff            : 9370
knights         : 6760
bridge          : 17130
port            : 11220
rec_normal      : 12680

Same ozbench for mozart 1.2.5, gcc 3.1
nrev            : 18410
tak_normal      : 10570
tak_thread      : 4830
fd_simple       : 17890
compiler_simple : 5790
diff            : 12270
knights         : 8000
bridge          : 20760
port            : 13720
rec_normal      : 13140

I guess it is acceptable.

I cannot give you the same numbers for mozart 3.0a and gcc 3.3, as I do 
not have "the same" ozbench...
But there was some improvement.
I guess I could recreate mozart 3.0a with gcc 2.95 for new comparable 
benchmarks... Most of the libraries it uses are pure C, right?

>> cannot say that we have a satisfying compiler yet. I may make a few
>> tests with an unreleased 3.3.1 I have built from Apple sources, if
>> there is an interest.
> I'd say it is at least interesting to have a theory why the code
> compiled with gcc3 runs slower than compiled with gcc2: e.g. for i386
> it had to do with "too clever" (inappropriate in our case) GCSE,
> register allocation, and probably some missing/non working peephole
> optimizations. More interesting is how to force the compiler to do the
> "right" job, preferably - with checks in the 'configure' script that
> would make selection of optimization options independent of particular
> compiler version.

At the time of 3.1, I did play with -finline-limit values. It had some 
impact. I am not a gcc guru, I can make a few tests and measure the 
impact, but exploring combinations would be done with not enough 
knowledge, and hence expand more time than I have available. If you 
tell me what worked on other platforms, I can compare.

>>> 3. packaging
>>>    Probably the bulkiest chunk of work. I'm afraid we might miss
>>>    information about Windows (apparently, the Windows packaging
>>>    business is going to change hands now). MacOS X & other platforms
>>>    (aka FreeBSD) seem to be a bit ad'hoc as well. WE WOULD WELCOME 
>>> ANY
>>>    INPUT - HELP, INFORMATION, DOCUMENTATION HERE!!! Credits will be
>>>    of course given..
>>
>> I have sent detailed instructions to the list before. Look for the
>> title: "Release (OSX)"
>> The packaging still involves many manual steps, and should be further
>> automated, but packaging material does exist. It is not integrated in
>> the CVS at this point, which we may want to do.
> definitely!!

Feel free ;-) (as in: You already have the files.)

>> We cannot really automate it at this point, as the packaging tool uses
>> absolute paths in a binary file (!!!) to point to the mozart install
>> location (which I hardcoded to /usr/local/oz) and the resources
>> location (i.e. LICENSE.html and ReadMe.rtf, which should live in the
>> source folder somewhere... and that being hardcoded is simply stupid.)
> Honestly I don't get the details, but: the more documented and the
> more automated (which also means better understood and documented,
> even as a script) - the better.

As things stand, there is at least an obligatory manual step per 
package: Specifying the absolute path of the Readme in the PackageMaker 
(a GUI application.)
Automating it is thinkable, but hellish. (AppleScripting the UI... 
Ouch! Bound to be fragile.)

To be honest, there is more; my strategy for the two separate 
sub-packages (doc, GTK) was to install mozart, build the main 
installation package from the installation location, wipe the 
installation location (!), installl the doc only, make that package, 
wipe, install GTK only, make that package... And reinstall everything. 
A pain. We should probably play with --install-prefix, or whatever it 
is that allows to "install" things in one place that will be run from 
another install location... How do you do RPM's on other unices, BTW?

Bottom line: We need a document with the packaging procedure. I guess I 
could try to make my emails into something more formal...

> I would gladly retract the "ad'hoc" comment, but something tells me
> that it takes *many* people that repeadly and reliably repeat the
> process until it becomes "standard". And I didn't see it myself, pity.
> We should probably get a Mac here (again) ;-)

You might get to enjoy it ;-)

>> Now, I must say we have a harder issue: Do we build for Panther (10.3)
>> only, stay compatible with Jaguar (10.2), etc. (I am not sure we are
>> even still compatible with 10.1, and I would advise against even
>> trying.)
> I would really like to delegate the decision making to you, MacOS guys
> (just tell me the outcome). I see though the possible considerations:
> . which platform is most spread?
> . are they backwards- compatible?
> . pedagogically ("PR-technologically", so to say) it is better to
>   support the latest system.. it is also better for the whole Mozart
>   community ("look - the guys even support the latest MacOS!!")

I am one guy; we need other (more serious) Mozart Mac users to tell us 
their needs.
I think that we have to support 10.3; the question is:
a) Do we support only 10.3 (sounds like coping out, but given that the 
Mac-Mozart community is probably small, it would be nice to know how 
many of those are still using 10.2. Maybe no one.)
b) Do we try to make one install that supports both 10.3 and 10.2 
(losing some optimizations, and probably hard to do well)
c) Do we make two packages (also a minor pain, but feels more 
manageable. My favourite solution, but adds to the download interface 
complexity.)

I do feel that we cannot maintain compatibility with an older OS 
indefinitely; esp. as each version tends to come with a new version of 
a compiler. The big jump here was 10.2 with the ABI changes, however; 
the changes we go through now could be handled more easily.

>> We may have to consider separate versions. For example, Mozart uses
>> dlopen, etc. which were not in Jaguar, so we used a compatibility shim
>> (dlcompat); it became standard in Panther. I am not sure that, if we
>> link against dlcompat, mozart will work properly with Panther (though
>> it should.) The reverse is of course not true.
>> libbz2 and libiconv, both needed by mozart-gtk, also made their way
>> into Panther.
>> In other words, some testing and some hard decisions should be done. I
>> myself would favour separate packages, but it adds to the workload.
> Hmm.. maybe the "use static linking for minimizing dependencies" is
> beneficial for MaxOS as well?

I would say not. darwin really likes dynamic. dlopen is news because we 
had a different mechanism. Loading the dynamic libraries can be 
optimized to amazing degrees, through a process called prebinding, 
though I never did do that for Mozart, as there are limitations that 
were only recently lifted  in 10.3. I did experiment a bit, but I felt 
that the small increase in load time did not warrant the added 
complexity to the make process... Esp. as I am not configure-savvy. But 
something to be considered someday, and another reason to make two 
packages, IMHO. As things stand, even without these optimizations, I 
find the oz startup time to be quite acceptable.
Bottom line, I am not keen on static, as I really feel it runs counter 
to the platform's philosophy.

There are more issues regarding platform philosophy; I wish I had the 
time and energy to make Mozart into a proper framework... But that is a 
project for someone else.

>> While still on the Panther issue, we also need to add a few lines to
>> configuration of  platform/wish:
>> The Makefile.in uses pbxbuild in two places. This was renamed to
>> xcodebuild in Panther. we should check which of these, if any, was
>> installed. (It would live in /usr/bin )
>> I am not familiar with configure, but maybe I could attempt writing
>> this.
> it would be great if you would try - that's how it should be done.
> I promise to help whenever I can.

OK. Will do. (though not immediately!) But I have to understand 
configure better someday, so...

>>> darwin-ppc
>>>   997 (hard-wired name of compiler ('gcc') in oztool.sh)
>>
>> Good point, we now have the xlc option. Did anyone try building mozart
>> with it?
> Huh? With what?

xlc, the C/C++ compiler from IBM, now has a version that is 
aggressively optimized for the G5. It's anything but free, however. 
(around US$300 for academics, I think.)
I was wondering if one of the other Mac programmers on the list had a 
chance to play with it.

Marc-Antoine