[hcs-d] learning C++

Zak Stone zstone at gmail.com
Wed Apr 6 16:37:56 EDT 2011


Thanks for the quick feedback from both of you. Returning to the
original subject of this thread, then, would you advise people who are
considering making the investment to master C++ to stick with pure C
and a higher-level wrapper language such as Python unless they truly
have specialized needs?

Zak


On Wed, Apr 6, 2011 at 4:31 PM, Greg Price <gprice at post.harvard.edu> wrote:
> I think that's a good general-purpose approach. It's basically what
> Quora (my company) does. Minus the part about Cython, it's basically
> been conventional wisdom in the Python world for some time.
>
> I am looking forward to PyPy (http://pypy.org) making step 3 much less
> frequently necessary, by making the pure Python code faster --
> bleeding-edge early adopters can use it in 2011, and I think the
> mainstream will be able to use it around 2013.
>
> I don't think it eliminates cases where it makes sense to write in C++
> or Java or C in the first place, in specialized circumstances.
>
> Greg
>
>
> On Wed, Apr 6, 2011 at 13:21, Zak Stone <zstone at gmail.com> wrote:
>> Hello again,
>>
>> In hopes of heading off a flame war, let me provide a bit more
>> context. I'm impressed with Cython [ http://cython.org/ ], a project
>> that attempts to make Python and C integration as smooth as possible.
>> It seems to me that tools such as Cython finally make the following
>> attractive development process possible:
>>
>> 1. Quickly prototype a system in Python with a minimal amount of code.
>>
>> 2. Run the system with real data and profile it.
>>
>> 3. Rewrite the performance-critical sections in Cython or C.
>>
>> 4. Return to Step 2 and repeat until system performance is satisfactory.
>>
>> The advantage I perceive to this development process is that it should
>> converge to a correct, high-performing solution with a minimal amount
>> of code in a minimal amount of developer time with a minimal amount of
>> system complexity, which should then make future modifications easier.
>>
>> Naively, it seems that a Python/Cython/C system produced by the
>> development process above could be strictly preferable to one produced
>> from scratch in either C++ or Java. Earlier comments suggest that C++
>> and Java are currently popular for their combination of speed and
>> resistance to memory bugs, but the integration of C in
>> performance-critical regions of a Python/Cython/C system should
>> address the speed issue, and the use of Python and Cython everywhere
>> else should make memory issues rare and easy to isolate in small
>> stretches of C code.
>>
>> Have we reached the stage where the development process above is
>> reasonable even for very large projects, or is it still absolutely
>> necessary to start from scratch in something like C++ or Java?
>>
>> For those of you who are curious, here is the original thread that I quoted:
>>
>> http://www.mail-archive.com/numpy-discussion@scipy.org/msg30470.html
>>
>> Thanks,
>> Zak
>>
>>
>> On Wed, Apr 6, 2011 at 4:12 PM, William Josephson <wkj at post.harvard.edu> wrote:
>>> On Wed, Apr 06, 2011 at 12:37:52PM -0700, Greg Price wrote:
>>>> > This is more or less bunk. ?Some time back Brian Kernighan showed me
>>>> > a small benchmark he had written in which C++ loses pretty handily to
>>>> > Java and a number of scripting languages. ?C++ is bloated and slow and
>>>> > memory corruption is still common enough.
>>>>
>>>> I don't know what this benchmark is or how the C++ code in question
>>>> was written, but this is not a common result. As for memory
>>>
>>> Umm...awk beats C++ STL sort.  What's impressive is that C++ STL
>>> loses to Python and awk.  A big problem with C++ is that its idea
>>> of polymorphism is rampant inlining and generation of almost identical
>>> code.  The result is blown I-caches.  Take a look at the recent
>>> work on a new ld at Google by Ian Lance Taylor to see what I mean.
>>>
>>> C++ is an archaic mess.  It may still be a marketable skill, but
>>> otherwise learn C (not C++) and move on.
>>>
>>>> corruption, the way you write the code is critical. If you use
>>>> pointers and arrays the same way as you would in C, of course memory
>>>> corruption bugs are just as likely. If you systematically use
>>>> abstractions like Boost shared pointers or scoped pointers, you are
>>>> much better off in that respect.
>>>
>>> Poor man's GC is still not GC.  Here's a dime...buy a real language :-)
>>>
>>> I say this as someone who has used AWK to generate templates to
>>> implement continuation passing in C++ to schedule concurrent code
>>> for cache locality.
>>>
>>> On a related note, have a gander at this:
>>>        http://www.scs.stanford.edu/~dm/home/papers/c++-new.html
>>>
>>> Cyclicly yours,
>>>
>>>  -WJ
>>> _______________________________________________
>>> hcs-discuss mailing list
>>> hcs-discuss at lists.hcs.harvard.edu
>>> https://lists.hcs.harvard.edu/mailman/listinfo/hcs-discuss
>>>
>>
>


More information about the hcs-discuss mailing list