NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/os2/programm/3830

Text File | 1992-07-27 | 7.8 KB | 196 lines

Newsgroups: comp.os.os2.programmer
Path: sparky!uunet!caen!hellgate.utah.edu!jensen.cs.utah.edu!brian
From: [e-mail] (Brian Sturgill)
Subject: Re: Can someone at IBM please explain why developers should develop for OS/2?
Date: 28 Jul 92 02:14:36 MDT
Message-ID: <[e-mail]>
Organization: University of Utah CS Dept
Lines: 186



Below is a response to two different individuals from IBM.
I wish to thank them both for responding to my original post.
By the same token I don't think I am getting my message through, so
I'll post another message explaining what I'm driving at.
In this message I'll deal only with the issues relating
to the IBM WorkSet/2 "professional" development system.

I put the "professional" in quotes as I have trouble believing anyone
would bill it as a professional development system.
I doesn't have C++ or a even a profiler.
It's optimizer is buggy (though having finally tracked one down
into a small code sample, it may not be quite as bad as I thought).
It is dog slow, and (I had not realized this as I have a 16 meg machine)
it is a pig.  Thus I think in my mind, C Set/2 will from here on
be referenced as the PIG-DOG compiler.  (Wouldn't it be fun
it the name caught on... I bet that would get it fixed fast!)

Feel free to pass this message on to the IBM internal network, friends,
collegues, etc.

>
> From: [e-mail] (dave)
> Newsgroups: comp.os.os2.programmer
> ...
>
> In <[e-mail]> Brian Sturgill writes:
> > I had assumed that with the beta tools, that they were slow because of debug
> > code... Wrong... this compiler's a dog.
>
> I can't comment on your comments about support, ordering, or NFS, but I
> can comment on compiler stuff.  The problem with the compiler is not that
> it's a dog, the problem is that it's a pig: it likes to have lots and
> lots of memory available.  We're fixing that, though.  The first CSD
> features a performance improvement of around 10%, and the next CSD will
> have significant improvements in working-set size, which will lead to
> better swapper behaviour.  Some of our preliminary tests show compile-
> time improvements of around 25% over the first CSD on small machines.
> We'll let you know when this is available.  In the mean time, you'll see
> big improvements if you jack your machine up to 16M of RAM.  I know that
> this is a poor way to fix the compiler's memory allocation problems, but
> it *will* give you fast relief.
Thanks for trying, but I already _HAVE_ a 16 meg machine.  However,
following your general idea, I threw an extra 4 megs into the machine,
and it does help.
The compiler is still a dog though... think I'm talking hot air?
Here's a minor benchmark:
I took a small program (2 files, total of 752 lines) and
ran it through ICC, GCC (in the EMX freeware package), and Borland
C/C++ 3.0 for DOS (BCC).
These were all ran on a 386/33 (128K cache) with 20 megs of RAM.
ICC was on an HPFS volume, GCC and BCC were on badly fragmented FAT
volumes, and thus ICC should have an advantage.
Times include all of the compile and link.
To avoid caching differences, I ran the compiles twice and
only timed the second one for each platform.
BCC was given 4 megs of DPMI memory in an OS/2 DOS box.
Command lines used:
    ICC FMT.C HEAD.C
    GCC FMT.C HEAD.C
    BCC -efmt -ml FMT.C HEAD.C

Results (in seconds):
    ICC    30.46
    GCC    12.92
    BCC    13.25

In other words a freeware compiler designed for another platform, and
a 16-bit DOS compiler are both more than twice faster than ICC.
If I were on the C Set/2 team, I'd be quite embarrased.

>
> > Also in June... the projects mostly there... I turn on the optimizer...
> > Gak!!! it screws up loop expression-extraction optimization.
> > I loose a week trying to get around the problems... decide I'll just have
> > to live without optimization... I don't call IBM!!! -- I'd lose another week.
>
> How do you expect us to fix bugs if you don't tell us what they are?
> ...
At the end of this message, I've included a small program that trips
the bug.
To see the bug... ICC prog.c works, ICC -O+ prog.c doesn't.
>
> dave
>
> -------------------------------------------------------------------------
> Dave Mooney                                              [e-mail]
>  C Set/2 Development, IBM Canada Lab, 844 Don Mills Rd, Toronto, Ontario
>             "If you've got a blacklist, I want to be on it"
>

********** Second Message **************

> From: [e-mail] (Tim Francis)
> Newsgroups: comp.os.os2.programmer
> ...
>
> ...
> you've been having.  I have posted your item internally, but have no idea
> ...
Thank you, I appreciate it.
>
> Let me address a couple of items:
>  - You found a bug in the optimizer, but didn't report it.
>      fed-ex a fix out to you.  There is a compiler CSD available already
I have the CSD from CompuServe, but as it does not contain a list
of bugs fixed, and claims to be BETA in a readme, I am somewhat hesitant
to try it.  Is it stable? (I.E. I really don't want my beta testers
debugging your beta and my beta.)

>  - Your desire for C++ and a profiler.
>      Please understand that a "new, open IBM" does imply that we should lay
>      _all_ our plans on the table - this is a competitive market.  You are
>      asking me for specific details about a future, unannounced version of
>      our product, and I just can't comment in that sort of detail.
>      Trust me: * Your concerns (and wishes) are being listened to.
>                * C Set/2 is a fully supported compiler, still undergoing
>                  development and enhancments.
>                * _I_ believe in making as much information as possible
>                  available to you, as soon as possible.  The decision to
>                  develop or not develop, announce or not announce, any given
>                  product, or component of that product, is very carefully
>                  thought out.  As soon as I _can_, I _will_ tell you.
I had a lot of nasty things to say about this section, but I'll let it pass.

>  - You say that we should have made available, from day 1, a development
>    environment "WITH ALL THE PROGRAMMING DOCS (at least on-line), and
>    the hard copies of docs AT COST."
>      Correct me if I've misunderstood you, but the programming docs are
>      provided (on-line) with the toolkit (part of the WorkSet).  Look in
>      your toolkit folder, under "Toolkit information".    -tim
What I'm talking about is the overview manuals.  The reference
manuals are there, but the other things are not.
Further the help system makes it very hard to print things out, it's
more or less the whole huge document, or a "page" at a time.

Not addressed above.

Why does a "professional" development environment not have a profiler?
Why is it so slow?
Why does IBM charge so much for the hardcopy manual set?
How can anyone possibly justify a >$800 price tag?

I'm somewhat amazed at your messages... it seems to me that you
see nothing incredibly wrong with the package having been released
like that.  It seems to me that you've perhaps not compared it to
other packages on peer platforms.  Against any package I've seen
that bills itself as a professional development package, Workset/2
is very weak.

Anyway you guys are obviously "Good Joes" for answering, so I don't
want to beat on you too badly.

Here's the code that breaks the optimizer:
    #include <stdio.h>
    #include <ctype.h>
    void doit(char *p)
    {
        long isbad;

        isbad = 0;
        if (!isalpha(*p++))
            isbad = 1;
        for (;;) {
            if (!isalpha(*p) && !isdigit(*p)) {
                if (*p == '\0' || *p == '=')
                    break;
                isbad = 1;
            }
            p++;
        }
        printf("%ld\n", isbad);
    }

    void main(void)
    {
        doit("test");
    }

When the optimizer is turned on, isbad is not initialized to zero and
thus contains junk. (I've checked the assembly output and what I'm saying
is what is happening.)


Brian