C is fastest

[Rajinder Yadav]

Lennart Sorensen wrote:
> 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

That was a stimulating read, I got to read up more on Win7 multi-core support 
and 'User Mode Scheduling', only because the company I work for happens to 
produce a virus scanner and this could greatly improve the performance of this 
product.

> 
> Seemed at least somewhat relevant to the topic.
> 

-- 
Kind Regards,
Rajinder Yadav

http://DevMentor.org
Do Good ~ Share Freely
--
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