C is fastest
Lennart Sorensen
lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Wed Oct 14 23:29:15 UTC 2009
On Wed, Oct 14, 2009 at 06:48:40PM -0400, Rajinder Yadav wrote:
> You wrote C++ code the compiler barfed up =) .... than I am sure
> you're glad you don't need to worry about working with STL and C++
> Template classes in C.
I learned C++ before STL existed. I tried a practice ACM programming
competition at waterloo, and at the time they only supported C. I spent
a while learning which subset of C++ was legal in C. I clearly didn't
do well at all on that particular practice event, but I mostly figured
out what C supported. It didn't help that I really like the libg++
string support at the time.
> I went the other way C to C++, took a while to get use to OO
> programming. I don't think about it that much. possibly I see things
> more easily as object due to the long-term C++ exposure?
>
> I remember when I worked at Nortel as a intern( when Nortel was the
> place to be ). The server team wrote code in C only, they didn't
> understand C++ and they feared it like no tomorrow. So I get it when
> some people (not you) say they don't like C++ or any other OO
> language.
I think too many people jump on OO because it is a buzz word, not because
it is a good solution. Problems often don't map neatly into class
hierachies, so you end up having people force things into a tree anyhow
with a few hacks here and there, and the result is a mess. In java it
is mandetory it seems. Sometimes you really just have a chunk of code
to run across a huge pile of data, and no objects at all.
> We write C++ multi-thread code here at work and the last few places I
> worked they wrote multi-threaded C++ code. I don't think OO gets in
> the way of threading, just that some can't understand how to design
> and code multi-threaded apps. If you gave them C in place of C++, they
> would create the same multi-threaded mess only in C. I've written
> multi-threaded code in C++ as well as multi-thread classes, not once
> did I have to stop and say, damn this OO, it keep getting in the way,
> let me drop down to C in this code module.
Sure C isn't a solution either, but objects certainly don't help.
They just make it worse. At least the way they seem to currently be
implemented in C++.
> I mentioned RapidMind here before on a different thread. They built a
> multi-processor, multi-threaded framework for C++ programmers, it also
> harness the power for GPUs to parallelizes methods, algorithms and the
> code in general.
>
> http://www.rapidmind.net/technology.php
>
> "With RapidMind, developers continue to write code in standard C++ and
> use their existing skills, tools and processes. The RapidMind platform
> then parallelizes the application across multiple cores and manages
> its execution."
But they have to call the special library to do the heavy lifting in
parallel. It is very neat stuff though, and looks very promissing for
some types of work.
> So C++ and threading can and do work very well. Seems like Rapidmind
> is trying to let the platform take care of the parallel work to some
> extent and not have it all fall on the programmer.
Sure, you can write multithreaded code, but you have to explictly do it.
There is promising indications that functional programming languages
could automatically make parallel code for many operations without the
programmer even having to think about it, other than having to learn
to write code in a functional programming language (which may be a big
enough problem in itself).
> I saw a video from MS a year or 2 ago that talked about one of their
> small research lab trying to figure out how to parallelize code at the
> compiler level without multi-threading getting in the way of the
> programmer. The lady heading the lab was a manager type not a geek
> type, and her work did sound challenging to say the least since she
> has zero dedicated resource doing actual development work. I do know
> MS is was looking into harnessing multi-core either at the OS level or
> the compiler level, or a union of both. Their dilemma they were trying
> to avoid and why they were slow getting out of the gate was not to
> rush out with a solution to market and then handcuff the development
> community with a poorly thought out way to do this.
MS certainly is doing work on it. F# is part of that work apparently.
> They will probably do it in .NET with C# ... it seems C++ at MS
> doesn't get much hype and attention, which is a shame. The last good
> thing to come out of MS in term of C++ productivity was MFC and that
> was in 1992... 17 years ago, my goodness has it been that long.
These days the .net runtime is what 50MB? Makes the java runtime
look tiny.
Well I just saw this article a few minutes ago:
http://www.computerworld.com/s/article/342870/The_Desktop_Traffic_Jam?intsrc=print_latest
Seemed at least somewhat relevant to the topic.
--
Len Sorensen
--
The Toronto Linux Users Group. Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
More information about the Legacy
mailing list