rubyinline, etc.

By: JasonB (no.delete@this.spam.com), March 3, 2008 9:40 am
Room: Moderated Discussions
Anonymous (no@spam.com) on 3/3/08 wrote:
---------------------------
>JasonB (no@spam.com) on 3/2/08 wrote:
>---------------------------
>>nordsieck (lesprit.d@gmail.com) on 3/2/08 wrote:
>>---------------------------
>>>Precisely, but that is the whole point, isn't it?
>>
>>No, it's not -- otherwise you can say "Java is incredibly efficient" because it
>>supports native methods, and you can prove it by writing your entire program in
>>C and then having a Java main() method that just calls the C program.
>
>Strawman, no one is trying to say such a thing,

Perhaps you should have followed the thread.

Howard:

"* The overarching goal should be to make it easy to write programs that execute
efficiently on highly parallel computing systems

Of course "easy" and "efficient" are opposed goals."

David:

"python is a reasonably efficient language and it is easy"

Me:

"I don't consider an average of 50 times slower to be "reasonably efficient"."

nordsieck:

"It depends on what you are optimizing for. One really neat thing about ruby (and probably python) is that it is really easy to integrate it with c code (see rubyinline) for performance sensitive parts of a program, while maintaining the benefits of a high level language."

We were talking about programs that execute efficiently and I was pointing out to David that Python isn't exactly efficient. nordsieck seemed to think that the ability to write bits in another language had some bearing on the discussion. Of course you can write bits in another language, as I keep saying, but that is besides the point.

>they are saying that the HLLs do
>not have an efficiency problem as soon as you accept that performance critical sections belong in another language.

If your HLL requires you to write performance critical sections in another language then it does have an efficiency problem, otherwise you wouldn't feel the need to not use it for anything performance critical.

Your argument amounts to saying that a Hummer doesn't have a fuel efficiency problem as soon as you accept that you should walk everywhere.

>>The fact that a language allows you to avoid using it for the entire program doesn't
>>mean you can apply the attributes of those parts to the language itself. Most
>>languages allow you to execute code written in another languages. What is important
>>is how well the parts actually written in that language perform.
>
>And?

And, therefore, my original comment was correct.

>>>There is no payoff to have performance
>>>that isn't in the critical path.
>>
>>Well, in itself it certainly doesn't hurt, but it's also besides the point.
>
>Not if that 'wasted' performance comes at other costs..

As i said, having performance that isn't on the critical path in itself doesn't hurt. If there are other costs then obviously it may hurt. Don't forget that there are also costs associated with developing in a mixed environment.

>>My objection was that you were claiming Python and Ruby are reasonably efficient
>>not because they are, but simply because they allows you to write parts in
>>another language that is efficient.
>
>No, that is not the claim, the claim is that they are efficient enough for the
>90% non performance critical code, and that that code comes at a reduced 'cost' in a number of measurable ways.

As I said in the post nordsieck first responded to, "It is definitely efficient enough for a whole bunch of tasks, just like a classic Pentium running C code is".

If I did misunderstand the claim then it seems that you guys are merely repeating what I stated in my very first post; Python isn't very efficient, but it often doesn't matter. Obviously there is an option to simply not use it for the critical bits, but that doesn't change the observation.

>>>There is a definite benefit to using high level
>>>languages as a default in terms of increased flexibility to iterate, as well as
>>>decreased line count (and hence decreased maintenance cost).
>>
>>I actually think those are overstated.
>
>So what? I manage a rather large software project, multi-year, 90% in python, I actually think you have never tried.

I have never tried managing a large software project in Python, no. I have managed products with over a million LOC for over ten years now, some written in Pascal, some in x86 assembler, but all the new stuff written in C++.

I have spent time learning Python because I am thinking of using it as a macro language for end users of our software. It seems OK for that and is reasonably easy to integrate into C++. I was also interested to see what features it had that would explain the productivity gains I've seen mentioned and everything I saw suggested that the people making those claims weren't all that experienced in C++.

>>Iteration times: a simple change of code and a recompile of our software to reflect
>>that change takes about 10 seconds, because only the affected unit needs to be recompiled
>>and the program isn't very large to relink -- yet this program is still much
>>bigger than anything I would contemplate in a scripting language. With Edit and
>
>That would be because you dont have a clue - because you have not tried. I assume
>you think Chinese is not a good spoken language, because you do not use it also?

Bizarre assumption. Ni hou ma?

>>Continue it is even possible to change the source code while debugging and continue
>>on, although I normally don't use that -- once you've realised what the problem
>>is there is often little point in continuing rather than starting again.
>>
>>Line count: I just don't see it. Python and C++ have very similar line counts,
>
>Wrong, we find the ratio to be about 1:3, and we use very good C++ programmers.

OK, explain the difference, then. How do you average three lines of C++ code per line of Python code when their syntax is practically 1:1?

I look at examples like http://www.dmh2000.com/cjpr/cmpframe.html and I think to myself "That's not even idiomatic C++, let alone C++ written by someone who knows what they're doing!" Even then, he can barely make it 1.7:1, despite having over twice as many lines of comments in the C++ version.

>making C++ do its 'nice' stuff is wordy, templates are complex - shall I bring up
>the joys of debugging them or the joys of their compiler errors?

Sounds like you need good tools. Also, one of the things I like most about C++ is that doing nice stuff is concise; if you're finding it "wordy" then you're programming it like a Java programmer.

>>with differences being caused by things as trivial as }'s on empty lines. Each language
>>has a few standard features that the other lacks that can swing an individual program
>>one way or the other, but we're not talking about a huge difference here, and most
>
>We are, but I can see that you have not tried - perhaps you should, or perhaps
>not, depends on your applications I guess.

Perhaps some concrete examples would be nice to highlight what I've overlooked.

>>of the work in writing software is not in the physical typing in of the code.
>
>Not, its in the mental tracking of the operation, HLLs enhance that, sometimes significantly.

Well, in our case, it's the R&D required to figure out how to implement a feature that we want to include; but a nice HLL with sophisticated abstraction facilities and the ability to tell me at compile time if I've made a mistake is very useful.

>>Furthermore, static typing does allow a whole class of bugs to be caught
>>at compile time that wouldn't be visible unless you happened to trigger them at runtime otherwise.
>
>True, it also comes at a high complexity and implementation cost for many applications - a tradeoff, like many others.

If your typing system is adding to your complexity then you're doing it wrong.

In a correct program the only difference is that in a statically-typed language you have to tell the compiler at the point of declaration that you know what the type is. You're providing additional information that the compiler can use to check correctness, just like pre- and post-conditions, invariants, and "const" declarations -- invaluable in large systems.

In an incorrect program you are very likely to get a compile-time error in a statically-typed language, and you just have to hope that your test cases trigger the error in a dynamically-typed language.

>>C++ does have greater scope for writing lousy programs, of course. I prefer not to use this ability. :-)
>
>ah, I see, you easily write perfect code, good for you, many dont.

So what? There's a reason I'm looking at Python and not C++ for end users; not everyone is a skilled programmer, they just want to do a little customisation. That doesn't mean I should make our development decisions on the same basis.

>>>To restate, machine efficiency is only valuable in certain cases. Developer efficiency is valuable in all cases.
>>
>>To restate: attributes can only be given to a language when they are a property
>>of that language, not when they are "inherited" by the language's ability
>>to combine programs with code written in another language. Pretty much all
>>languages allow that, rendering comparisons meaningless.
>
>Lucky that is not the point here, but you hug your strawman nice and tight, hopefully it will keep you warm and safe.

I've obviously hit a nerve.

>C++ is good for some applications, python is good for some applications.

As I said right at the beginning. A classic Pentium is fine for plenty of applications as well.

>In my
>experience the total mass of the second far exceeds that of the first, however neither
>language is in any way 'better' than the other.

I have no idea what the "total mass" of applications might be, but I do know that a lot of people use Python or something similar in their C++ applications for the same reason that I want to -- to allow non-technical people some ability to alter the behaviour of the software. Whether you see the latest 3D game as a Python program with performance critical "bits" written in C++, or as a C++ program with some scripting ability for AI, etc., probably depends on your bias -- I'm definitely in the latter camp, but feel free to live in the former.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Multicore is unlikely to be the ideal answer.Anders Jensen2008/02/14 04:24 AM
  And the links..Anders Jensen2008/02/14 04:25 AM
    Disappointing..Linus Torvalds2008/02/14 10:17 AM
      Disappointing..Mark Roulo2008/02/14 11:03 AM
        LOL (NT)Linus Torvalds2008/02/14 05:43 PM
      Disappointing..David Patterson2008/02/15 11:53 AM
        Disappointing..Linus Torvalds2008/02/15 05:01 PM
          Disappointing..anon2008/02/15 08:54 PM
            Disappointing..JasonB2008/02/19 07:45 PM
          Disappointing..Ilya Lipovsky2008/02/22 06:27 PM
          Disappointing..Scott Bolt2008/03/16 11:36 AM
        Need for new programming languagesVincent Diepeveen2008/02/19 06:18 AM
          Need for new programming languagesPete Wilson2008/02/24 11:41 AM
        Disappointing..Zan2008/02/25 10:52 PM
      Disappointing..Robert Myers2008/02/19 09:47 PM
        Disappointing..Fred Bosick2008/02/22 06:38 PM
          Disappointing..Robert Myers2008/03/01 01:17 PM
        The limits of single CPU speed are here.John Nagle2008/03/14 10:55 AM
          The limits of single CPU speed are here.Howard Chu2008/03/15 01:02 AM
            The limits of single CPU speed are here.slacker2008/03/15 08:08 AM
              The limits of single CPU speed are here.Howard Chu2008/03/17 01:47 AM
                The limits of single CPU speed are here.slacker2008/03/17 10:04 AM
    And the links..Howard Chu2008/02/14 12:58 PM
      I take some of that backHoward Chu2008/02/14 01:55 PM
      And the links..Jesper Frimann2008/02/14 02:02 PM
      And the links..Ilya Lipovsky2008/02/15 02:24 PM
        And the links..iz2008/02/17 10:55 AM
          And the links..JasonB2008/02/17 07:09 PM
            And the links..Ilya Lipovsky2008/02/18 01:54 PM
              And the links..JasonB2008/02/18 10:34 PM
                And the links..Thiago Kurovski2008/02/19 07:01 PM
                  And the links..iz2008/02/20 10:36 AM
                And the links..Ilya Lipovsky2008/02/20 03:37 PM
                  And the links..JasonB2008/02/20 06:28 PM
        And the links..JasonB2008/02/17 06:47 PM
          And the links..Ilya Lipovsky2008/02/18 02:27 PM
            And the links..JasonB2008/02/18 10:00 PM
              And the links..JasonB2008/02/19 03:14 AM
              And the links..Ilya Lipovsky2008/02/20 04:29 PM
                And the links..JasonB2008/02/20 06:14 PM
                  And the links..Ilya Lipovsky2008/02/21 11:07 AM
    And the links..Howard Chu2008/02/14 01:16 PM
      And the links..Jukka Larja2008/02/15 03:00 AM
      Berkeley View on ParallelismDavid Kanter2008/02/15 11:41 AM
        Berkeley View on ParallelismHoward Chu2008/02/15 12:49 PM
          Berkeley View on ParallelismDavid Kanter2008/02/15 03:48 PM
            Berkeley View on ParallelismHoward Chu2008/02/17 05:42 PM
              Berkeley View on Parallelismnick2008/02/17 09:15 PM
                Berkeley View on ParallelismHoward Chu2008/02/18 04:23 PM
                  Berkeley View on Parallelismnick2008/02/18 10:03 PM
                    Berkeley View on ParallelismHoward Chu2008/02/19 01:39 AM
                  Berkeley View on Parallelismrcf2008/02/19 12:44 PM
                    Berkeley View on ParallelismHoward Chu2008/02/19 03:25 PM
              Average programmersanon2008/02/18 12:40 PM
        Berkeley View on ParallelismJasonB2008/02/15 08:02 PM
        Berkeley View on ParallelismJasonB2008/02/15 08:02 PM
          Berkeley View on ParallelismDean Kent2008/02/15 08:07 PM
          Berkeley View on ParallelismRay2008/02/20 03:20 PM
            Berkeley View on ParallelismJasonB2008/02/20 06:11 PM
              Berkeley View on ParallelismFritzR2008/02/24 03:08 PM
          rubyinline, etc.nordsieck2008/02/22 03:38 PM
            rubyinline, etc.JasonB2008/02/23 05:53 AM
              rubyinline, etc.nordsieck2008/03/02 01:40 AM
                rubyinline, etc.Michael S2008/03/02 02:49 AM
                  rubyinline, etc.Dean Kent2008/03/02 07:41 AM
                    rubyinline, etc.Michael S2008/03/02 08:19 AM
                      rubyinline, etc.Dean Kent2008/03/02 08:30 AM
                        rubyinline, etc.JasonB2008/03/02 05:26 PM
                rubyinline, etc.JasonB2008/03/02 06:01 PM
                  rubyinline, etc.Anonymous2008/03/03 02:11 AM
                    rubyinline, etc.JasonB2008/03/03 09:40 AM
                      rubyinline, etc.Foo_2008/03/09 09:59 AM
                        rubyinline, etc.JasonB2008/03/10 01:12 AM
                        rubyinline, etc.Gabriele Svelto2008/03/10 02:22 AM
                          rubyinline, etc.JasonB2008/03/10 04:35 AM
                            C++ for beginnersMichael S2008/03/10 05:16 AM
                              C++ for beginnersJasonB2008/03/10 06:35 AM
                          C++Michael S2008/03/10 04:55 AM
                rubyinline, etc.Linus Torvalds2008/03/03 11:35 AM
                  rubyinline, etc.Dean Kent2008/03/03 02:35 PM
                    rubyinline, etc.JasonB2008/03/03 03:57 PM
                      rubyinline, etc.Dean Kent2008/03/03 08:10 PM
                        rubyinline, etc.Michael S2008/03/04 01:53 AM
                          rubyinline, etc.Dean Kent2008/03/04 07:51 AM
                            rubyinline, etc.Michael S2008/03/04 08:29 AM
                              rubyinline, etc.Dean Kent2008/03/04 08:53 AM
                                rubyinline, etc.Michael S2008/03/04 11:20 AM
                                  rubyinline, etc.Dean Kent2008/03/04 02:13 PM
                                    read it. thanks (NT)Michael S2008/03/04 04:31 PM
                  efficient HLL'sPatrik Hägglund2008/03/04 03:34 PM
                    efficient HLL'sWes Felter2008/03/04 09:33 PM
                      efficient HLL'sPatrik Hägglund2008/03/05 01:23 AM
                        efficient HLL'sMichael S2008/03/05 02:45 AM
                          efficient HLL'sWilco2008/03/05 05:34 PM
                            efficient HLL'sHoward Chu2008/03/05 07:11 PM
                              efficient HLL'sWilco2008/03/06 02:27 PM
                    efficient HLL'sanon2008/03/05 08:20 AM
      And the links..Groo2008/02/17 04:28 PM
        And the links..Vincent Diepeveen2008/02/18 02:33 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell green?