Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

P. J. Plauger's current code is likely as fast as it can be

29 views
Skip to first unread message

Peter Olcott

unread,
Jan 18, 2002, 4:22:54 PM1/18/02
to
With his latest memory management methods plus
taking the benefit of COW strings into the benchmarking
process, plus making the code as small as possible,
P. J. Plauger's current code would likely at least
equal any other code under these same conditions,
including STLport and FastString.

*** NOTE *** This message supercedes any prior
statements made my me.
--
Seeking Truth requires one to abandon all assumptions.

tom_usenet

unread,
Jan 18, 2002, 5:11:27 PM1/18/02
to

And so we can lay it all to rest - hooray! I should point out that PJP
uses the Small String Optimisation on his current implementation, not
COW. They are different and in fact orthogonal strategies - they can
be combined.

e.g. Alexandrescu's flex_string is very configurable:

typedef flex_string<
char,
std::char_traits<char>,
std::allocator<char>,
SmallStringOpt<char, 5,
CowString<char, AllocatorStringStorage<char,
std::allocator<char> > > >
> String;

Here we have a string utilising the small string optimisation and COW
that uses std::allocator for heap memory allocation.

http://www.cuj.com/experts/1906/alexandr.htm?topic=experts

Tom

Peter Olcott

unread,
Jan 18, 2002, 5:17:58 PM1/18/02
to
> And so we can lay it all to rest - hooray! I should point out that PJP
> uses the Small String Optimisation on his current implementation, not
> COW. They are different and in fact orthogonal strategies - they can
> be combined.

Is this still a form of reference counting ?

> e.g. Alexandrescu's flex_string is very configurable:

> Here we have a string utilising the small string optimisation and COW
> that uses std::allocator for heap memory allocation.
>
> http://www.cuj.com/experts/1906/alexandr.htm?topic=experts
>
> Tom

I just read this article, and downloaded the code.


tom_usenet

unread,
Jan 18, 2002, 9:38:49 PM1/18/02
to
On Fri, 18 Jan 2002 22:17:58 GMT, "Peter Olcott"
<olc...@worldnet.att.net> wrote:

>> And so we can lay it all to rest - hooray! I should point out that PJP
>> uses the Small String Optimisation on his current implementation, not
>> COW. They are different and in fact orthogonal strategies - they can
>> be combined.
>
>Is this still a form of reference counting ?

Nope. It is simply a matter of embedding an array in the string that
can be used to hold small strings, typically up to 16 or 32 bytes,
without any memory allocation. This gives very fast construction for
small strings, since there is no memory allocation to do, but slows
everything else down due to the extra book-keeping required.

>
>> e.g. Alexandrescu's flex_string is very configurable:
>> Here we have a string utilising the small string optimisation and COW
>> that uses std::allocator for heap memory allocation.
>>
>> http://www.cuj.com/experts/1906/alexandr.htm?topic=experts
>>
>> Tom
>
>I just read this article, and downloaded the code.

The SSO is explained in the article.

Tom

Eugene Kuznetsov

unread,
Jan 19, 2002, 12:17:20 AM1/19/02
to
Peter Olcott wrote:

> *** NOTE *** This message supercedes any prior
> statements made my me.

'My opinions may have changed, but not the fact that I'm right'
:)

Mike Hewson

unread,
Jan 19, 2002, 2:46:24 AM1/19/02
to
"Eugene Kuznetsov" <di...@euro.ru> wrote in message
news:3c49...@news1.abac.com...

Maybe he's just found out who he's been bagging. From
ISO/IEC 14882:1998(E):

<quote>

1.10 Acknowledgments [intro.ack]
1 The C++ programming language as described in this
International Standard is based on the language as
described in Chapter R (Reference Manual) of Stroustrup: The
C++ Programming Language (second edition,
Addison-Wesley Publishing Company, ISBN 0- 201- 53992- 6,
copyright © 1991 AT&T). That, in
turn, is based on the C programming language as described in
Appendix A of Kernighan and Ritchie: The C
Programming Language (Prentice-Hall, 1978, ISBN 0- 13-
110163- 3, copyright © 1978 AT&T).
2 Portions of the library clauses of this International
Standard are based on work by P.J. Plauger, which was
published as The Draft Standard C++ Library (Prentice-Hall,
ISBN 0- 13- 117003- 1, copyright © 1995
P.J. Plauger).
3 All rights in these originals are reserved.

</quote>

That's not bad company to be finding one's name in!
( and....no....I'm not sucking up to Mr. Plauger )

--

Cheers.

--
Hewson::Mike
"I have made this letter longer than usual because I lack
the time to make it shorter."
- Blaise Pascal


Attila Feher

unread,
Jan 21, 2002, 8:04:33 AM1/21/02
to

Excuse me for asking: but who are you to make _any_ statements about
this library _or_ Mr. Plauger? Self confidence is a nice thing, up to a
certain level, where it starts to collide with respect. You know you,
as someone, who just 2 weeks ago had no idea about what is COW and still
had no idea just a day back what is SSO... How to put it polite? At
least start your "statements" with: IMHO (In My Humble Oppinion)...
Sigh.

A

Stephen Howe

unread,
Jan 21, 2002, 8:29:47 AM1/21/02
to
> Is this still a form of reference counting ?

If you don't even know that then your opinions on Plauger's code are of no
substance.

Stephen Howe


Peter Olcott

unread,
Jan 21, 2002, 9:12:04 AM1/21/02
to
> If you don't even know that then your opinions on Plauger's code are of no
> substance.
>
> Stephen Howe
>
>
He argued vehemently for including reference counted strings
in the analysis. If his code does not have reference counting,
then why else would he do this? Its not my mere opinions
that count, its the concrete results of my benchmarks that
count.


Peter Olcott

unread,
Jan 21, 2002, 9:14:11 AM1/21/02
to

Isn't the whole source of everyone's problem with my
opinions, that they are not humble, but, brazen?


Jon Bills

unread,
Jan 21, 2002, 9:20:29 AM1/21/02
to
"Peter Olcott" <olc...@worldnet.att.net> wrote in message
news:TmV28.112148$fe1.2...@bgtnsc06-news.ops.worldnet.att.net...

[snip]

> Isn't the whole source of everyone's problem with my
> opinions, that they are not humble, but, brazen?

No. It's that you state opinion as fact, and what you state as fact
is ill researched and often wrong.


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Attila Feher

unread,
Jan 21, 2002, 9:21:07 AM1/21/02
to
Peter Olcott wrote:
[SNIP]

> Isn't the whole source of everyone's problem with my
> opinions, that they are not humble, but, brazen?

The problem is that you show up yourself as an authoritative,
non-questionable source of facts, while you are a humble (as I am)
source of _opinions_. And you try to sell them as unquestionable and
important facts. Which they are not. Just look into how many important
things you did not know about the topic where you try to sell yourself
as an expert!

A

Attila Feher

unread,
Jan 21, 2002, 9:26:16 AM1/21/02
to

_Your_ benchmarks! That was an _important_ point! You simply disregard
benchmarks made by others, which show up the weaknesses of your code
etc. I dunno what do you think who are you, but please remember: your
benchmarks show up behaviour, what you thought it is important to test.
And those are only a finite set of infinite possible applications! A
single threaded benchmark for string copy-extensive will scenario will
certainly bring up a COW implementation as the winner. The same one
under MT environment and enough threads creating and destroying strings
will be slower than a deep copy implementation and on a 4 CPU SMP it may
even be 25% in speed than a deep copy one, since it the colliding
creation and destroying of mutexes will actually stop all but one CPU
from working...

Anyways, I have made again the error of trying to talk to you...

Attila

Peter Olcott

unread,
Jan 21, 2002, 9:58:43 AM1/21/02
to
> > He argued vehemently for including reference counted strings
> > in the analysis. If his code does not have reference counting,
> > then why else would he do this? Its not my mere opinions
> > that count, its the concrete results of my benchmarks that
> > count.
>
> _Your_ benchmarks! That was an _important_ point! You simply disregard
> benchmarks made by others, which show up the weaknesses of your code

(1) There were no benchmarks of others presented.
(2) The weaknesses of my code have been corrected to the best
of my knowledge. This code has been extensively peer reviewed.

> etc. I dunno what do you think who are you, but please remember: your
> benchmarks show up behaviour, what you thought it is important to test.

Which still forms a reasonable measure of the relative performance
of the subset of those most fundamental features that I implemented.
P. J. Plauger thought it sufficient reason to modify his code to
attempt to beat these benchmarks. To the best of my knowledge
(I have never seen any proof) he beat my code by 1.3%.
(OnePointThreePercent). Also posted results where I beat his
latest production code by 2.44 fold, that's 144% faster, more than
double the speed. This difference is nearly inconsequential compared
to earlier benchmark results on his older version. The difference is now
so small, that the added benefit of COW strings would wipe
out this difference altogether, hence the title of this thread.

Peter Olcott

unread,
Jan 21, 2002, 9:58:44 AM1/21/02
to
> > Isn't the whole source of everyone's problem with my
> > opinions, that they are not humble, but, brazen?
>
> No. It's that you state opinion as fact, and what you state as fact
> is ill researched and often wrong.

Most often (if not always) I state my opinions qualified
with "I think that", assertions that I state as fact generally
take the form of "I know this because".


Peter Olcott

unread,
Jan 21, 2002, 9:58:45 AM1/21/02
to
> The problem is that you show up yourself as an authoritative,
> non-questionable source of facts, while you are a humble (as I am)
> source of _opinions_. And you try to sell them as unquestionable and
> important facts. Which they are not. Just look into how many important
> things you did not know about the topic where you try to sell yourself
> as an expert!
>
> A

I have two bachelor's degrees in computers. MIS and CS.
I have been a professional programmer since 1984. Although
I am relatively new to C++, I have been programming in
C since K&R was the official standard, in my case since
1986. Thus some of what I say has a very substantial basis.
Other things that I say may rely upon information that
I received from others that eventually proves to be unreliable.
I resolve to take more care in labeling my hypotheses as
such.


Attila Feher

unread,
Jan 21, 2002, 11:55:15 AM1/21/02
to
Peter Olcott wrote:
>
> > > He argued vehemently for including reference counted strings
> > > in the analysis. If his code does not have reference counting,
> > > then why else would he do this? Its not my mere opinions
> > > that count, its the concrete results of my benchmarks that
> > > count.
> >
> > _Your_ benchmarks! That was an _important_ point! You simply disregard
> > benchmarks made by others, which show up the weaknesses of your code
>
> (1) There were no benchmarks of others presented.

I know you pretend that, but just look again into
comp.lang.c++.moderated threads of yours!

> (2) The weaknesses of my code have been corrected to the best
> of my knowledge. This code has been extensively peer reviewed.

:-)))

> > etc. I dunno what do you think who are you, but please remember: your
> > benchmarks show up behaviour, what you thought it is important to test.
>
> Which still forms a reasonable measure of the relative performance
> of the subset of those most fundamental features that I implemented.

I see. Who has said that those are the most fundamental features? :-))
You.

> P. J. Plauger thought it sufficient reason to modify his code to
> attempt to beat these benchmarks. To the best of my knowledge
> (I have never seen any proof) he beat my code by 1.3%.
> (OnePointThreePercent).

> Also posted results where I beat his
> latest production code by 2.44 fold, that's 144% faster, more than
> double the speed.

With a fake string representation supporting no traits... It is only my
feeling or I really keep repeating myself with no effect whatsoever?
:-)))

> This difference is nearly inconsequential compared
> to earlier benchmark results on his older version. The difference is now
> so small, that the added benefit of COW strings would wipe
> out this difference altogether, hence the title of this thread.

Wow. I still don't give a rats behind for your "expert opinion" stated
as fact. :-) I saw already what you know and I saw that you still
cannot really see the difference between a non-template stuff premature
optimized for PODs and a full-blown template. And you know, unlike you,
I have also read what other people wrote to you... and taken them into
consideration.

And the thread says: *PLONK*

Attila

Attila Feher

unread,
Jan 21, 2002, 11:58:15 AM1/21/02
to
Peter Olcott wrote:
>
> > The problem is that you show up yourself as an authoritative,
> > non-questionable source of facts, while you are a humble (as I am)
> > source of _opinions_. And you try to sell them as unquestionable and
> > important facts. Which they are not. Just look into how many important
> > things you did not know about the topic where you try to sell yourself
> > as an expert!
> >
> > A
>
> I have two bachelor's degrees in computers. MIS and CS.
> I have been a professional programmer since 1984.

And my disck is... :-))) Who cares! I know people with 5 Masters
degree who could not connect two wires together.

> Although
> I am relatively new to C++, I have been programming in
> C since K&R was the official standard, in my case since
> 1986. Thus some of what I say has a very substantial basis.

Uh oh. Now I see why are you so ignorant about the differences between
C and C++ way of design and coding. Your code is excellent, from the
narrowed down perspective of a C programmer.

> Other things that I say may rely upon information that
> I received from others that eventually proves to be unreliable.

Wow. But you are reliable. And modest. :-)) Oh boy.

> I resolve to take more care in labeling my hypotheses as
> such.

I see. Still, IMHO is veery much missing from there. :-))) Believe me
or not. :-)))

Bye-bye,

Attila

Adam Peterson

unread,
Jan 21, 2002, 12:38:58 PM1/21/02
to
> It is only my
> feeling or I really keep repeating myself with no effect whatsoever?
> :-)))

Well, it can't be only you, because I'm getting a similar feeling. It took
me about eight times of saying the same thing over and over each post before
he understood the exception issue I first jumped into the thread with. My
experience has been much the same since.

Adam Peterson


LShaping

unread,
Jan 21, 2002, 12:42:37 PM1/21/02
to
"Peter Olcott" <olc...@worldnet.att.net> wrote:

>> The problem is that you show up yourself as an authoritative,
>> non-questionable source of facts, while you are a humble (as I am)

>> source of opinions. And you try to sell them as unquestionable and


>> important facts. Which they are not. Just look into how many important
>> things you did not know about the topic where you try to sell yourself
>> as an expert!
>> A

>I have two bachelor's degrees in computers. MIS and CS.

>I have been a professional programmer since 1984. <snip>

But Attila Feher and Jon Bills both have PhDs in trolling.

Attila Feher

unread,
Jan 21, 2002, 12:56:23 PM1/21/02
to
LShaping wrote:
[SNIP]

> But Attila Feher and Jon Bills both have PhDs in trolling.

Correction: troll detection. :-) We won't take your role away for all
the money in the world. :-))))

Attila

Peter Olcott

unread,
Jan 21, 2002, 1:04:57 PM1/21/02
to
> > > _Your_ benchmarks! That was an _important_ point! You simply disregard
> > > benchmarks made by others, which show up the weaknesses of your code
> >
> > (1) There were no benchmarks of others presented.
>
> I know you pretend that, but just look again into
> comp.lang.c++.moderated threads of yours!
>
I recall nothing else that was presented that could be construed to
be any form of a benchmark. There were many comments, but,
no benchmarks.

> > (2) The weaknesses of my code have been corrected to the best
> > of my knowledge. This code has been extensively peer reviewed.
>
> :-)))
>
> > > etc. I dunno what do you think who are you, but please remember: your
> > > benchmarks show up behaviour, what you thought it is important to test.
> >
> > Which still forms a reasonable measure of the relative performance
> > of the subset of those most fundamental features that I implemented.
>
> I see. Who has said that those are the most fundamental features? :-))
> You.

Since I test: (1) Data Movement (2) Memory Allocation (3)
Construction and (4) Relational Comparison, and all other
operations require one or more aspects of these operations,
the fact that these are most fundamental is self-evident.
Provide a counter-example that does not require any of these
features, and is very frequently used, otherwise I rest my case.

> > P. J. Plauger thought it sufficient reason to modify his code to
> > attempt to beat these benchmarks. To the best of my knowledge
> > (I have never seen any proof) he beat my code by 1.3%.
> > (OnePointThreePercent).
>
> > Also posted results where I beat his
> > latest production code by 2.44 fold, that's 144% faster, more than
> > double the speed.
>
> With a fake string representation supporting no traits... It is only my
> feeling or I really keep repeating myself with no effect whatsoever?

It is not at all fake. I read the material in Stroustrup about traits
and still do not understand your objection. It looks like your
objection is that I did not implement FastString as a template.
This would be an irrelevant implementation detail.

> Wow. I still don't give a rats behind for your "expert opinion" stated
> as fact. :-) I saw already what you know and I saw that you still

Here are the facts. I currently beat him by as much as 167-fold on his
older code. On his newest code I beat him by as much as 8.5 fold.

Peter Olcott

unread,
Jan 21, 2002, 1:04:58 PM1/21/02
to
> > Although
> > I am relatively new to C++, I have been programming in
> > C since K&R was the official standard, in my case since
> > 1986. Thus some of what I say has a very substantial basis.
>
> Uh oh. Now I see why are you so ignorant about the differences between
> C and C++ way of design and coding. Your code is excellent, from the
> narrowed down perspective of a C programmer.

Finally someone says something nice about this code.
I also propose that it can be extended to the full standard.
Apparently P. J. Plauger has already proven this point.

> Attila


Peter Olcott

unread,
Jan 21, 2002, 1:08:16 PM1/21/02
to

Thanks for your support. I would not be quite this
harsh in my assessment of Attila, and I don't know
Jon.


Jon Bills

unread,
Jan 21, 2002, 1:09:17 PM1/21/02
to
"Attila Feher" <Attila...@lmf.ericsson.se> wrote in message
news:3C4C5647...@lmf.ericsson.se...


What Queeg... sorry, LShaping seems to forget is that anyone can go
and search the Google archives to see what sort of posts he submits.
A quick search reveals him to be a classic Usenet fuckwit.

Jon.

Peter Olcott

unread,
Jan 21, 2002, 1:09:42 PM1/21/02
to
> Well, it can't be only you, because I'm getting a similar feeling. It took
> me about eight times of saying the same thing over and over each post before
> he understood the exception issue I first jumped into the thread with. My
> experience has been much the same since.
>
> Adam Peterson
>
>
It is not the same things that are being said. It is
a subtle mathematical interpolation on the truth.


Adam Peterson

unread,
Jan 21, 2002, 1:15:15 PM1/21/02
to
> It is not the same things that are being said. It is
> a subtle mathematical interpolation on the truth.

Explain.


tom_usenet

unread,
Jan 21, 2002, 1:24:39 PM1/21/02
to
On Mon, 21 Jan 2002 14:58:45 GMT, "Peter Olcott"
<olc...@worldnet.att.net> wrote:

>I am relatively new to C++, I have been programming in
>C since K&R was the official standard, in my case since
>1986.

K&R C was never an official standard AFAIK, rather an ad hoc standard.
ANSI C89, ISO C90 and ANSI/ISO C99 are the only official C standards.
Not being an expert on C standardisation, I might be wrong.

>Thus some of what I say has a very substantial basis.

Some. Perhaps some. But you have made very few intelligent points in
hundreds of posts and seem unable to grasp the intelligent points of
others.

>Other things that I say may rely upon information that
>I received from others that eventually proves to be unreliable.

You appear to have a complete inability to judge the information that
others give you. You disregard correct information, and, according to
what you are now saying, you rely upon incorrect information. This is
hardly indicative of critical thinking.

Tom

Pete Becker

unread,
Jan 21, 2002, 1:26:58 PM1/21/02
to
Peter Olcott wrote:
>
> I also propose that it can be extended to the full standard.
> Apparently P. J. Plauger has already proven this point.
>

No, he showed that the Dinkumware code can be cut back to match the
performance of yours. That says nothing about whether your code can be
extended to conform to the standard.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

ignore subthread, LShaping

unread,
Jan 21, 2002, 1:28:45 PM1/21/02
to
no comment

LShaping

unread,
Jan 21, 2002, 1:32:53 PM1/21/02
to
"Peter Olcott" wrote:
>LShaping wrote:

>>>>><snip>

>> But Attila Feher and Jon Bills both have PhDs in trolling.

>Thanks for your support. I would not be quite this

>harsh in my assessment ...

How about Masters?

Arnold Hendriks

unread,
Jan 21, 2002, 1:46:45 PM1/21/02
to
In comp.lang.c++ Peter Olcott <olc...@worldnet.att.net> wrote:
> Since I test: (1) Data Movement (2) Memory Allocation (3)
> Construction and (4) Relational Comparison, and all other
> operations require one or more aspects of these operations,
> the fact that these are most fundamental is self-evident.
> Provide a counter-example that does not require any of these
> features, and is very frequently used, otherwise I rest my case.
It is not enough to test those four indepedently, because they may
influence each other. And every operation is data movement in some way.

Find a real-world application, or a subset thereof, in which your string
class outperforms any other string class. As long as you cannot even come
close to such a benchmark, all your assumptions about cache behaviour won't
be worth much. If your goal was to create a generic usable string class,
that other people should actually use, you'd have to come up with real
proof that it outperforms other classes, not benchmarks.

I sincerely doubt that any third party, after having seen the discussions
in c.l.c++ about your string class, would even consider using it. There
have been too many refutations of your claims, which were made by people
who have practical experience with optimizing real world c++ code. You
dismissed all those refutations on basis of your own assumptions. You have
yet to show any real data that those concerns are unfounded.

The burden of proof is on you if you really want to provide a faster string
class for general usage.

--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/

Peter Olcott

unread,
Jan 21, 2002, 4:25:35 PM1/21/02
to

It proves that code matching the performance of
my code, that also matches the standard can be
achieved. This is very close to the original purpose
of my investigation, to derive the speed of the fastest full
std::string. I set the speed limit, and P.J. provided
the conforming implementation, thus fully conforming
code can be at least as fast as FastString, and several
hundred fold faster than its earlier versions. As a side note
the earlier version of the Borland std::string was only
about half as fast as the earlier version of the MSVC++
6.0 std::string.


Peter Olcott

unread,
Jan 21, 2002, 4:31:33 PM1/21/02
to
> >I am relatively new to C++, I have been programming in
> >C since K&R was the official standard, in my case since
> >1986.
>
> K&R C was never an official standard AFAIK, rather an ad hoc standard.

Not quite as weak as Ad Hoc implies nor as strong as
the term "official" that I used. It was the defacto standard.

> ANSI C89, ISO C90 and ANSI/ISO C99 are the only official C standards.
> Not being an expert on C standardisation, I might be wrong.
>
> >Thus some of what I say has a very substantial basis.

In refutiong my use of the word "official" you provide more than
a mere substantial basis, you provide a sufficient basis.

> Some. Perhaps some. But you have made very few intelligent points in
> hundreds of posts and seem unable to grasp the intelligent points of
> others.

There are two reasons for this.

(1) I don't share much of the common terminology, thus
it is not the ideas that I don't understand it is the attachment
of these ideas to their corresponding terms, that I have yet
to memorize.

(2) There may in some cases be subtleties that I am referring
to that are not apprarent to others.

> >Other things that I say may rely upon information that
> >I received from others that eventually proves to be unreliable.
>
> You appear to have a complete inability to judge the information that
> others give you. You disregard correct information, and, according to
> what you are now saying, you rely upon incorrect information. This is
> hardly indicative of critical thinking.
>
> Tom

You open youself up to losing all of your personal property
to libel cases, by calling people liars with no sufficient basis.


Pete Becker

unread,
Jan 21, 2002, 4:38:07 PM1/21/02
to
Peter Olcott wrote:
>
> > > I also propose that it can be extended to the full standard.
> > > Apparently P. J. Plauger has already proven this point.
> > >
> >
> > No, he showed that the Dinkumware code can be cut back to match the
> > performance of yours. That says nothing about whether your code can be
> > extended to conform to the standard.
> >
> > --
> > Pete Becker
> > Dinkumware, Ltd. (http://www.dinkumware.com)
>
> It proves that code matching the performance of
> my code, that also matches the standard can be
> achieved. This is very close to the original purpose
> of my investigation, to derive the speed of the fastest full
> std::string. I set the speed limit, and P.J. provided
> the conforming implementation, thus fully conforming
> code can be at least as fast as FastString, and several
> hundred fold faster than its earlier versions.

That is a completely different statement from the one I replied to,
which was that your code can be extended to the full standard. Unless,
of course, by "extended" you mean "completely rewritten," in which case
it's a completely meaningless statement. Once again: the fact that some
other code is as fast as yours says nothing about the extensibility of
your code.

David Schwartz

unread,
Jan 21, 2002, 4:59:59 PM1/21/02
to
Peter Olcott wrote:

> thus fully conforming
> code can be at least as fast as FastString, and several
> hundred fold faster than its earlier versions.

As measured by a benchmark that nobody but you thinks measures anything
important.

DS

Peter Olcott

unread,
Jan 21, 2002, 5:49:37 PM1/21/02
to
...

I might say that Attila tends to take things a little too personally.


Peter Olcott

unread,
Jan 21, 2002, 6:01:16 PM1/21/02
to
> > It proves that code matching the performance of
> > my code, that also matches the standard can be
> > achieved. This is very close to the original purpose
> > of my investigation, to derive the speed of the fastest full
> > std::string. I set the speed limit, and P.J. provided
> > the conforming implementation, thus fully conforming
> > code can be at least as fast as FastString, and several
> > hundred fold faster than its earlier versions.
>
> That is a completely different statement from the one I replied to,
> which was that your code can be extended to the full standard. Unless,
> of course, by "extended" you mean "completely rewritten," in which case
> it's a completely meaningless statement. Once again: the fact that some
> other code is as fast as yours says nothing about the extensibility of
> your code.

It would not have to be completely rewritten. The basic
methods would remain intact, and placed into templates.
Since there are few ways to achieve this degree of speed,
the resulting code would have to be quite analogous to
the code that I wrote. Certainly variable names could be
changed, yet little of the fundamental structure could be
altered. It would have to be essentially for the most part
the same execution flow charts, the only difference
being how these are decomposed into units of execution,
and how they are implemented, as functions, templates
et cetera.


Peter Olcott

unread,
Jan 21, 2002, 6:03:04 PM1/21/02
to
--
Peter Olcott
Seeking Truth requires one to abandon all assumptions.
http://home.att.net/~olcott/FastString.html
"Adam Peterson" <ah...@email.byu.edu> wrote in message news:a2hlsq$98i$1...@acs2.byu.edu...

> > It is not the same things that are being said. It is
> > a subtle mathematical interpolation on the truth.
>
> Explain.
>
>

You might be repeating the same things over and over,
(or not) while I am continuing to dig a little deeper each
iteration.


Peter Olcott

unread,
Jan 21, 2002, 6:10:12 PM1/21/02
to
> > Since I test: (1) Data Movement (2) Memory Allocation (3)
> > Construction and (4) Relational Comparison, and all other
> > operations require one or more aspects of these operations,
> > the fact that these are most fundamental is self-evident.
> > Provide a counter-example that does not require any of these
> > features, and is very frequently used, otherwise I rest my case.

> It is not enough to test those four indepedently, because they may
> influence each other. And every operation is data movement in some way.

Not every operation is fundamentally data movement.
I contend that the order of my operations will not ever
make any difference to their performance, unlike some
other code that I will politely refrain from mentioning.
I leave it to those whom choose to dispute this claim to
prove otherwise.

> Find a real-world application, or a subset thereof, in which your string
> class outperforms any other string class. As long as you cannot even come
> close to such a benchmark, all your assumptions about cache behaviour won't
> be worth much. If your goal was to create a generic usable string class,
> that other people should actually use, you'd have to come up with real
> proof that it outperforms other classes, not benchmarks.
>
> I sincerely doubt that any third party, after having seen the discussions
> in c.l.c++ about your string class, would even consider using it. There
> have been too many refutations of your claims, which were made by people
> who have practical experience with optimizing real world c++ code. You
> dismissed all those refutations on basis of your own assumptions. You have
> yet to show any real data that those concerns are unfounded.
>
> The burden of proof is on you if you really want to provide a faster string
> class for general usage.

Nope its down to special the purpose usage of cases approximating
the intensity of my benchmarks,m regardless of the order of
operations. Thus making the benchmarks valid, and your above
points moot.


Pete Becker

unread,
Jan 21, 2002, 6:18:51 PM1/21/02
to

That is a completely different statement form the one I replied to,
which was that PJ's posting proved that your code could be extended to
the full standard. I'm sure that you believe that it can be extended.
But misquoting other people doesn't prove that. Doing it does. Put up or
shut up.

Peter Olcott

unread,
Jan 21, 2002, 6:19:05 PM1/21/02
to

P. J. Plauger went to the trouble of testing his code against mine,
on these benchmarks, on two separate occasions. On the latter
occasion he even went through the extraordinary effort of changing
his code in the apparently successful attempt to beat these benchmarks.
(by 1.3%). Also these benchmarks directly resulted in a permanent
change to all future releases of his library. All this can be verified
through Google. I would say that you have been sufficiently refuted.

Since his code is the MSVC++ STL library it forms probably
the most widely distributed STL library available, this latter
comment is an educated guess.


Adam Peterson

unread,
Jan 21, 2002, 6:20:09 PM1/21/02
to
> Not every operation is fundamentally data movement.
> I contend that the order of my operations will not ever
> make any difference to their performance, unlike some
> other code that I will politely refrain from mentioning.
> I leave it to those whom choose to dispute this claim to
> prove otherwise.

You can contend this if you want. It is self-evidently false by many of us,
and the burden of proof is on you that it is true. (A very heavy burden to
bear, by the way.)

I have seen that a counter example is not sufficient to disprove what you
say. When you receive a counter example, very frequently you simply alter
the argument so that the counter example is no longer covered. Well, I for
one can see where this can go, and I don't have time to do this little
dance.

Again, this assertion you make is not proven by you or anyone else, and for
the reasons I have given that you have not addressed (and many of the ones
you have tried to address unsuccessfully) I believe it is false. You must
prove it true. Not me, not Pete Becker, not Bjarne Stroustrup, not Bill
Gates. We have our own problems, and this one is yours.

I have given you this information in an advisory capacity to help you deal
with the deficiencies in your programming and/or reasoning. I do not feel I
have to prove it. You are free to discard it, if you wish. But if you do,
realize that if your goal was convincing me, then you have not succeeded.

<snip>


> > The burden of proof is on you if you really want to provide a faster
string
> > class for general usage.
>
> Nope its down to special the purpose usage of cases approximating
> the intensity of my benchmarks,m regardless of the order of
> operations. Thus making the benchmarks valid, and your above
> points moot.

This last sentence is unfounded. Just because an application approximates
your intensity does not mean it approximates your usage pattern. And the
usage pattern will have subtle and significant impact on performance.
Moreso in code that has veritably never seen main memory and spent virtually
its entire lifetime in cache before being used in a real application.


David Schwartz

unread,
Jan 21, 2002, 7:12:08 PM1/21/02
to
Peter Olcott wrote:

> > Peter Olcott wrote:

> > > thus fully conforming
> > > code can be at least as fast as FastString, and several
> > > hundred fold faster than its earlier versions.

> > As measured by a benchmark that nobody but you thinks measures anything
> > important.

> P. J. Plauger went to the trouble of testing his code against mine,


> on these benchmarks, on two separate occasions.

Only because he felt it was important to expose the false assumptions
in your testing and the erroneous nature of your benchmark. Not because
he felt your testing was so valid and important that he could use it to
improve his string class.

> On the latter
> occasion he even went through the extraordinary effort of changing
> his code in the apparently successful attempt to beat these benchmarks.
> (by 1.3%).

I doubt this was 'extraordinary effort'. But if anything, the end
result of this effort was to prove what he already suspected, which was
that your benchmarks don't measure anything relevant to actual use of a
string class and that they don't show that your string class is better
than his in any meaningful way.

> Also these benchmarks directly resulted in a permanent
> change to all future releases of his library.

I usually can't even look at a significant piece of code for more than
ten minutes without coming up with some changes. That doesn't validate
the original reason for the look.

More than once it suddenly hit me that some piece of code I wrote might
fail to deal with a certain situation correctly. When this happens, I
look at the code to make sure that this won't cause a problem. While I'm
there, I might change any number of things that strike me as suboptimal
at the time. But I may ultimately conclude that the code does handle the
situation I was worried about correctly. The fact that a person thinking
X looks at some codes and makes some changes doesn't mean that X was the
rationale for the changes.

> All this can be verified
> through Google. I would say that you have been sufficiently refuted.

Refuted?! Show me one place where anybody other than you states or
implies that your benchmarks measure anything important. My claim was
that you are the only person who believes your benchmark measures
anything important. I've also listed several times the specific defects
in your testing methodology, primarily that it rewards bloated code by
drowning out cache footprint effects.

DS

Peter Olcott

unread,
Jan 21, 2002, 7:59:17 PM1/21/02
to
> > It would not have to be completely rewritten. The basic
> > methods would remain intact, and placed into templates.
> > Since there are few ways to achieve this degree of speed,
> > the resulting code would have to be quite analogous to
> > the code that I wrote. Certainly variable names could be
> > changed, yet little of the fundamental structure could be
> > altered. It would have to be essentially for the most part
> > the same execution flow charts, the only difference
> > being how these are decomposed into units of execution,
> > and how they are implemented, as functions, templates
> > et cetera.
>
> That is a completely different statement form the one I replied to,
> which was that PJ's posting proved that your code could be extended to
> the full standard. I'm sure that you believe that it can be extended.
> But misquoting other people doesn't prove that. Doing it does. Put up or
> shut up.
>
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)

Are you sure that you really want the direct head to head
competition? I have other higher priority things to accomplish,
and am satisfied with my faster, yet special purpose FastString.


Peter Olcott

unread,
Jan 21, 2002, 8:06:49 PM1/21/02
to
> Only because he felt it was important to expose the false assumptions
> in your testing and the erroneous nature of your benchmark. Not because
> he felt your testing was so valid and important that he could use it to
> improve his string class.

Yet he did not expose any false assumptions, nor, erroneous nature,
therefore you err in your fundamental assessment.

> > On the latter
> > occasion he even went through the extraordinary effort of changing
> > his code in the apparently successful attempt to beat these benchmarks.
> > (by 1.3%).
>
> I doubt this was 'extraordinary effort'. But if anything, the end
> result of this effort was to prove what he already suspected, which was
> that your benchmarks don't measure anything relevant to actual use of a
> string class and that they don't show that your string class is better
> than his in any meaningful way.
>

This baseless assertion might have been made, yet not a trace
of evidence was provided to support it.

> > All this can be verified
> > through Google. I would say that you have been sufficiently refuted.
>
> Refuted?! Show me one place where anybody other than you states or
> implies that your benchmarks measure anything important. My claim was

Of couse P. J. Plauger's words would make every attempt to
refute that validity of my benchmarks, yet his actions prove
otherwise.

> that you are the only person who believes your benchmark measures
> anything important. I've also listed several times the specific defects
> in your testing methodology, primarily that it rewards bloated code by
> drowning out cache footprint effects.
>
> DS

If you want to discuss this last point more in depth, I am willing.
I have already acknowledged that this is the one possibility
of less than ideal accuracy in these benchmarks. I still think
that the consequences of this one possibly valid point are
insufficient, yet, I am willing to explore this issue further.

David Schwartz

unread,
Jan 21, 2002, 8:29:35 PM1/21/02
to
Peter Olcott wrote:

> > Only because he felt it was important to expose the false assumptions
> > in your testing and the erroneous nature of your benchmark. Not because
> > he felt your testing was so valid and important that he could use it to
> > improve his string class.

> Yet he did not expose any false assumptions, nor, erroneous nature,
> therefore you err in your fundamental assessment.

Your logic escapes me. I am saying that his motive in benchmarking his
string class with your benchmark was to show that your benchmark was
erroneous. You respond that he didn't show that your benchmark was
erroneous. True or not, this doesn't refute my point at all.



> > > On the latter
> > > occasion he even went through the extraordinary effort of changing
> > > his code in the apparently successful attempt to beat these benchmarks.
> > > (by 1.3%).

> > I doubt this was 'extraordinary effort'. But if anything, the end
> > result of this effort was to prove what he already suspected, which was
> > that your benchmarks don't measure anything relevant to actual use of a
> > string class and that they don't show that your string class is better
> > than his in any meaningful way.

> This baseless assertion might have been made, yet not a trace
> of evidence was provided to support it.

Again, I'm that this was his motive and the conclusion he drew, and you
respond that it is not a conclusion that he has convinced you of. So you
are trying to establish another person's motives not based upon how they
see things but based upon how you see things. This will not ever succeed
in determining another person's motives.

Suppose you are trying to figure out why a man bought flowers for a
woman he finds pretty. You might say, "he's obviously not buying her
flowers because he's attractive to her, she's so ugly". But if you want
to determine why he bought her flowers, you have to look at how he sees
her, not how you see her.

Remember how we got into this. I said:

> As measured by a benchmark that nobody but you thinks measures anything
> important.

And you replied:

>P. J. Plauger went to the trouble of testing his code against mine,

>on these benchmarks, on two separate occasions. On the latter


>occasion he even went through the extraordinary effort of changing
>his code in the apparently successful attempt to beat these benchmarks.

>(by 1.3%). Also these benchmarks directly resulted in a permanent
>change to all future releases of his library. All this can be verified


>through Google. I would say that you have been sufficiently refuted

So my point is not that what you said above is false but that this
doesn't provide any evidence that your benchmark is valid. You are
trying to say that P. J. Plauger would not have bothered had he not
considered your benchmark valid. I provided an alternate motive. To
refute that motive, you must start with how P. J. Plauger judges things
which you can easily do based upon his posts here.

> > > All this can be verified
> > > through Google. I would say that you have been sufficiently refuted.

> > Refuted?! Show me one place where anybody other than you states or
> > implies that your benchmarks measure anything important. My claim was

> Of couse P. J. Plauger's words would make every attempt to
> refute that validity of my benchmarks, yet his actions prove
> otherwise.

So you maintain that the only reason P. J. Plauger would test his code
against your benchmark was if he felt they accurately measured the speed
of his code? You consider it impossible that he was just curious or just
trying to beat you at your own game or just trying to show how
meaningless your benchmarks are. What an interesting world you live in.



> > that you are the only person who believes your benchmark measures
> > anything important. I've also listed several times the specific defects
> > in your testing methodology, primarily that it rewards bloated code by
> > drowning out cache footprint effects.

> If you want to discuss this last point more in depth, I am willing.


> I have already acknowledged that this is the one possibility
> of less than ideal accuracy in these benchmarks. I still think
> that the consequences of this one possibly valid point are
> insufficient, yet, I am willing to explore this issue further.

So you have some question about the usefulness of your benchmarks? You
don't think P. J. Plauger does too?

DS

Pete Becker

unread,
Jan 21, 2002, 8:52:51 PM1/21/02
to
Peter Olcott wrote:
>
> > > It would not have to be completely rewritten. The basic
> > > methods would remain intact, and placed into templates.
> > > Since there are few ways to achieve this degree of speed,
> > > the resulting code would have to be quite analogous to
> > > the code that I wrote. Certainly variable names could be
> > > changed, yet little of the fundamental structure could be
> > > altered. It would have to be essentially for the most part
> > > the same execution flow charts, the only difference
> > > being how these are decomposed into units of execution,
> > > and how they are implemented, as functions, templates
> > > et cetera.
> >
> > That is a completely different statement form the one I replied to,
> > which was that PJ's posting proved that your code could be extended to
> > the full standard. I'm sure that you believe that it can be extended.
> > But misquoting other people doesn't prove that. Doing it does. Put up or
> > shut up.
> >

Steven Rumbalski

unread,
Jan 21, 2002, 10:10:38 PM1/21/02
to
Peter Olcott wrote:

> David Schwartz wrote:
>> As measured by a benchmark that nobody but you thinks measures anything
>> important.
>
> P. J. Plauger went to the trouble of testing his code against mine,
> on these benchmarks, on two separate occasions. On the latter
> occasion he even went through the extraordinary effort of changing
> his code in the apparently successful attempt to beat these benchmarks.
> (by 1.3%).

Extraordinary effort? He claimed that it took a couple of hours.

> Also these benchmarks directly resulted in a permanent
> change to all future releases of his library.

P.J. Plauger has already refuted your false assertion. It was a comment of
_another poster_ that gave him the idea of changing something.

> All this can be verified
> through Google.

Exactly, that's why you should stick to the facts.

> I would say that you have been sufficiently refuted.

Hardly.

Steven Rumbalski


Peter Olcott

unread,
Jan 21, 2002, 10:22:36 PM1/21/02
to
> > > That is a completely different statement form the one I replied to,
> > > which was that PJ's posting proved that your code could be extended to
> > > the full standard. I'm sure that you believe that it can be extended.
> > > But misquoting other people doesn't prove that. Doing it does. Put up or
> > > shut up.
> > >
> > Are you sure that you really want the direct head to head
> > competition? I have other higher priority things to accomplish,
> > and am satisfied with my faster, yet special purpose FastString.
>
> Put up or shut up.
>
Okay then I may choose to acquire the resources of
some world class partner's with the sole purpose
of providing the best possible STL available. This
will be a commercial venture. I will not be doing
the coding myself. Don't expect to get your microsoft
contract renewed.


Peter Olcott

unread,
Jan 21, 2002, 10:52:15 PM1/21/02
to
> > > Only because he felt it was important to expose the false assumptions
> > > in your testing and the erroneous nature of your benchmark. Not because
> > > he felt your testing was so valid and important that he could use it to
> > > improve his string class.
>
> > Yet he did not expose any false assumptions, nor, erroneous nature,
> > therefore you err in your fundamental assessment.
>
> Your logic escapes me. I am saying that his motive in benchmarking his
> string class with your benchmark was to show that your benchmark was
> erroneous. You respond that he didn't show that your benchmark was
> erroneous. True or not, this doesn't refute my point at all.
>

You claimed that he showed that my benchmark was erroneous.
He did not indeed provide the slightest detail about any erroneous
aspect of my benchmark, thus your claim is flatly false.

> Again, I'm that this was his motive and the conclusion he drew, and you

He provided not the slightest trace of evidence supporting your
contention, thus your contention is utterly baseless.

> respond that it is not a conclusion that he has convinced you of. So you
> are trying to establish another person's motives not based upon how they
> see things but based upon how you see things. This will not ever succeed
> in determining another person's motives.

If his goal was to show that my benchmarks are in error, then
he did nothing at all to fullfill this goal.

> And you replied:
>
> >P. J. Plauger went to the trouble of testing his code against mine,
> >on these benchmarks, on two separate occasions. On the latter
> >occasion he even went through the extraordinary effort of changing
> >his code in the apparently successful attempt to beat these benchmarks.
> >(by 1.3%). Also these benchmarks directly resulted in a permanent
> >change to all future releases of his library. All this can be verified
> >through Google. I would say that you have been sufficiently refuted
>
> So my point is not that what you said above is false but that this
> doesn't provide any evidence that your benchmark is valid. You are

The act of the time and effort that P. J. Plauger spent on my benchmark,
provides a degree of validation of this benchmark. The lack of direct
evidence refuting the validity of this benchmark, also provides
evidence of its validity.

> trying to say that P. J. Plauger would not have bothered had he not
> considered your benchmark valid. I provided an alternate motive. To
> refute that motive, you must start with how P. J. Plauger judges things
> which you can easily do based upon his posts here.

If my benchmarks were obviously invalid, he would have only
needed to point out the specific errors in them, and then stop.
He didn't point out any errors. The only limitation that was raised
is the lack of measuring the benefit of COW strings. Even this
is moot now, because his current code does not have COW
strings. It looks like the COW may have died.

> So you maintain that the only reason P. J. Plauger would test his code
> against your benchmark was if he felt they accurately measured the speed
> of his code? You consider it impossible that he was just curious or just
> trying to beat you at your own game or just trying to show how
> meaningless your benchmarks are. What an interesting world you live in.

His utter lack of success in refuting the validity of these
benchmarks itself is very significant. Of course it would
not be at all reasonable for a person to assert the validity
of any set of benchmarks where their relative performance
comes out behind. He may have said that they were
invalid many times in many ways. What it missing is that
he did not show that they were invalid, and neither did
you.

The whole purpose of this thread is to derive a truce
on this issue. I have the fastest special purpose string,a
and his string is well fast enough for general purpose
use. To make his string much faster costs code bloat,
and for a general purpose string this is not desirable.
For a special purpose string the degree of code bloat
is inconsequenctial, because of its infrequencey of use.

With this form of truce we could both continue on
pursuing our self-interests without the need to
compete head to head. I would not cut into his
markey share, and there would still be a market
saher left for me.

> > If you want to discuss this last point more in depth, I am willing.
> > I have already acknowledged that this is the one possibility
> > of less than ideal accuracy in these benchmarks. I still think
> > that the consequences of this one possibly valid point are
> > insufficient, yet, I am willing to explore this issue further.
>
> So you have some question about the usefulness of your benchmarks? You
> don't think P. J. Plauger does too?
>
> DS

No there is no question of the usefulness or the accuracy
of my benchmarks when they are measruring how well
an application with equivalent degree of string intense
usage would compare to these benchmarks. I am quite
confident that these benchmarks will provide a very
good measure of actual performance under any and
all conditions with extremely intense string operation
usage. Bottom line is just plug FastString into the app
and see.


Peter Olcott

unread,
Jan 21, 2002, 11:03:23 PM1/21/02
to
> > P. J. Plauger went to the trouble of testing his code against mine,
> > on these benchmarks, on two separate occasions. On the latter
> > occasion he even went through the extraordinary effort of changing
> > his code in the apparently successful attempt to beat these benchmarks.
> > (by 1.3%).
>
> Extraordinary effort? He claimed that it took a couple of hours.
>

That is quite a bit of effort to compete against a benchmark
that so many people are claiming is totally worthless.While
they may continue to claim that these benchmarks are not
accurate, not even one person has provided any sufficient
basis to support this claim.

> > Also these benchmarks directly resulted in a permanent
> > change to all future releases of his library.
>
> P.J. Plauger has already refuted your false assertion. It was a comment of
> _another poster_ that gave him the idea of changing something.
>

Yet still as a direct result of my benchmarks. In particular
the benchmark where his code was 300-fold slower than
STLport. This figure was estimated in that FastString
was 178-fold faster than MSVC++ 6.0, and STLport
beat FastString by double, thus the 300-fold estimate
was conservative. I still beat his old code by 167-fold,
even without the notorious bug in my benchmark.

http://home.att.net/~olcott/FastString.html
If there is any bug in this current benchmark let me know,
and I will fix it. I think that he explained this huge performance
difference in terms of a very conservative memory growth rate,
that has since been updated.

Adam Peterson

unread,
Jan 21, 2002, 11:19:06 PM1/21/02
to
> > P.J. Plauger has already refuted your false assertion. It was a comment
of
> > _another poster_ that gave him the idea of changing something.
> >
>
> Yet still as a direct result of my benchmarks.

You might be able to argue that it was an _indirect_ result of your
benchmarks. You cannot argue that it was a direct result. It was not your
benchmarks that caused the change (on a fork of an older version of string
that doesn't affect the current code fork, IIUC), but rather someone else's
pointing out a nonnormative note in the C++ Standard that you seem to refuse
to get your hands on.

Adam Peterson

unread,
Jan 21, 2002, 11:15:56 PM1/21/02
to
> The act of the time and effort that P. J. Plauger spent on my benchmark,
> provides a degree of validation of this benchmark. The lack of direct
> evidence refuting the validity of this benchmark, also provides
> evidence of its validity.

I believe he stated very clearly that he was doing it to satisfy you alone.
I don't see how you can make a jump like this. It's just plain not logical.
That's like saying that because 2*2=4 that 3*3=6. It just plain straight
out doesn't follow. Clear evidence that he had low regard for these
benchmarks are the fact that from the very beginning, when he had produced a
class designed to fit on the benchmarks that did better than your FastString
and his own distributing codebase for std::string on those benchmarks, he
stated very clearly that he had no intention of distributing it, favoring
instead what he was already distributing.

>
> > trying to say that P. J. Plauger would not have bothered had he not
> > considered your benchmark valid. I provided an alternate motive. To
> > refute that motive, you must start with how P. J. Plauger judges things
> > which you can easily do based upon his posts here.
>
> If my benchmarks were obviously invalid, he would have only
> needed to point out the specific errors in them, and then stop.

We have been pointing out the problems with them for weeks now, and you're
not listening. So in a misguided (IMO) effort to get through to you, he
demonstrated both the low value of your FastString by beating it on the
benchmarks for which it was designed and the low value of your benchmarks by
declaring his intention to discard those changes on his authority and
evaluation that they were worthless. If your benchmarks are really useful,
this is a risky thing for him to do. It would cost confidence in
Dinkumware's ability to produce quality software. However, speaking as
someone about as disconnected from Dinkumware as a serious C++ programmer
can be, I believe he has lost none.

Jacques

unread,
Jan 21, 2002, 11:45:17 PM1/21/02
to
Peter Olcott wrote:

ROFL.
Peter, it may pay you to write each of your posts and then wander off
to make some coffee before sending. If, when you get back, you still
think the message is a good idea then by all means go ahead and send
it.
That would certainly save you from this sort of embarrassment.

--
-----------------------------------------------
mail: curve at waveform.org, UIN: 64192061.
list: curves-kiddies-request at ethernal.org.
-----------------------------------------------

Peter Olcott

unread,
Jan 22, 2002, 12:02:48 AM1/22/02
to
> > Okay then I may choose to acquire the resources of
> > some world class partner's with the sole purpose
> > of providing the best possible STL available. This
> > will be a commercial venture. I will not be doing
> > the coding myself. Don't expect to get your microsoft
> > contract renewed.
> >
> >
> >
>
> ROFL.
> Peter, it may pay you to write each of your posts and then wander off
> to make some coffee before sending. If, when you get back, you still
> think the message is a good idea then by all means go ahead and send
> it.
> That would certainly save you from this sort of embarrassment.
>
>
I have been thinking that it would be a good idea to have
an STL implementation that can be relied upon as near
mathematical optimality across all of its platforms for
quite some time. I have already derived a simple and
profitable way that this can be accomplished. His error
was assuming that I would be the one writing this code.


Adam Peterson

unread,
Jan 21, 2002, 11:51:09 PM1/21/02
to
> > Okay then I may choose to acquire the resources of
> > some world class partner's with the sole purpose
> > of providing the best possible STL available. This
> > will be a commercial venture. I will not be doing
> > the coding myself. Don't expect to get your microsoft
> > contract renewed.
> >
> >
> >
>
> ROFL.
> Peter, it may pay you to write each of your posts and then wander off
> to make some coffee before sending. If, when you get back, you still
> think the message is a good idea then by all means go ahead and send
> it.
> That would certainly save you from this sort of embarrassment.

Well said, if I may say so. When I read this, I couldn't think of a
suitable response. Nothing I could say could possibly make it look more
ridiculous than letting it speak for itself.


Attila Feher

unread,
Jan 22, 2002, 12:16:01 AM1/22/02
to
Peter Olcott wrote:
>
> > > Although

> > > I am relatively new to C++, I have been programming in
> > > C since K&R was the official standard, in my case since
> > > 1986. Thus some of what I say has a very substantial basis.
> >
> > Uh oh. Now I see why are you so ignorant about the differences between
> > C and C++ way of design and coding. Your code is excellent, from the
> > narrowed down perspective of a C programmer.
>
> Finally someone says something nice about this code.

I have not said anything nice about your code. What I have said
translates to an experienced C++ programmer as: this is the way, what an
unexperienced, C-only ego would come up, and think that he has done
something, while in reality it is a highly narrowed down perspective,
missing the most fundamental points of - yet trying to compare to - the
original (templated etc.) design.

> I also propose that it can be extended to the full standard.

:-))) I remember when I was young and I thought I know everything,
because I know so little. I wonder how can you be in this state... I
mean I left it around age 5, latest.

> Apparently P. J. Plauger has already proven this point.

He did not. What he has proven is, that for _certain_, POD traits, for
_certain_ conditions he was able to speed up his code in the light of
non-representative benchmarks. If this new code will show significant
speedup in real-life situations is another issue...

You are pathetic. Sorry to say that, nothing personal meant, but this
whole thing (your posts) starts to sound like the current Hungarian
governments tax-payed self-advertisement:
- We are in much better position now!
- But Sir, you have doubled the state debt!
- Do not worry! We are in a much better position now!
- But Sir, we have twice as much unemployed and twice as much homeless
people!
- Do not worry! We are in a much better position now!
- But Sir, our economy has slowed down to halt!
- Do not worry! We are in a much better position now!
- But Sir, our budget has been overrun more than twice the percentage
allowed by the EU requirements for joining!
- Do not worry! We are in a much better position now!

Now this is how discussion with you looks like, except that you are
being told facts and you answer with your mute and usually dumb opinions
posed as facts.

Attila

Attila Feher

unread,
Jan 22, 2002, 12:20:05 AM1/22/02
to

No. Your error was that you think that creating a useful STL is two
nights work. I remember that it took several weeks for you to provide a
version of your class which even worked(!!!) in some simple situations
(not being exception safe etc.). And you have never ever reached the
stage to even _grasp_ the _fundamental_ difference between generic a
_container_ (what std::string is) and a C-programmers class-packed
memcpy collection what your string is...

So I would say about 20 years from now, Standard Library implementors
should look out for your first public beta... :-))

A

Peter Olcott

unread,
Jan 22, 2002, 12:25:22 AM1/22/02
to
> You can contend this if you want. It is self-evidently false by many of us,
> and the burden of proof is on you that it is true. (A very heavy burden to
> bear, by the way.)

Prove that the order of my operations significantly effects their
performance by specifying any order that could be used in any
string intensive tight loop, whereas order would make a significant
difference in its performance. It must be something that could
actually occur in a real app. I already have one particular idea
in mind for this. The repeated concatenation of a single byte
to one thousand different strings. That ought to give the data
cache a run for its money.

> I have seen that a counter example is not sufficient to disprove what you
> say. When you receive a counter example, very frequently you simply alter
> the argument so that the counter example is no longer covered. Well, I for
> one can see where this can go, and I don't have time to do this little
> dance.

You have not provided a 100% complete and empirically verifiable
counter-example yet. I may have already done this above. See
what 100% complete and totally specific ideas you can add to
my test of your hypothesis as specified above.

Attila Feher

unread,
Jan 22, 2002, 12:36:14 AM1/22/02
to
Peter Olcott wrote:
>
> > Peter Olcott wrote:
> >
> > > thus fully conforming
> > > code can be at least as fast as FastString, and several
> > > hundred fold faster than its earlier versions.
> >
> > As measured by a benchmark that nobody but you thinks measures anything
> > important.
> >
> > DS
>
> P. J. Plauger went to the trouble of testing his code against mine,
> on these benchmarks, on two separate occasions. On the latter
> occasion he even went through the extraordinary effort of changing
> his code in the apparently successful attempt to beat these benchmarks.
> (by 1.3%). Also these benchmarks directly resulted in a permanent
> change to all future releases of his library. All this can be verified
> through Google.

> I would say that you have been sufficiently refuted.

I would say it hasn't. :-))) The fact that Mr. Plauger had enough of
your black marketing against his code, and spent some of his time to
shut you up, before you cause him any more financial loss he already had
to suffer due to the people wanted him out of business does not mean
that he gives a rats backside to the results of your benchmarks. Which
is very possible. And I am sure if he _will_ include this change into
his code, he will do it after _very_ careful considerations of
portability etc. Like while an inline asm memcpy on Intel may beat the
crap out of a for loop with a not-so-good optimizing compiler, the
latter for loop may beat the crap out of shared library called memcpy on
a Unix/Linux with a good optimizer in the compiler. And for short
strings (which make up the most of the strings used in some
applications) a function call can be rather expensive even compared to
the worse copy loop... So he will (based on his huge experience with
C++) base his design decision on facts. You base yours on
trial-n-error, hopes, opinions of yours, non-representative benchmarks
and C programming experiences - and practically no C++ design
knowledge...

> Since his code is the MSVC++ STL library it forms probably
> the most widely distributed STL library available, this latter
> comment is an educated guess.

Most widely distributed and but way less used STL (in MSVC). Sorry to
say that, but _most_ of the MSVC++ designers use MFC, and they have not
ever heard or cared about STL much. This is nothing about Mr. Plauger's
product, it is the way life works around MS products. So if there were
2M MSVC sold, 1M out of this has _never_ been used for production
(people bought the Studio or MSDN for Java and VB and stuff) and about
100K out of those designers use STL and many of those uses STLPort...
These are just arbitrary numbers, but I have seen enough places to know,
that MSVC licence is usually not even used, or if used it is used with
MFC etc. etc. Which does not have anything to say about the STL in
MSVC.

Attila

Attila Feher

unread,
Jan 22, 2002, 12:38:52 AM1/22/02
to
"ignored LShaping" wrote:
>
> no comment

Steven Rumbalski

unread,
Jan 22, 2002, 1:17:10 AM1/22/02
to
Jacques wrote:

> Peter Olcott wrote:
>
>> Okay then I may choose to acquire the resources of
>> some world class partner's with the sole purpose
>> of providing the best possible STL available. This
>> will be a commercial venture. I will not be doing
>> the coding myself. Don't expect to get your microsoft
>> contract renewed.
>>
>>
>>
>
> ROFL.
> Peter, it may pay you to write each of your posts and then wander off
> to make some coffee before sending. If, when you get back, you still
> think the message is a good idea then by all means go ahead and send
> it.
> That would certainly save you from this sort of embarrassment.
>

One would expect after such a stupid statement Peter would crawl away
quietly, never to be seen on comp.lang.c++ again. But of course that would
require being in touch with reality.

Steven Rumbalski

Dann Corbit

unread,
Jan 22, 2002, 1:03:00 AM1/22/02
to
"Adam Peterson" <ah...@email.byu.edu> wrote in message
news:a2ir42$luq$1...@acs2.byu.edu...

"Some people you don't have to parody -- you just quote 'em." -- Tom Lehrer
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm

Al Dunbar

unread,
Jan 22, 2002, 1:38:52 AM1/22/02
to

"Peter Olcott" <olc...@worldnet.att.net> wrote in message
news:Yn638.315630$WW.14...@bgtnsc05-news.ops.worldnet.att.net...

Ahhh, another budding Bill Gates in the works, perhaps...

/Al

Al Dunbar

unread,
Jan 22, 2002, 1:54:47 AM1/22/02
to

"Attila Feher" <Attila...@lmf.ericsson.se> wrote in message
news:3C4CF591...@lmf.ericsson.se...

As a non-C non-C++ person, I find the nitty gritty technical details of this
thread totally beyond me. It is plain, however, that Mr. Olcott is in a
serious minority in this thread, however much he misconstrues the statements
of others in support of his ideas.

/Al

Al Dunbar

unread,
Jan 22, 2002, 1:56:26 AM1/22/02
to

"Jon Bills" <jon_...@hotmail.com> wrote in message
news:0c49133bbec65270e35...@mygate.mailgate.org...

> "Attila Feher" <Attila...@lmf.ericsson.se> wrote in message
> news:3C4C5647...@lmf.ericsson.se...
>
> > LShaping wrote:
> > [SNIP]
> > > But Attila Feher and Jon Bills both have PhDs in trolling.
> >
> > Correction: troll detection. :-) We won't take your role away for all
> > the money in the world. :-))))
> >
> > Attila
>
>
> What Queeg... sorry, LShaping seems to forget is that anyone can go
> and search the Google archives to see what sort of posts he submits.
> A quick search reveals him to be a classic Usenet fuckwit.

Queeg, eh? Now *there* was a man with balls!

/Al

Al Dunbar

unread,
Jan 22, 2002, 2:07:55 AM1/22/02
to

"Peter Olcott" <olc...@worldnet.att.net> wrote in message
news:VM%28.415941$W8.14...@bgtnsc04-news.ops.worldnet.att.net...

<snip>

> > Some. Perhaps some. But you have made very few intelligent points in
> > hundreds of posts and seem unable to grasp the intelligent points of
> > others.
>
> There are two reasons for this.
>
> (1) I don't share much of the common terminology, thus
> it is not the ideas that I don't understand it is the attachment
> of these ideas to their corresponding terms, that I have yet
> to memorize.

IMHO, if you are still at the stage where you are having to memorize
terminology, you are likely out of your depth here.

> (2) There may in some cases be subtleties that I am referring
> to that are not apprarent to others.

LOL. How could this possibility result in *your* "making few intelligent
comments", and *your* "inability to grasp..."?

Interesting how you can say this, but that you do not seem to accept the
view expressed by others that you have on occasion missed subtleties (and
even some not so subtle ones) in what they have said.

> > >Other things that I say may rely upon information that
> > >I received from others that eventually proves to be unreliable.
> >
> > You appear to have a complete inability to judge the information that
> > others give you. You disregard correct information, and, according to
> > what you are now saying, you rely upon incorrect information. This is
> > hardly indicative of critical thinking.
> >
> > Tom
>
> You open youself up to losing all of your personal property
> to libel cases, by calling people liars with no sufficient basis.

IMHO, he said no such thing in his last paragraph. He repeats a statement
you did not refute earlier, and he repeats a statement you yourself made
previously. To say a person is incorrect is not to call them a liar.

/Al

Mike Hewson

unread,
Jan 22, 2002, 2:31:35 AM1/22/02
to
"Steven Rumbalski" <srumb...@prodigy.net> wrote in message
news:Gt738.10026$3C2.165...@newssvr17.news.prodigy.com..

.
> One would expect after such a stupid statement Peter would
crawl away
> quietly, never to be seen on comp.lang.c++ again. But of
course that would
> require being in touch with reality.

"Vomiting ambition overleaps itself"

( ......with apologies to Mr Shakespeare )

--

Cheers.

--
Hewson::Mike
"I have made this letter longer than usual because I lack
the time to make it shorter."
- Blaise Pascal


Attila Feher

unread,
Jan 22, 2002, 3:03:11 AM1/22/02
to
Al Dunbar wrote:
[SNIP]

> Queeg, eh? Now *there* was a man with balls!

...in place of his brain - and here I mean the Queeg troll in clc++

Attila

Peter Olcott

unread,
Jan 22, 2002, 11:27:25 AM1/22/02
to
> We have been pointing out the problems with them for weeks now, and you're
> not listening. So in a misguided (IMO) effort to get through to you, he
> demonstrated both the low value of your FastString by beating it on the
> benchmarks for which it was designed and the low value of your benchmarks by
> declaring his intention to discard those changes on his authority and
> evaluation that they were worthless. If your benchmarks are really useful,

Yet since he did not provide sufficient reason why he intended to
discard these changes, even when directly asked, I can not count on
this as a fact. He said that the changes looked ugly, and he said that the
code took longer to compile. Neither of these two is a sufficient reason
to abandon code that has proven to be as much as 8.5 fold faster
on recent benchmarks.

Because he refused to answer the direct question of the set of things
that was given up by this optimization, for all I know for sure he
may not actually discard these changes, and might retain them in
specific violation of my copyright. The proof of this will be when
his next code ships, and he still beats me.

I have already stated that what I consider the more likely scenario
is the fact that a large degree of this change results in the code
bloat entailed by having all of the user interface functions inlined,
yet if this is the case, I see no reason why he would not have
said this when directly asked.

Peter Olcott

unread,
Jan 22, 2002, 11:30:04 AM1/22/02
to
> IMHO, he said no such thing in his last paragraph. He repeats a statement
> you did not refute earlier, and he repeats a statement you yourself made
> previously. To say a person is incorrect is not to call them a liar.
>
> /Al
>
>
He called my a liar specifically. He did not
merely assert that I was incorrect.


Attila Feher

unread,
Jan 22, 2002, 11:40:27 AM1/22/02
to

Good morning! Having a bad day? Again? All the stupid worlds is
against except a troll? :-))) Anyways: good morning!

A

Peter Olcott

unread,
Jan 22, 2002, 12:11:31 PM1/22/02
to
> > P. J. Plauger went to the trouble of testing his code against mine,
> > on these benchmarks, on two separate occasions. On the latter
> > occasion he even went through the extraordinary effort of changing
> > his code in the apparently successful attempt to beat these benchmarks.
> > (by 1.3%). Also these benchmarks directly resulted in a permanent
> > change to all future releases of his library. All this can be verified
> > through Google.
>
> > I would say that you have been sufficiently refuted.
>
> I would say it hasn't. :-))) The fact that Mr. Plauger had enough of
> your black marketing against his code, and spent some of his time to
> shut you up, before you cause him any more financial loss he already had

This last statement proves my point. That is the problem with people
with biased views, the actual truth keeps getting in the way of their
bias. Everyone knows that these benchmarks are totally worthless,
AND they cause him financial loss? You can't have it both ways,
I will take this as a slip up in your bias, and thus a confirmation of
the value of these benchmarks.

Peter Olcott

unread,
Jan 22, 2002, 12:11:30 PM1/22/02
to
> > I have been thinking that it would be a good idea to have
> > an STL implementation that can be relied upon as near
> > mathematical optimality across all of its platforms for
> > quite some time. I have already derived a simple and
> > profitable way that this can be accomplished. His error
> > was assuming that I would be the one writing this code.
>
> Ahhh, another budding Bill Gates in the works, perhaps...
>
> /Al
>
>
I have been working on different software inventions
for twenty years. I finally have one that is almost finished
that has a good chance of getting past the novelty
requirement of the patent laws, and would be highly
marketable in several different types of application.
As compare to this obtaining the cooperation of others
to implement a better STL as a for profit venture
would be trivial, STL being inherently far simpler than
the technology of my current invention.


Peter Olcott

unread,
Jan 22, 2002, 12:11:31 PM1/22/02
to
> > I have been thinking that it would be a good idea to have
> > an STL implementation that can be relied upon as near
> > mathematical optimality across all of its platforms for
> > quite some time. I have already derived a simple and
> > profitable way that this can be accomplished. His error
> > was assuming that I would be the one writing this code.
>
> No. Your error was that you think that creating a useful STL is two
> nights work. I remember that it took several weeks for you to provide a

I never made that mistake, this is only a presumption on your part.
I did make a very useful and much faster subset of std::string,
in about a month in my spare time.

> version of your class which even worked(!!!) in some simple situations
> (not being exception safe etc.). And you have never ever reached the
> stage to even _grasp_ the _fundamental_ difference between generic a
> _container_ (what std::string is) and a C-programmers class-packed
> memcpy collection what your string is...

(1) My class now works top the best of my knowledge, perfectly.
I have at least addressed every objection that was expressed.

(2) Apparently making std::string completely generic loses
some important features, like a simpler syntax for reserving
space std::string A(10000); and a consistent form
for constructors std::string A('a');

(3) The specific form of implementation is an implementation
detail, and should not be considered as part of the design.
In this case this detail does effect how a string can be used,
yet it is only the aspects that effect how a string can be used
that are relevant.

Peter Olcott

unread,
Jan 22, 2002, 12:11:32 PM1/22/02
to
> He did not. What he has proven is, that for _certain_, POD traits, for
> _certain_ conditions he was able to speed up his code in the light of
> non-representative benchmarks. If this new code will show significant
> speedup in real-life situations is another issue...

Yet of all these experts here no one has provided any sufficient
evidence to show otherwise. Not even one specific hypothetical
scenario where my code would prove to be even relatively
slower than other implementations. The lack of evidence against
a claim, forms increasingly stronger evidence for a claim, in
direct proportion to the degree that this counter-evidence is
sought.


Paul E. Black

unread,
Jan 22, 2002, 12:57:26 PM1/22/02
to
Peter Olcott wrote:
> Seeking Truth requires one to abandon all assumptions.

Seeking Truth requires one to be willing to abandon all assumptions.

-paul-
--
Paul E. Black (p.b...@acm.org)

P.J. Plauger

unread,
Jan 22, 2002, 1:40:56 PM1/22/02
to
"Peter Olcott" <olc...@worldnet.att.net> wrote in message
news:Npg38.417006$W8.14...@bgtnsc04-news.ops.worldnet.att.net...

> Because he refused to answer the direct question of the set of things
> that was given up by this optimization, for all I know for sure he
> may not actually discard these changes, and might retain them in
> specific violation of my copyright. The proof of this will be when
> his next code ships, and he still beats me.

Back off, Bucko. I suspect you know less about copyright law than you
do about libel, but I won't tolerate slurs like this. I've made a
living as a programmer and a writer for nearly 40 years, and I've
clocked time in Federal court defending my intellectual property.
I believe I DO know something about copyright law, both the letter and
the spirit. I have NOT copied any expression from you. I don't need to.

Now I went after you before because you were falsely maligning a
product of some importance to us. I backed off when it became clear
that I had made my point to our mutual audience, and because I have
trouble picking on an emotional cripple. I have no scruples about
resuming our little asymmetric debate if you're going to start
traipsing on dangerous ground once again.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Adam Peterson

unread,
Jan 22, 2002, 2:00:57 PM1/22/02
to
> I never made that mistake, this is only a presumption on your part.
> I did make a very useful and much faster subset of std::string,
> in about a month in my spare time.

If it took you a month to get a start on std::string, how long is it going
to take you to implement the 350+ pages of library mandated by the C++
standard (not even including any of the stuff inherited from C)? I think it
is reasonable to suppose that it would take you (even as part of a team)
years or possibly decades to even get it right, let alone optimize it so
that it's better than what we will then have from the library vendors of the
future.

> (2) Apparently making std::string completely generic loses
> some important features, like a simpler syntax for reserving
> space std::string A(10000); and a consistent form
> for constructors std::string A('a');

These are both extensions that you may choose to provide, I suppose, if you
like. But if as a result you break Standard compatibility, the price is way
too high.

> (3) The specific form of implementation is an implementation
> detail, and should not be considered as part of the design.
> In this case this detail does effect how a string can be used,
> yet it is only the aspects that effect how a string can be used
> that are relevant.

So essentially this is the opposite of what you claim is good. It affects
the interface of your class without affecting the implementation.

Even if your library was available _now_, almost no one would use it if it
has too high an opinion of itself to conform to the standard. I don't want
to be locked into the Olcott library any more than I want to be tied to g++
or MSVC or xlC or any other component that should be replacable and will be
if it conforms.


Peter Olcott

unread,
Jan 22, 2002, 2:49:56 PM1/22/02
to
You never did finish your support case. What exactly is there about
the changes that you made to beat my benchmarks that would cause
you to discard ALL of these changes? Please try to reply in terms
of a fully supported basis.


Peter Olcott

unread,
Jan 22, 2002, 2:59:52 PM1/22/02
to
> Now I went after you before because you were falsely maligning a
> product of some importance to us. I backed off when it became clear
> that I had made my point to our mutual audience, and because I have
> trouble picking on an emotional cripple. I have no scruples about

The fact that you must resort to name calling, and I do not
shows whom has the disadvantage, and whom does not.

P.J. Plauger

unread,
Jan 22, 2002, 3:07:26 PM1/22/02
to
"Peter Olcott" <olc...@worldnet.att.net> wrote in message
news:Enj38.113790$fe1.2...@bgtnsc06-news.ops.worldnet.att.net...

> > > Because he refused to answer the direct question of the set of things
> > > that was given up by this optimization, for all I know for sure he
> > > may not actually discard these changes, and might retain them in
> > > specific violation of my copyright. The proof of this will be when
> > > his next code ships, and he still beats me.
> >
> > Back off, Bucko. I suspect you know less about copyright law than you
> > do about libel, but I won't tolerate slurs like this. I've made a
> > living as a programmer and a writer for nearly 40 years, and I've
> > clocked time in Federal court defending my intellectual property.
> > I believe I DO know something about copyright law, both the letter and
> > the spirit. I have NOT copied any expression from you. I don't need to.
> >
> > Now I went after you before because you were falsely maligning a
> > product of some importance to us. I backed off when it became clear
> > that I had made my point to our mutual audience, and because I have
> > trouble picking on an emotional cripple. I have no scruples about
> > resuming our little asymmetric debate if you're going to start
> > traipsing on dangerous ground once again.
> >

> You never did finish your support case. What exactly is there about
> the changes that you made to beat my benchmarks that would cause
> you to discard ALL of these changes? Please try to reply in terms
> of a fully supported basis.

I admire your ability to engage otherwise sensible people in your
little circular games. I've noted more than once that you resort to
more outrageous statements when attention seems to flag. But I
remain clear why I personally am participating in this verbal flea
circus. It is to counter misrepresentations that you make before
they acquire specious truth through repetition.

I don't give a tinker's dam what you think about the state of my
``support case.'' My only concern at this point is whether you
intend to further signify that I am violating any copyrights, yours
or otherwise. I suggest you drop that particular subject entirely.

Peter Olcott

unread,
Jan 22, 2002, 3:27:23 PM1/22/02
to
> I admire your ability to engage otherwise sensible people in your
> little circular games. I've noted more than once that you resort to
> more outrageous statements when attention seems to flag. But I
> remain clear why I personally am participating in this verbal flea
> circus. It is to counter misrepresentations that you make before
> they acquire specious truth through repetition.
>
> I don't give a tinker's dam what you think about the state of my
> ``support case.'' My only concern at this point is whether you
> intend to further signify that I am violating any copyrights, yours
> or otherwise. I suggest you drop that particular subject entirely.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
>
I simply can not tell the answer to this question one way
or the other at this time. There is not a sufficient basis
yet. I would assume that you are not. I would assume that
one of the primary reasons that you dropped the changes
that were required to beat my benchmarks was that these
changes required making all the interface functions inline,
and this could result in greater code bloat, thus not desirable
in a general purpose string class. Since you never provided
this reason, it may be that my reasoning is wrong in this
regard. If your next release consistently beats FastString
on these same benchmarks, this would form my sufficient
basis to look into this matter further, a line-by-line analysis.

If it retains the quite good performance that it had on this
benchmark test that you ran, then I would consider this matter
essentially dropped.

http://groups.google.com/groups?q=g:thl3028038985d&hl=en&selm=3c3df285%240%241644%244c41069e%40reade
r0.ash.ops.us.uu.net


Stephen Howe

unread,
Jan 22, 2002, 3:32:26 PM1/22/02
to
> Isn't the whole source of everyone's problem with my
> opinions, that they are not humble, but, brazen?

I am amazed at you saying that. So many people have commented on that, that
you have to ask, "is it me?"
Obviously not in your case.

Presumably, if the whole world said the same, it follows the whole world is
brazen, right?

Stephen Howe


CBFalconer

unread,
Jan 22, 2002, 3:47:41 PM1/22/02
to

Olcott has been PLONKED here. Saves a lot of wear and tear on the
modem. I made one response that tended to confirm his wishes
about hardware, and was then touted as a hardware expert who
justified his attitude for some time (which I am, but he doesn't
know that :-).

--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)


Peter Olcott

unread,
Jan 22, 2002, 3:57:55 PM1/22/02
to
> If it took you a month to get a start on std::string, how long is it going
> to take you to implement the 350+ pages of library mandated by the C++
> standard (not even including any of the stuff inherited from C)? I think it
> is reasonable to suppose that it would take you (even as part of a team)
> years or possibly decades to even get it right, let alone optimize it so
> that it's better than what we will then have from the library vendors of the
> future.

That's the cool thing about STL and its related libraries.
All of this stuff stands alone, and is not a monolithic
single app. Thus the duration of the job, would depend
upon the abilities and size of the team. We might start
by just implementing the best possible std::string.

> > (2) Apparently making std::string completely generic loses
> > some important features, like a simpler syntax for reserving
> > space std::string A(10000); and a consistent form
> > for constructors std::string A('a');
>
> These are both extensions that you may choose to provide, I suppose, if you
> like. But if as a result you break Standard compatibility, the price is way
> too high.

It would be better if this arbitrary aspect of the standard would
change.


Stephen Howe

unread,
Jan 22, 2002, 4:10:18 PM1/22/02
to
> I have two bachelor's degrees in computers. MIS and CS.
> I have been a professional programmer since 1984. Although

> I am relatively new to C++, I have been programming in
> C since K&R was the official standard, in my case since
> 1986.

Well that is 15 years then. And in all that time you have, as you have
acknowledged in a another thread, you have never learnt to use pointers.
Since that is the heart of C, particularly in terms of sheer speed (and this
is not really debatable, go back to K&R 2nd edition for opinions on this),
that is a major omission. As far as I am concerned, you are a novice. If
another 15 years lapsed and you still had not learnt how to use pointers,
then you would still be a novice. It is no good saying, "compilers are so
smart, arrays are almost good as pointers".

It is also restrictive. Many parts of the standard C library hand you back
pointers(bsearch(), malloc(), fopen() etc) where it vital to treat the
return value as a pointer.

The same could be said about C++. If it worked out that a programmer had
been using C++ for 15 years and had used vectors, strings & deques because
they provided an [] operator which gives you array-like access and had never
used an iterator or other containers because iterators are required (*),
then I would regard them as a novice.

(*) except map [] insert/update.

Stephen Howe

Stephen Howe

unread,
Jan 22, 2002, 4:24:12 PM1/22/02
to
> He argued vehemently for including reference counted strings
> in the analysis. If his code does not have reference counting,
> then why else would he do this?

Because there is general consensus these days that COW strings are extremely
difficult to make thread-safe and making them thread-safe gives slow
performance. So the tendency is to provide non-COW strings. Perhaps for
single-threaded applications, COW strings would be okay (*). And since
Dinkumware's code is used in environments where thread-safety is an issue,
that explains that.

(*) and that is a generalisation. A particular application may make very
little use of shared strings in which case non-COW would score.

> Its not my mere opinions that count, its the concrete results of my
benchmarks that count.

And as has been said, your benchmarks are disputable. Why don't you run
FastString through the benchmarks available at
http://www.gotw.ca/gotw/045.htm See bottom of the page

Stephen Howe


Peter Olcott

unread,
Jan 22, 2002, 4:27:20 PM1/22/02
to
> Well that is 15 years then. And in all that time you have, as you have
> acknowledged in a another thread, you have never learnt to use pointers.
> Since that is the heart of C, particularly in terms of sheer speed (and this
> is not really debatable, go back to K&R 2nd edition for opinions on this),
> that is a major omission. As far as I am concerned, you are a novice. If
> another 15 years lapsed and you still had not learnt how to use pointers,
> then you would still be a novice. It is no good saying, "compilers are so
> smart, arrays are almost good as pointers".
>
> It is also restrictive. Many parts of the standard C library hand you back
> pointers(bsearch(), malloc(), fopen() etc) where it vital to treat the
> return value as a pointer.
>
> The same could be said about C++. If it worked out that a programmer had
> been using C++ for 15 years and had used vectors, strings & deques because
> they provided an [] operator which gives you array-like access and had never
> used an iterator or other containers because iterators are required (*),
> then I would regard them as a novice.
>
> (*) except map [] insert/update.
>
> Stephen Howe
>
>
The most elementary use of pointers is trivial, and I have known how
to do this since before I learned C. The difficult case is getting the
syntax just right, when you must pass pointers to pointers to pointers
to functions. I was able to bypass learning this too. Merely tack an
& on the end, and have this also as the function parameter, and
whatever syntax works outside of the function now works inside
the function. One of the biggest problems with using pointers
instead of array subscripts is that array subscripts can be output
for debugging. Now that I must finally deal with dynamic memory,
I must finally deal with pointers everywhere. I can even avoid
this in many cases by creating a dynamic array. Using pointers
is ideal in the creation of a stack. Now the stack can dynamically
grow to exactly the depth that it needs.


willem veenhoven

unread,
Jan 22, 2002, 4:36:18 PM1/22/02
to
CBFalconer wrote:

>
> P.J. Plauger wrote:
>
> > Back off, Bucko. I suspect you know less about copyright
> > law than you do about libel ...

> Olcott has been PLONKED here. Saves a lot of wear and tear
> on the modem. I made one response that tended to confirm
> his wishes about hardware, and was then touted as a hardware
> expert who justified his attitude for some time (which I am,
> but he doesn't know that :-).

I know, and I'm sure P.J. Plauger knows too. But please tell
me, does anything of this have to do with the daily business
of comp.programming?

I'm sure over 80% of the posters in comp.programming has no
idea of who P.J. Plauger is, let alone they'll get very exited
when you mention this Olcott guy.

A kind request to all posters from comp.lang.c++: Please strip
comp.programming from this silly thread :)

willem

Stephen Howe

unread,
Jan 22, 2002, 4:34:12 PM1/22/02
to
> Like while an inline asm memcpy on Intel may beat the
> crap out of a for loop with a not-so-good optimizing compiler, the
> latter for loop may beat the crap out of shared library called memcpy on
> a Unix/Linux with a good optimizer in the compiler.

I would trust the compiler vendors version of memcpy(), memmove() and
memset() these days in preference to hand-crafted assembler particularly for
Intel chips. The reason for this is that some versions are hybrid, making
use of coprocessor instructions FILD/FISTP or MMX if available to do 8-byte
aligned copies/moves/sets, for a large value of the 3rd parameter. 8-byte
moves are faster than 4-byte moves, I have timed it myself.

Why use inline assembler if it is slower on various computers? memcpy(),
memmove() and memset() have the advantage also that they are portable.

Stephen Howe


Stephen Howe

unread,
Jan 22, 2002, 4:37:28 PM1/22/02
to
> This last statement proves my point. That is the problem with people
> with biased views, the actual truth keeps getting in the way of their
> bias. Everyone knows that these benchmarks are totally worthless,
> AND they cause him financial loss? You can't have it both ways,
> I will take this as a slip up in your bias, and thus a confirmation of
> the value of these benchmarks.

Crud. Proves nothing. We all know the propaganda value of unchallanged
peddled lies. Some innocent programmers might end up believing them.

Stephen Howe


Stephen Howe

unread,
Jan 22, 2002, 4:42:20 PM1/22/02
to
> Thanks for your support.

Be careful who you get into bed with Peter. They may prove uncomfortable
bedfellows.

Stephen Howe


Peter Olcott

unread,
Jan 22, 2002, 4:57:20 PM1/22/02
to
This code only tests the performance of differing
COW implementations. Since I have decided
against COW, it becomes moot to my code.

--
Peter Olcott


Seeking Truth requires one to abandon all assumptions.

http://home.att.net/~olcott/FastString.html
"Stephen Howe" <SPAMstephe...@tnsofres.com> wrote in message
news:3c4dd87d$0$238$ed9e...@reading.news.pipex.net...

Stephen Howe

unread,
Jan 22, 2002, 5:08:48 PM1/22/02
to
"tom_usenet" <tom_u...@hotmail.com> wrote in message
news:3c4c5b60...@news.easynet.co.uk...

> On Mon, 21 Jan 2002 14:58:45 GMT, "Peter Olcott"
> <olc...@worldnet.att.net> wrote:
>
> >I am relatively new to C++, I have been programming in
> >C since K&R was the official standard, in my case since
> >1986.
>
> K&R C was never an official standard AFAIK, rather an ad hoc standard.

K&R was one of the official recognised source documents for the original C
standard.

Looking at current ISO C standard, it says

>>>>>>>>>>>>>>
The following normative documents contain provisions which, through
reference in this
text, constitute provisions of this International Standard. For dated
references,
subsequent amendments to, or revisions of, any of these publications do not
apply.
However, parties to agreements based on this International Standard are
encouraged to
investigate the possibility of applying the most recent editions of the
normative
documents indicated below. For undated references, the latest edition of the
normative
document referred to applies. Members of ISO and IEC maintain registers of
currently
valid International Standards.

2 ISO 31?11:1992, Quantities and units - Part 11: Mathematical signs and
symbols for
use in the physical sciences and technology.

3 ISO/IEC 646, Information technology - ISO 7-bit coded character set for
information
interchange.

4 ISO/IEC 2382?1:1993, Information technology - Vocabulary - Part 1:
Fundamental
terms.

5 ISO 4217, Codes for the representation of currencies and funds.

6 ISO 8601, Data elements and interchange formats - Information
interchange -
Representation of dates and times.

7 ISO/IEC 10646 (all parts), Information technology - Universal
Multiple-Octet Coded
Character Set (UCS).

8 IEC 60559:1989, Binary floating-point arithmetic for microprocessor
systems (previously
designated IEC 559:1989).
>>>>>>>>>>>>>>

For the current ISO C++, it says

>>>>>>>>>>>>>>
The following standards contain provisions which, through reference in this
text, constitute provisions of this International Standard. At the time of
publication, the editions indicated were valid.
All standards are subject to revision and parties to agreements based on
this International Standard are encouraged to
investigate the possibility of applying the most recent editions of the
standards indicated below. Members of IEC and ISO maintain registers of
currently valid International Standards.

2 ISO 31?11:1992, Quantities and units - Part 11: Mathematical signs and
symbols for
use in the physical sciences and technology.

3 ISO/IEC 646, Information technology - ISO 7-bit coded character set for
information
interchange.

- ISO/IEC 2382 (all parts) Information technology - Vocabulary

- ISO/IEC 9899:1990, Programming languages - C

- ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
Integrity

- ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
Coded
Character Set (UCS) - Part 1: Architecture and Basic Multilingual plane

The library described in clause 7 of ISO/IEC 9899:1990 and clause 7 of
ISO/IEC 9899/Amd.1:1995 is hereinafter called the Standard C library.
>>>>>>>>>>>>>>

So you can see that the current C++ standard rests on the 4 documents above
:-)

Stephen Howe

Peter Olcott

unread,
Jan 22, 2002, 5:33:53 PM1/22/02
to
Yet another biased view, you can't even leave
in the correct context.

--
Peter Olcott
Seeking Truth requires one to abandon all assumptions.
http://home.att.net/~olcott/FastString.html
"Stephen Howe" <SPAMstephe...@tnsofres.com> wrote in message

news:3c4ddb99$0$233$ed9e...@reading.news.pipex.net...

Peter Olcott

unread,
Jan 22, 2002, 5:36:16 PM1/22/02
to
Assumptions themselves form the antithesis of Truth.
--
Peter Olcott

Seeking Truth requires one to abandon all assumptions.
http://home.att.net/~olcott/FastString.html
"Paul E. Black" <paul....@nist.gov> wrote in message news:3C4DA806...@nist.gov...

Jacques

unread,
Jan 22, 2002, 6:27:57 PM1/22/02
to
Peter Olcott wrote:

<snip>

> The most elementary use of pointers is trivial, and I have known how
> to do this since before I learned C. The difficult case is getting the
> syntax just right, when you must pass pointers to pointers to pointers
> to functions. I was able to bypass learning this too. Merely tack an


Jeepers man, are you insane? You don't bypass learning such a major
part of the language for any reason. If first and second year university
students can wrap their heads around pointers, a professional programmer
had better be able to!

--
-----------------------------------------------
mail: curve at waveform.org, UIN: 64192061.
list: curves-kiddies-request at ethernal.org.
-----------------------------------------------

Dann Corbit

unread,
Jan 22, 2002, 6:16:11 PM1/22/02
to
"willem veenhoven" <wil...@veenhoven.com> wrote in message
news:3C4DDB52...@veenhoven.com...

> CBFalconer wrote:
> >
> > P.J. Plauger wrote:
> >
> > > Back off, Bucko. I suspect you know less about copyright
> > > law than you do about libel ...
>
> > Olcott has been PLONKED here. Saves a lot of wear and tear
> > on the modem. I made one response that tended to confirm
> > his wishes about hardware, and was then touted as a hardware
> > expert who justified his attitude for some time (which I am,
> > but he doesn't know that :-).
>
> I know, and I'm sure P.J. Plauger knows too. But please tell
> me, does anything of this have to do with the daily business
> of comp.programming?
>
> I'm sure over 80% of the posters in comp.programming has no
> idea of who P.J. Plauger is, let alone they'll get very exited
> when you mention this Olcott guy.

Anybody who does not know who P. J. Plauger is, must be the rankest sort of
neophyte. His book on the standard C library is a must have for any serious
C programmer. Same goes for his C++ library reference. Have none of the
readers of comp.programming ever read "The C/C++ Users Journal"? Where have
they been?

> A kind request to all posters from comp.lang.c++: Please strip
> comp.programming from this silly thread :)

Just plonk Olkott. He's a whinging twit, with nothing better to do than
annoy people. Every Usenet group seems to have them. Plonking isn't really
a solution, but it is still better than wasting time on them.

To the bare-threaded newbie who knows nothing:

P. J. Plauger is a highly respected individual in the C and C++ programming
arena. Olcott is a whinging-twit-wanna-be who thinks he has invented
something just like "none" in comp.graphics.algorithms thinks he has
invented the world's fastest line algorithm and JSH in sci.math thinks he
has solved FLT with simple algebra.

They [net cranks/trolls] are world class experts at annoying people into
making a response and have no special ability for anything else.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm


It is loading more messages.
0 new messages