[hcs-d] learning C++
gprice at post.harvard.edu
Wed Apr 6 16:31:40 EDT 2011
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.
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:
> 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:
>> Cyclicly yours,
>> hcs-discuss mailing list
>> hcs-discuss at lists.hcs.harvard.edu
More information about the hcs-discuss