Re: object oriented Squid ?

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

On Tue, 2 Dec 1997, Oskar Pearson wrote:

> People disagree with me. I just ignore them.
> (Linus Torvalds, regarding the use of C++ for the Linux kernel.)

Oh, that explains!
 
> Linus has been known to work through the assembly code of the kernel
> and do funny stuff like insert GOTO's to speed up the code...

Yes, that is the same kind of argument kc was making earlier: In C you can
do all sort of "funny" stuff to make yourself and others happy. The
questions is "Does Squid really need those GOTO's and assembly pieces?".
In other words, do they improve the performance by more than 1% or do they
just make us happy because we think they help?

I would be really surprised if the same Squid code written entirely in
assembly language would be more than 5% faster than the current one (or
the one in C++). With at least 10 msec disk I/Os and 100 msec network
delays, it does not make sense for me to spend time on 10 usec
improvements. There are quite a few huge pieces of Squid code where we
could save 10s (if not 100s) of msecs by using better _algorithms_, not
GOTOs.

> When you are optimising at the bytecode level you don't want things
> creating instances and destroying themselves...

Do we need bytecode level optimization? Also, things are never created or
destroyed "by themselves", even in C++.
 
> I had some interesting mail somewhere from Davem about optimisation,
> but this might be relevant: http://www.geog.ubc.ca/s_linux/mail/msg03027.html
> Basically: Davem does the 'step through assembly' thing too...

He certainly does. Has anybody measured the improvement from those
particular optimizations? How that improvement (if any) compares with
current Squid total disk and network delays?

> -------------
> From: "David S. Miller" <davem@jenolan.rutgers.edu>
> Subject: Re: while I'm nursing a kernel compile or two...
>
>
> I've read the squid sources in depth, they use every fast search trick
> in the book, some of it is really impressive. ;-) I really like the
> things they do in that code for performance.
> -------------

Great! I was afraid he would suggest to "optimize" something on the
bytecode level. His opinion supports my claim that, in case of Squid
_performance_, the algorithms matter, not the language.
 
> 1) With C you are pretty sure that your code is efficient. With C++ you can't
> really be sure.... unless you are pretty damn hot with C++ and know overhead
> values that mere mortals don't.

I have to disagree. What you are saying is that any C code is efficient,
while only good C++ code is efficient. I think one can do bad/good things
no matter what the language is. There is nothing "magic" going on in a
straightforward C++ code. The overhead is no different from C.
 
> 2) Less people know C++ so you will reduce your 'developer base'.

True. However, I was pleasantly surprised that many cool folks here on the
list, including yourself, claimed their familiarity with C++. With a good
design, one would just need to know where to "insert" a simple object into
already existing schema. This should not be to hard provided there are
examples and the code is documented.

In fact, it could be much more easier than patching the current Squid code
even for people with small C++ experience.
 
> 3) We can't put in the 'top-down' programming design needed to make squid C++
> in an effective way.

Not sure what you mean here. IMHO, the design does not depend on the
language much. The ease of its implementation and support does.

> 4) Given OS constraints we HAVE to have threads.

Do you mean one thread per client? If yes, then you will kill all the per
request pipelining there is in Squid. (Maybe it's good, I do not know!).
That is, a client will not be able to fetch data from disk/network while
the earlier portion of the data is being transmitted to the client.

You will also have to lock all your global data structures whenever you
access them. This, along with consequent deadlocks, will be a real pain to
debug!

BTW, are Unix threads standard/portable?

> I don't see how C++ can
> get around 'open' being a blocking system call.

There will be no essential difference from what we do know. You will still
use the same I/O libraries, you just will forget to close a file less
often. :)

Please note that g++ compiler is just a wrap around good old gcc ...

> I have heard yucky
> things about most threads libraries with C++... things go
> very funny.

Nobody suggests using bad/immature C++ libraries. IMHO, to switch to C++,
we do not need more libraries than Squid is already using. We could create
our own libs and APIs to enhance cooperation though.
 
Alex.

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