Subject: Re: Why We Should Use the STL (fwd)
From: Eric W. Sink (eric@sourcegear.com)
Date: Sun Jun 04 2000 - 14:36:28 CDT
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:32:38 CDT