[bittorrent] Introductory/endgame algorithms
bill at viasic.com
Fri Sep 30 09:55:23 EDT 2005
On Fri, 2005-09-30 at 11:51 +0200, Olaf van der Spek wrote:
> On 9/30/05, Bill Cox <bill at viasic.com> wrote:
> > On Fri, 2005-09-30 at 10:05 +0200, Olaf van der Spek wrote:
> > > On 9/30/05, Elliott Mitchell <ehem at m5p.com> wrote:
> > > > >From: Olaf van der Spek <olafvdspek at gmail.com>
> > > > > On 9/30/05, Elliott Mitchell <ehem at m5p.com> wrote:
> > > > > > > http://libtorrent.rakshasa.no/
> > > > > >
> > > > > > Unfortunately two issues here. First, http://libtorrent.sourceforge.net/,
> > > > > > there is already a library of the same name out there. Second, despite
> > > > > > claims to the contrary, the world is not ruled by C++, quite a few new
> > > > > > things are written in C. Just because you're using C, doesn't mean you
> > > > > > aren't doing OO (sorry, rant time there).
> > Ditto on the rant. Actually, most commercial code is still written in
> > C, and for good (although debatable) reasons.
> What's the source of that statement?
Good question. It's well documented that Microsoft has the largest
market share with Visual C++, but most companies I know of use it
primarily for it's C compiler. The exception is GUI, which is generally
done with MFC.
Internally, Microsoft does most of it's coding in C. Multiple friends
of mine who are in positions to know have stated this. This directly
contradicts this link:
So, for example, Windows XP certainly is mostly C. The author is giving
credit for any application developed with Visual C++ as a C++
application, which is certainly not the case. Each application listed
by this link where I know how the code was written is listed
I think Microsoft is not leaking market data about computer languages.
They probably don't want to appear as supporting one language over
another. So, exact data is probably hard to find.
However, from personal experience, C is still the dominant commercial
development language. Of course, my life in EDA skews my perceptions.
For example, I've never seen a line of Cobal.
> > > > > But what's the reason to use C instead of C++ in that case?
> > > > Slightly better performance.
> > Other reasons exist if you're doing a multi-programmer project.
There's a good reason C sucks yet is still the right choice for large
projects. C is simple. That's why it sucks. That's also why it's
right for large teams.
Here's a more detailed list:
-- Big teams have less-than-average programmers. Less than average
programmers will never understand multiple inheritance, templates, and
other cool C++ features. Your code will break when these guys edit it.
Therefore, large C++ projects are doomed. The exception is really cool
companies that only hire really good programmers. Think Google, and
-- C++ as a language and as a coding culture naturally supports many
different coding styles. Success in a group greatly depends on choosing
one, which has been very difficult, as C++ programmers usually feel
strongly about their programming style and the freedom that C++ gives
-- Large projects usually involve a common database of some sort. While
C++ is great for GUI, since data structures tend to be simple
inheritance trees, it has no features to help write databases. For
example, try representing a circuit in a database. C++ classes do it
just fine. Now, try to write a tool that uses it: the data is already
loaded when the tool runs (that's the point of a common database), and
the tool needs to add it's own fields to the circuit elements so it can
do it's work. How do you do that? Inheritance doesn't work, since that
would extend all the objects in the database for every tool that used
it. You need the fields to be allocated dynamically, the way Python
does it. In C++, you're forced to use cross-pointing void pointers with
-- Large projects usually have complicated data structures, not just the
simple inheritance tress common in GUIs. C++ sucks at representing even
simple directed graphs, since it insists on inheriting functionality one
class at a time. C++ is so weak at representing graphs, there are no
reusable graph classes available from any source I've been able to find,
except where the reuse is based on nothing better than what I would do
in C: callback functions and a C API and some void pointers on objects.
That's not what I call reusable code.
I complain about this a lot since I'm and EDA programmer, and I write
the same stupid graph traversals about once a week. Graph Theory may be
the single most important branch of computer science, yet C++ has no
reusable graph based code. OTOH, neither do many languages. Java
actually passes this test, and has reusable graph packages based on
interfaces. One major difference that allows Java to beat C++ here is
how iterators are handled. In C++ (unlike Java), iterators are objects
with a specific size, allocated on the stack. To instantiate one, you
have to know the exact class, not an abstract class. In Java, iterators
have an interface, you don't know their implementation when you use
them. They're polymorphic. C++ iterators aren't. You can do a think
called "virtual iterators" in C++, but then you might as well just go
program in Lisp, since nothing's typed and nothing's checked, and the
speed is similar to an interpreter.
-- C++ forces header files to change as you write code, since class
methods are declared in a single header file per class, even if they are
private, causing everyone else in your group to have to recompile their
code. This hostile cooperation environment leads programmers to update
from CVS/SVN rarely, which leads to other problems.
-- C++ is so complex, that there is no compiler that fully complies with
the standard. Thus, C++ code developed by large teams is only portable
once it has been ported, and only to the compilers to which it was
ported. Individuals familiar with porting can write portable code, but
again, large teams will not be made up entirely of such people. C is
hard to write in a portable way. C++ is harder.
> > > Why (if you write equivalent code)?
> > It runs just as fast then. We just have to avoid features, like virtual
> > functions, in critical code. I find that in very critical code, I even
> > have to avoid some C features such as structures, which organize data
> > very poorly for cache performance.
> But what part of your code is (highly) performance critical?
In BitTorrent, nothing. Perhaps I'd want more speed if I was writing a
client that was meant to work over a super-high-speed connection in many
simultaneous torrents. Otherwise, Java bytecode is fast enough.
However, in EDA programming, speed is always crucial, in many inner
loops, since we keep having to build chips that are proportional in size
to our CPU's speed. You can call it "Bill's Law". EDA has been, and
will continue to be a speed and memory hog, so long as More's Law holds.
Basically, designing the next generation of chips using the last
generation is hard.
Speed is also critical in many DSP applications, but C++ is hardly used
for this application.
Don't get me wrong, I'm generally a fan of C++. However, there are
reasons not to use it, particularly in a group development environment.
Thus, we see new languages like C# and D. However, an open-source
application with one author and one compiler (g++) should feel free to
use C++ or any other language that suits the author. Most of the
open-source C code I've read has been worse than code written in just
about any other language. Basically, C sucks, and we're stuck using it.
More information about the BitTorrent