Topic: XTL implementation (was STL Template collections are useless in a large project)
Author: marcsh@corel.ca (Marc Sherman)
Date: 1997/09/30 Raw View
In article <3430444b.10657554@news.apk.net>, steagall@deltalogic.com
(Bob Steagall) wrote:
>You should have a look at the XTL whitepaper, which describes how our
>standard library container design pattern eliminates code bloat. It's at
>
> http://www.deltalogic.com/xtlwhite.htm and
> http://www.deltalogic.com/xtleii.htm
Do you have any comparisons of executable size of "typical" STL client
apps compiled with a traditional STL implementation (such as SGI's) vs.
XTL?
It seems that this kind of implementation technique would be very useful
to reduce code bloat in STL clients. Could such an implementation be
considered conforming to the draft standard?
- Marc
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: steagall@deltalogic.com (Bob Steagall)
Date: 1997/10/01 Raw View
On 30 Sep 97 15:52:57 GMT, marcsh@corel.ca (Marc Sherman) wrote:
> In article <3430444b.10657554@news.apk.net>, steagall@deltalogic.com
> (Bob Steagall) wrote:
> >You should have a look at the XTL whitepaper, which describes how our
> >standard library container design pattern eliminates code bloat. It's at
> >
> > http://www.deltalogic.com/xtlwhite.htm and
> > http://www.deltalogic.com/xtleii.htm
>
> Do you have any comparisons of executable size of "typical" STL client
> apps compiled with a traditional STL implementation (such as SGI's) vs.
> XTL?
Well, we have anecdotal evidence from our customers. It's very hard to say
what "typical" is.
As you would expect, the amount of code reduction depends on the
application. The more use a program makes of different types of standard
library containers, the more benefit you will see from the XTL container
design idiom.
For example, one of our customers has described an application that only
used maps. The XTL version (linked statically) was slightly larger in this
case (234k for XTL vs. 232k for VC++ STL), but he reports that XTL maps
gave him better performance than those supplied by VC++, and that he found
the XTL map interface extensions to be particularly useful in his work.
OTOH, another customer of ours has a medium-scale VC++ application
(~75kloc) that uses many different types of maps and lists (as well as
strings, iostreams, and our regular expression classes). He reports that
compiling with XTL, and statically linking to it, results in a 50%
reduction in the size of his executable. When he dynamically links to XTL,
he sees another ~20% reduction in executable size. He also reports that,
with either type of linking, his application runs faster than with the VC++
implementation. However, he has never quantified "faster", so I can't
quote a figure.
> It seems that this kind of implementation technique would be very useful
> to reduce code bloat in STL clients. Could such an implementation be
> considered conforming to the draft standard?
I may be mistaken, but a strict reading of 17.3.3.1 would seem to indicate
that the XTL implementation technique is not strictly conforming. By its
very nature, the idiom creates an interface that is a superset of the
standard interface. Perhaps the committee could consider relaxing the
language of this clause to sanction alternate container design idioms.
Our thinking with XTL is to provide at least the public and protected
interface specified by the standard, as well as things that clearly make
life easier. We have therefore added a number of extensions to our
allocators, containers, strings, and iostreams classes, and included many
additional classes and functions. However, our customers don't seem to
mind because XTL lets them get things done that they could not do otherwise
(with the standard library).
--Bob
====================================================================
Bob Steagall steagall@deltalogic.com
DeltaLogic, Inc. http://www.deltalogic.com
1537 Kew Road Voice (216) 321-8200
Cleveland Hts, OH 44118-1204 Fax (216) 321-6976
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Kevin Jacobs <jacobs@darwin.mhmc.CWRU.Edu>
Date: 1997/10/01 Raw View
Marc Sherman <marcsh@corel.ca> wrote:
> In article <3430444b.10657554@news.apk.net>, steagall@deltalogic.com
> (Bob Steagall) wrote:
> >You should have a look at the XTL whitepaper, which describes how our
> >standard library container design pattern eliminates code bloat. It's at
> >
> > http://www.deltalogic.com/xtlwhite.htm and
> > http://www.deltalogic.com/xtleii.htm
> Do you have any comparisons of executable size of "typical" STL client
> apps compiled with a traditional STL implementation (such as SGI's) vs.
> XTL?
I'm working on this. We've had XTL for about a month and all of our Unix
based code works with it wonderfully. The same cannot be said for
Microsoft's implementation (just try creating list<list<int>::iterator> and
watch it crash and burn). If there is interest, I'll post results with the
various compilers we use against the various standard libraries. Our
applications perform large scale genetic analysis and make heavy use of
standard containers and some algorithms.
> It seems that this kind of implementation technique would be very useful
> to reduce code bloat in STL clients. Could such an implementation be
> considered conforming to the draft standard?
Of course. Several vendors, such as Kuck and Associates use similar ideas
in their KAI C++ standard library, except not nearly to the extent of XTL.
-Kevin Jacobs, who is tired of people grumping about the standard library
based on experience with inferior compilers and implementations.
Note: I have no stake in either XTL or KAI C++. I am just an extremely
happy user of both fine products.
--
-----------> Kevin Jacobs <-----------|-------> (216) 778-8487 <--------
S.A.G.E. Project Technical Coordinator | Department of Epidemiology
& System Administrator | & Biostatistics
Internet E-mail: jacobs@darwin.cwru.edu | Case Western Reserve University
----------------------------------------------------------------------------
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Mike Giroux <mgiroux@icon.com>
Date: 1997/10/01 Raw View
Marc Sherman wrote:
> In article <3430444b.10657554@news.apk.net>, steagall@deltalogic.com
> (Bob Steagall) wrote:
> >You should have a look at the XTL whitepaper, which describes how our
> >standard library container design pattern eliminates code bloat. It's at
> >
> > http://www.deltalogic.com/xtlwhite.htm and
> > http://www.deltalogic.com/xtleii.htm
>
> Do you have any comparisons of executable size of "typical" STL client
> apps compiled with a traditional STL implementation (such as SGI's) vs.
> XTL?
According to their webpage, XTL lives in a DLL, and most of the code is accessed
from that DLL, so I'd guess the code size gain is substantial. I'm not so sure
about the performance, though...
On the bad news side, also from their webpage,
> XTL Availability
>
> XTL 1.04 is available for Borland C++ 5.00, 5.01, 5.02, and C++ Builder,
> as well as Microsoft Visual C++ 4.2, 5.0,
> and 5.0a. Support for other Win32 C++ compilers will be added shortly as demand
> dictates.
I guess that means that XTL doesn't compare at all with STL, on any non-Win32
platform :(. It would be nice if a shared library version for Solaris and a few
other Unix flavours was available...
It might also be nice to have some idea about what the price of this library
is... STL does seem to have a certain cost advantage... :)
--
Mike Giroux
mgiroux@icon.com (work)
rmgiroux@worldnet.att.net (home)
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: paul@ra.avid.com (Paul Miller)
Date: 1997/10/01 Raw View
steagall@deltalogic.com (Bob Steagall) writes:
>> Do you have any comparisons of executable size of "typical" STL client
>> apps compiled with a traditional STL implementation (such as SGI's) vs.
>> XTL?
>Well, we have anecdotal evidence from our customers. It's very hard to say
>what "typical" is.
We looked at it briefly but were immediately turned off by the lack of
UNIX support.
On the other hand, using the SGI STL, after stripping usually results
in pretty small binaries.
--
Paul T. Miller | paul@elastic.avid.com
Principal Software Engineer | Opinions expressed here are my own.
Elastic Reality - a division of Avid Technology, Inc.
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: steagall@deltalogic.com (Bob Steagall)
Date: 1997/10/01 Raw View
On 01 Oct 97 14:33:09 GMT, paul@ra.avid.com (Paul Miller) wrote:
> We looked at it briefly but were immediately turned off by the lack of
> UNIX support.
We expect to support KAI C++ (on Solaris at first) by the end of the year.
We'll add platforms and compilers as we can afford them :-)
> On the other hand, using the SGI STL, after stripping usually results
> in pretty small binaries.
As you would expect, the savings in code size is highly dependent on your
application. For a list<int> with Borland C++, approximately 85% of the
object code is type independent and resides in list_engine. About 10% is
dependent solely on the element type (int) and resides in basic_list<int>.
The remainder is dependent on both the element type and the allocator and
resides in list<int>. If you need a list<int> and a list<long> in the same
application, then you'll save at least the size of the list_engine. If you
only need list<int>, then you won't see any size savings.
--Bob
====================================================================
Bob Steagall steagall@deltalogic.com
DeltaLogic, Inc. http://www.deltalogic.com
1537 Kew Road Voice (216) 321-8200
Cleveland Hts, OH 44118-1204 Fax (216) 321-6976
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: steagall@deltalogic.com (Bob Steagall)
Date: 1997/10/01 Raw View
On 01 Oct 97 05:14:59 GMT, in comp.std.c++ you wrote:
> According to their webpage, XTL lives in a DLL, and most of the code is accessed
> from that DLL, so I'd guess the code size gain is substantial. I'm not so sure
> about the performance, though...
You have your choice of linking to static or dynamic libraries.
> I guess that means that XTL doesn't compare at all with STL, on any non-Win32
> platform :(. It would be nice if a shared library version for Solaris and a few
> other Unix flavours was available...
We expect (knock on wood :-) to have a Solaris port with KAI C++ ready by
the end of the year. With all the good things I hear about KAI C++, I
believe porting to other Unixes should go very quickly once the initial
port is finished.
> It might also be nice to have some idea about what the price of this library
> is...
I've updated the website to reflect the prices for commercial and academic
licenses (http://www.deltalogic.com/products.htm).
> STL does seem to have a certain cost advantage... :)
It's hard to beat free ;-) However, we try to by including not only the
containers and algorithms, but also iostreams, locales, synchronization
types, threads, callbacks, *very* extended strings, regular expressions,
and various helpful utility types and functions.
--Bob
====================================================================
Bob Steagall steagall@deltalogic.com
DeltaLogic, Inc. http://www.deltalogic.com
1537 Kew Road Voice (216) 321-8200
Cleveland Hts, OH 44118-1204 Fax (216) 321-6976
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]