Re: object oriented Squid ?

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 1 Dec 1997, k claffy wrote:

> i don't code
> but i engage in the dynamics enuf coding projects
> and my impression
> is that c++ is way cool
> if you're willing to spend the effort
> and are more interested in a software engineering endeavor
> than a high performance code

I can seriously bet one month free work for NLANR that there is no big
project like Squid that will be really more efficient in C than in C++ if
done properly.

There is practically nothing in C that cannot be done in C++ with exactly
the same overhead. This was the core axiom used by Stroustrup when he
designed the C++ language: you do not pay for what you do not use. On the
other hand, there are some things in C++ that make the development much
easier and faster, especially when it is done by a group of people.

The opposite opinion about C++ performance does exist. However, IMHO, it
was created mostly by people who tried to switch to OO programming by
reading "C++ for dummies in two weeks" books, and they simply did not know
what they were doing. It was an easy way for them to explain why they
would not learn OO stuff.

> but i get the impression
> that c++ can really cost you
> in terms of what's happnening in the
> 'protected' (*cough*) chassis part
> which has been canonically-implemented
> by folks more interested in language
> than performance

There is no "protected" part you are forced to use. Actually, I can think
of only one currently supported feature of C++ that is kind of "protected"
_and_ might be less efficient than a brute force, namely "exception
handling" (and only few people care about performance when a system is
crashing, or something else goes wrong once in a long while).
 
> so folks who needed performance
> have often found themselves
> having to rip up the c++ internals (eg event handling)
> to sustain the thruput etc they need

As far as I know, event handling in C++ is a simple function call with a
first parameter being a "this" pointer to the object. I am not sure how
they could "optimize" a standard C function call (by storing an equivalent
of "this" pointer in a global table and then doing a lookup??).

One can argue that another great C++ feature, virtual functions, are
"heavy". However, I bet that in most cases Squid already uses them!!
(look at all those pointers-to-handlers in data structures and function
parameters...). And a C++ compiler will probably handle same (but
"protected") pointers at _least_ as efficiently as a C compiler would
handle a "public" pointer-to-function. (with a smaller probability of
having a garbage there). Finally, you should not use virtual functions
when they are not needed, of course.

> (which takes Even More Very Dedicated Coding...

This should never happen, of course.

> that worries me
> and until i hear real-life ISP-code
> experience narratives o/w
> i'm inclined to paranoia

You won't hear them in the nearest 5 years, I guess, because software
companies are not ready to switch to C++ yet on a big scale. There are not
enough engeneers/programmers yet (colleges started teaching C++ only a few
years ago...).

Waiting for them is probably the same as writing in Cobol or Fortran just
because the majority of new programs are still being written using those
languages.

> since itfa i do need this stuff to work at a
> bizzy bizzy NAP sometimes

It will.

> and as you've all re-re-re-re-noted
> we don't have lots of DW's to spare

Very true, but this is a separate issue. That is why switching to C++
could be done gradually without terminating or slowing down any current
projects. In a long run (3-4 months?), it could even save DW's time
because people will be able add new features to Squid with less DW's
intervention by adding new "dynamic" modules to a re-designed Squid in a
plug-in fashion. You can look at the example of how this is being done
with Apache HTTP server (still written in C, but designed, in part, to
support a collaborative effort.)

> further disambiguation: i'm in a bind (npi)
> cause we'd Like to support squid coding ad infinitum
> but ...
> we need to focus Lots more on
> Internet architecture and globally commercial viability
> (and more elegant integration with dns, security,
> multicast, isp-compatible pricing, bgp-NG,
> hit-metering, URNs (if they ever decide to exist),
> optimal server location, robust interoperability,
> cache-traffic-flow level routing/traceroute/diagnostic/debugging)
> rather than software coding/support/tweaks
> than we have so far

The number and complexity of various new features to be added to Squid is
one of the major arguments for "tuning" Squid so it can be
modified/enhanced faster and easier. C++ is a nice way to achieve that.

Implementing your list of features will require a lot of coding _anyway_.
Why not to invest in something that will make that coding/debugging
faster, saving your efforts in a few months?

 
I am sorry if I sound too "nervous". This is just because you have touched
something I know and love very much... I do understand that there is no
way I can _prove_ that having Squid moved gradually to a better language
will help a lot. I also understand that I am in a minority here, and
trying to convince your boss to invest in something that _may_ payoff
later is a crazy idea... :)

Thank you,

Alex.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:44 MDT