Subject: Re: Why We Should Use the STL (fwd)
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Sun Jun 04 2000 - 14:46:50 CDT
Eric,
I understand what you're saying and I agree with most of it. Using STL is
not an urgent feature for 1.0, but the beauty of open source is that the
development effort is not driven by artificial release dates.
So, if I understand correctly, you would not be completely resistant
towards thinking about such a change, but you would prefer that people
work on more signifigant and helpful changes.
Aaron Lehmann
P.S. I usually save the word Luddite to describe the girls in my class
who criticize me of being a geek and having no life just because I sit in
front of a computer all day. It's a very appropriate word :).
On Sun, 4 Jun 2000, Eric W. Sink wrote:
>
> I'd like to offer my personal congratulations to Aaron. Even though I
> keep a copy of Websters Ninth near my computer, I cannot recall any
> prior posts to abiword-dev which gave me cause to reach for it.
>
> Just call me one of the Luddites. :-)
>
> Actually, I don't really want to *veto* this idea. However, to borrow
> a word from the dictionary definition, I *would* have to describe myself
> as "resistant" to this change. And OTOH, I am also resistant to the
> veto.
>
> This message is not intended to bring resolution to the matter
> at hand. Instead, I want to explain two basic things:
>
> 1. The reasons why I am resistant to this change.
> 2. The reasons why I am resistant to a veto.
>
> The comments below are largely a discussion of principles. I have
> very few real practical objections to support my resistance, but
> I will offer those practical objections at the end of this note.
>
> 1a. I am resistant to this change because it is very low bang-for-buck
> when measured in terms of our current goal of reaching version 1.0.
>
> Once again: speed is not one of AbiWord's major problems. Yes, it
> can be improved. No, it's not a critically necessary move to enable
> AbiWord to reach a sizable base of real end users.
>
> Furthermore, improving the speed of UT_Vector should not be that hard.
> If speed were the problem, there are far less invasive ways of
> getting it.
>
> 1b. I am resistant to this change because the practice of avoiding
> the bleeding edge technologies has served me very well for a very long
> time.
>
> I am not a technophobe, but I have learned to manage project risk.
> In traditional project management, most decisions are examined
> in terms of the level of risk they would add to the project.
> All kinds of risks might be considered, including risk of schedule
> slip or risk of outright project failure.
>
> Adopting the use of templates would have increased the risks
> associated with this project. You cannot convince me otherwise.
>
> You can convince me that the risks have dropped significantly,
> as the prevailing C++ implementations have improved.
>
> You can convince me that the risks are acceptable.
>
> And, you can convince me that the day will come when this
> particular risk is widely accepted as negligible. If the
> major vendor compilers still do not implement templates
> correctly, then I would certainly argue that this day is
> not yet here.
>
> But you can not convince me that the increase in risk is
> zero.
>
>
>
> 2a. I am resistant to a veto because it would be demotivating to
> the people who are currently investing substantial effort into
> this project.
>
> Nobody here is working on AbiWord because under duress or threat
> of torture.
>
> Very few people here are working on AbiWord because of financial
> compensation.
>
> We're doing this for fun, mostly. Vetoes are no fun.
>
> 2b. I am resistant to a veto because I cannot definitively say that I
> have the right to take such an action.
>
> Under any circumstances, the notion of authority is quite poorly
> defined for a community-developed GPL project. In this case, I'd
> have to say that things may be even murkier.
>
> First, there's the GPL. Regardless of what kinds of authority may
> or may not be presence, the GPL enables any contributor to remove
> themselves from the influence of that authority while still retaining
> an affiliation with the code itself. Authority in a community
> developed GPL project cannot be absolute.
>
> Then there's the matter of how authority is developed. I started this
> project. I am the CEO of the company which has dumped more effort
> into this project than any other entity. That same company sponsors
> the Internet presence for this project.
>
> And yet, since AbiWord is community developed, I am reluctant to play
> dictator. There are others here who arguably have as much leadership
> on this project as I do. My personal involvement has diminished
> considerably, as the demands of a growing company have distracted me
> from heavy AbiWord involvement.
>
> Do I have the ability to get my way on major issues? Probably. But
> I am resistant to accept an approach which we would all find to be
> a disappointing way of resolving issues.
>
> 2c. I am resistant to a veto because I am sympathetic to the issue.
>
> Good points are being made. Compiler support for templates *has*
> improved. UT_Vector *is* slower than its STL counterpart. The
> prevalent use of STL *is* becoming real, thus validating its
> existence as a standard. I can't argue these things, and I don't
> know why I would if I could.
>
> I'm as drawn toward new and better technologies as anyone. I like
> to see the new technology chosen. But, I definitely don't like
> being let down. Some of my most spectacular disasters have been
> due to a decision to adopt a new technology before the risks
> associated with that technology had been mitigated or even
> fully understood.
>
> So is it possible that the risks associated with STL have been
> reduced to the point of acceptability? Sure. It's possible.
>
> --------
>
> An impartial outsider *could* simply say that if the
> Luddites want to maintain the status quo, then they should silence
> the objections of the STL Sect by improving the performance of
> UT_Vector. I would frankly prefer that said outsider simply
> pipe down, but the point would nonetheless hold some validity.
>
> --------
>
> As a practical matter, I can raise only two real objections:
>
> 1. Support for vendor compilers still matters, at least to me.
> Does anyone know if the QNX compiler can handle templates
> properly? What about BeOS? Solaris?
>
> 2. I still don't see how a switch to STL helps us achieve the
> kinds of major user-visible improvements which we still need in
> order to reach a version 1.0.
>
> --
>
> >Well, I'm pleasently suprized that an AbiWord developer would even suggest
> >such a contraversial change.
> >
> >I agree 100%. Speed is very important, even in desktop programs. It is
> >pointless to slow down some parts of the program by 23 times just because
> >of a fear of templates.
> >
> >Another issue I would like to raise is standards. The point of STL is
> >having a standard so that applications do not have to implement their own,
> >mediocre, simple types. This is what AbiWord has done. By all means,
> >AbiWord should use the standard, not only for speed, but so that C++
> >developers don't have to learn yet another type library. Using STL would
> >mean that we wouldn't have to maintain or support the UT_* classes,
> >because they would be replaced by faster, better, more standard
> >equivilents.
> >
> >I really hope this doesn't get vetoed by the luddites ( :) ) on this list.
> >Now, who's going to write this huge patch? ;-)
> >
> >Aaron Lehmann
> >
> >On Sun, 4 Jun 2000, sam th wrote:
> >
> >> ---------- Forwarded message ----------
> >> Date: Sun, 4 Jun 2000 02:45:51 -0500 (CDT)
> >> From: sam th <sam@uchicago.edu>
> >> To: abiword developer list <abiword-dev@abisource.com>
> >> Subject: Why We Should Use the STL
> >>
> >> Now, I realize that this is going to cause controversy, but I hope we
> >> don't need to have flames.
> >>
> >> Currently, we use none of the STL. This is becuase we have been under the
> >> impression that templates were not well-enough supported on all the
> >> platforms we use. However, this is untrue.
> >>
> >> As far as I know, the major compilers used for AbiWord are gcc (for linux,
> >> be and qnx), metroworks (for mac) and VC++, borland and gcc (for
> >> win32). every one of these compilers supports templates. As evidence of
> >> this, I offer the list of supported compilers on
> >> http://www.stlport.org/doc/platforms.html Every compiler we use (and lots
> >> of others) are listed. If I have left out any compilers, please let me
> >> know.
> >>
> >> as to why we should use the STL, the reason is: it is lots faster.
> >>
> >> I discovered this running a simple test of UT_Vector vs vector<>. If this
> >> test is fatally flawed let me know, and I will retract everything. But
> >> here goes.
> >>
> >> I ran the following code for both UT_Vector and vector<int*>
> >>
> >> void main()
> >> {
> >> for (int i=1; i<=1000; ++i)
> >> {
> >> #if 0
> >> UT_Vector vec;
> >> for (int j = 0; j<10000; ++j)
> >> {
> >> vec.addItem(&j);
> >> if(j%100 == 0)
> >> cout << j << " ";
> >> }
> >> vec.getItemCount();
> >> #else
> >> vector<int*> vec;
> >> for (int j = 0; j<10000; ++j)
> >> {
> >> vec.push_back(&j);
> >> if(j%100 == 0)
> >> cout << j << " ";
> >> }
> >> vec.size();
> >> #endif
> >>
> >>
> >> }
> >> cout << "\n\n\n\n\n\n\n\n\n\n\n\n";
> >> }
> >>
> >> Here's the output from time:
> >>
> >> with UT_Vector
> >>
> >> 56.76user 1.84system 1:07.21elapsed 87%CPU (0avgtext+0avgdata
> >> 0maxresident)k
> >> 0inputs+0outputs (97major+29012minor)pagefaults 0swaps
> >>
> >> With STL vector<int*>
> >>
> >> 2.20user 0.33system 0:05.06elapsed 49%CPU (0avgtext+0avgdata
> >> 0maxresident)k 0inputs+0outputs (100major+27014minor)pagefaults 0swaps
> >>
> >> In other words, the STL implementation was about 26.25 times faster. When
> >> you take out the output, the change is even more dramatic. The speed
> >> factor increases to about 33.97 times faster for STL.
> >>
> >> There is one potential drawback to the STL - it's pretty big. The STL
> >> implementation of this simple program was 71k, or 72% larger. However,
> >> this is not that much of a size increase, and AbiWord has room to
> >> spare. We are the smallest word processor I have ever seen, and can
> >> afford a few hundred k.
> >>
> >> I realize that free software in general has been unfriendly to c++, and
> >> it's advanced features especially. But in the face of that kind of speed
> >> difference, I can't see not at least considering a change.
> >>
> >>
> >> sam th
> >> sam@uchicago.edu
> >> http://sam.rh.uchicago.edu
> >>
> >> And yes, I do know that premature optimization is the root of all evil.
> >> ------------ Output from gpg ------------
> >> gpg: Good signature from "Sam Tobin-Hochstadt <sytobinh@uchicago.edu>"
> >>
> >>
> >>
>
>
> Eric W. Sink, Software Craftsman
> SourceGear Corporation
> eric@sourcegear.com
>
>
>
>
>
This archive was generated by hypermail 2b25 : Sun Jun 04 2000 - 14:46:57 CDT