Re: Python speed vs csharp

Discussion in 'Python' started by Greg Brunet, Aug 1, 2003.

  1. Greg Brunet

    Greg Brunet Guest

    "Mike" <> wrote in message
    news:...
    > Bear with me: this post is moderately long, but I hope it is

    relatively
    > succinct.
    > ...
    > This is an error function approximation, which gets called around 1.5
    > billion times during the simulation, and takes around 3500 seconds

    (just
    > under an hour) to complete. While trying to speed things up, I created

    a
    > simple test case with the code above and a main function to call it 10
    > million times. The code takes roughly 210 seconds to run.
    >
    > The current execution time is acceptable, but I need to increase the
    > complexity of the simulation, and will need to increase the number of

    data
    > points by around 20X, to roughly 30 billion. This will increase the
    > simulation time to over a day. Since the test case code was fairly

    small, I
    > translated it to C and ran it. The C code runs in approximately 7.5
    > seconds. That's compelling, but C isn't: part of my simulation

    includes a
    > parser to read an input file. I put that together in a few minutes in
    > Python, but there are no corresponding string or regex libraries with

    my C
    > compiler, so converting my Python code would take far more time than

    I'd
    > save during the resulting simulations.
    > ...
    > Surprisingly (to me, at least), this code executed 10 million

    iterations in
    > 8.5 seconds - only slightly slower than the compiled C code.
    >
    > My first question is, why is the Python code, at 210 seconds, so much
    > slower?
    >



    I'm just a little curious how test code runs 10 million cycles in 210
    seconds, while production code with runs 1.5 billion cycles in 3500
    seconds. That makes your production code more efficient by roughly a
    factor of 10. If so, even though folks are only quoting an improvement
    factor of about 3x for Pysco and 5-6x with Pyrex, that may be sufficient
    enough for your needs.

    --
    Greg
     
    Greg Brunet, Aug 1, 2003
    #1
    1. Advertising

  2. Greg Brunet

    Mike Guest

    On Thu, 31 Jul 2003 22:25:55 -0500, Greg Brunet wrote:

    > I'm just a little curious how test code runs 10 million cycles in 210
    > seconds, while production code with runs 1.5 billion cycles in 3500
    > seconds. That makes your production code more efficient by roughly a
    > factor of 10. If so, even though folks are only quoting an improvement
    > factor of about 3x for Pysco and 5-6x with Pyrex, that may be sufficient
    > enough for your needs.


    Ugh. Because I can't be trusted with a calculator, that's why. 1.5 billion
    should be 150 million. The elapsed times are correct: 210 seconds and 3500
    seconds.

    Using psyco, the test case runs in 43 seconds. I was able to reduce that to
    25 seconds using some of the improvements that Bengt Richter provided. I
    was able to reduce the full simulation time down to 647 seconds; I'm sure
    more improvements are possible, since I haven't implemented all of Bengt's
    improvements. Part of the problem with the full simulation is that psyco
    gobbles up all my available memory if I use psyco.full(), so I've been
    experimenting with psyco.bind(). 647 seconds is my best result so far.

    -- Mike --
     
    Mike, Aug 2, 2003
    #2
    1. Advertising

  3. Mike wrote:

    > Ugh. Because I can't be trusted with a calculator, that's why. 1.5 billion
    > should be 150 million. The elapsed times are correct: 210 seconds and 3500
    > seconds.



    I cannot see your original message except on google:

    Hi:


    I am sure you know what you are after, but Python for numerical
    computations is more or less crap. Not only has Python a crippled
    syntax it is most of the time dog slow and unpredictable. Python is
    more or less a fraud. But I must admit it is sometimes immensly useful
    due to its big pool of add-on libraries. But I would rather like to
    see that all the manpower gets concentrated in languages which
    deserve to be called a programming language (for example Scheme,
    CommonLisp, Ada, C++,..).

    I am not sure what exactly are your simulation problems and
    requirements but the Bigloo (Scheme) compiler is very robust and I use
    it every day for numerical computations. I once used Python but
    quickly stopped using it and I have never looked back.

    For example Bigloo lets you specify types. It is easy to specify types
    in Bigloo and the code is transportable even, provided you write a
    small macro where the compiler decides wheter it is Bigloo or
    not. Normally, giving types in Bigloo puts you in the range of "only 2
    times slower than C"; also for heavy numerical computations. The
    following small Scheme program sums up your error function 10^6
    times. Also included a C program. The timings on a simple Celeron
    laptop are as follows:

    g++ -O3 erf.c : 0.5 seconds
    bigloo -Obench erf.scm: 1.1 seconds

    The Bigloo code could be a bit improved because I do not know wheter
    using (expn x 2.0) introduces a bottleneck in Bigloo. If there are only
    floating
    point calculations involved Bigloo is as fast as C (see
    comp.lang.scheme and my code for the Coyote Gulch benchmark; see also
    slashdot). If you have big arrays Bigloo's gap to C is shifted towards
    a factor of 2 or in hard cases 3. This is still fairly good.

    Not to cheerlead Bigloo or Scheme here. If you are pragmatic stay with
    Python it has really tons of add-on libraries and huge community.

    S. Gonzi
    ;;;;;;;;;;;;;;;;; BIGLOO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    (module erfc2
    (option (set! *genericity* #f)))

    (define (erfc x )
    (let* ((x (exact->inexact x))
    (p 0.3275911)
    (a1 0.254829592)
    (a2 -0.284496736)
    (a3 1.421413741)
    (a4 -1.453152027)
    (a5 1.061405429)
    (t (/fl 1.0
    (+fl 1.0
    (*fl p
    x))))
    (erfcx (*fl
    (*fl t
    (+fl a1
    (*fl t (+fl a2
    (*fl t
    (+fl a3
    (*fl t
    (+fl a4
    (*fl t a5)))))))))
    (exp (- (expt x 2.0))))))
    erfcx))


    (define (do-it)
    (let ((erg 0.0))
    (do ((i 0 (+fx i 1)))
    ((=fx i 1000000))
    (set! erg (+fl erg (erfc 0.456))))
    erg))

    (print (do-it))
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;;; C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    #include <stdio.h>
    #include <math.h>


    double erfc( double x )
    {
    double p, a1, a2, a3, a4, a5;
    double t, erfcx;

    p = 0.3275911;
    a1 = 0.254829592;
    a2 = -0.284496736;
    a3 = 1.421413741;
    a4 = -1.453152027;
    a5 = 1.061405429;

    t = 1.0 / (1.0 + p*x);
    erfcx = ( (a1 + (a2 + (a3 +
    (a4 + a5*t)*t)*t)*t)*t ) * exp(-pow(x,2.0));

    return erfcx;
    }

    int main()
    {
    double erg=0.0;
    int i;

    for(i=0; i<1000000; i++)
    {
    erg += erfc(0.456);
    }
    printf("%f",erg);

    return 1;
    }
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
     
    Siegfried Gonzi, Aug 3, 2003
    #3
  4. Siegfried Gonzi wrote:

    Only for the sake of completeness. My last version had a minor
    bottleneck. The following Bigloo version is as fast as C .

    Suming up your erfc function 10^6 times:

    new version: 0.5 seconds
    C version: 0.5 seconds

    As I wrote giving types in Bigloo renders code effectively. It has also
    the advantage that the compiler becomes very picky and spots a lot of
    type errors; Bigloo is as OCaml for example then. If you do not give
    types Bigloo is as forgiving as what you would assume from Scheme.

    S. Gonzi
    ===== NEW VERSION =====
    (module erfc2
    (option (set! *genericity* #f)))

    (define (erfc::double x::double )
    (let* (
    (x::double (exact->inexact x))
    (p::double 0.3275911)
    (a1::double 0.254829592)
    (a2::double -0.284496736)
    (a3::double 1.421413741)
    (a4::double -1.453152027)
    (a5::double 1.061405429)
    (t::double (/fl 1.0
    (+fl 1.0
    (*fl p
    x))))
    (erfcx::double (*fl
    (*fl t
    (+fl a1
    (*fl t (+fl a2
    (*fl t
    (+fl a3
    (*fl t
    (+fl a4
    (*fl t a5)))))))))
    (exp (negfl (*fl x x))))))
    erfcx))


    (define (do-it)
    (let ((erg::double 0.0))
    (do ((i 0 (+fx i 1)))
    ((=fx i 1000000))
    (set! erg (+fl erg (erfc 0.456))))
    erg))

    (print (do-it))
    ======================
     
    Siegfried Gonzi, Aug 4, 2003
    #4
  5. Siegfried Gonzi wrote:
    ...
    > I am sure you know what you are after, but Python for numerical
    > computations is more or less crap. Not only has Python a crippled


    ....Note for the unwary...:
    It's interesting that "gonzi", in Italian, means "gullible" (masculine
    plural adjective, also masculine plural noun "gullible individuals") --
    this may or may not give a hint to the purpose of this troll/flamewar:).

    Anyway, a challenge is a challenge, so:

    > times. Also included a C program. The timings on a simple Celeron
    > laptop are as follows:
    >
    > g++ -O3 erf.c : 0.5 seconds
    > bigloo -Obench erf.scm: 1.1 seconds


    Never having been as silly as to purchase such a deliberately crippled
    chip as a Celeron, I cannot, unfortunately, reproduce these timings --
    I will, however, offer my own timings on a somewhat decent CPU, an old
    but reasonably well-configured early Athlon. No bigloo here, so I
    started with the C program:

    > ;;; C ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    > #include <stdio.h>
    > #include <math.h>
    >
    >
    > double erfc( double x )
    > {
    > double p, a1, a2, a3, a4, a5;
    > double t, erfcx;
    >
    > p = 0.3275911;
    > a1 = 0.254829592;
    > a2 = -0.284496736;
    > a3 = 1.421413741;
    > a4 = -1.453152027;
    > a5 = 1.061405429;
    >
    > t = 1.0 / (1.0 + p*x);
    > erfcx = ( (a1 + (a2 + (a3 +
    > (a4 + a5*t)*t)*t)*t)*t ) * exp(-pow(x,2.0));
    >
    > return erfcx;
    > }
    >
    > int main()
    > {
    > double erg=0.0;
    > int i;
    >
    > for(i=0; i<1000000; i++)
    > {
    > erg += erfc(0.456);
    > }
    > printf("%f",erg);
    >
    > return 1;
    > }
    > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


    saved this to gonzi.c, compiled it and ran/timed it:

    [alex@lancelot swig_wrappers]$ gcc -O -o gonzi gonzi.c -lm
    [alex@lancelot swig_wrappers]$ time ./gonzi
    519003.933831Command exited with non-zero status 1
    0.37user 0.01system 0:00.39elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (107major+13minor)pagefaults 0swaps

    (that silly "return 1" must be connected to some in-joke or other...
    why's the program unconditionally returning an error-indication!?-)]

    Then I "converted" it to Python, a trivial exercise to be sure:

    import math

    def erfc(x):
    exp = math.exp

    p = 0.3275911
    a1 = 0.254829592
    a2 = -0.284496736
    a3 = 1.421413741
    a4 = -1.453152027
    a5 = 1.061405429

    t = 1.0 / (1.0 + p*x)
    erfcx = ( (a1 + (a2 + (a3 +
    (a4 + a5*t)*t)*t)*t)*t ) * exp(-x*x)
    return erfcx

    def main():
    erg = 0.0

    for i in xrange(1000000):
    erg += erfc(0.456)

    print "%f" % erg

    if __name__ == '__main__':
    main()

    and ran that:

    [alex@lancelot swig_wrappers]$ time python gonzi.py
    519003.933831
    5.32user 0.05system 0:05.44elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (473major+270minor)pagefaults 0swaps

    then I put a huge effort into optimization -- specifically, I inserted
    after the "import math" the two full lines:

    import psyco
    psyco.full()

    [must have taken me AT LEAST 3 seconds of work, maybe as much as 4] and
    ran it again:

    [alex@lancelot swig_wrappers]$ time python gonzi.py
    519003.933831
    0.15user 0.02system 0:00.24elapsed 69%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (547major+319minor)pagefaults 0swaps

    There -- optimized Python over twice as fast as optimized C in terms of
    user-mode CPU consumption, almost twice as fast in terms of elapsed time
    (of course, using programs as tiny and fast as this one for such purposes
    is not clever, since they run so fast their speed is hard to measure,
    but "oh well"). No need to declare types, of course, since psyco can
    easily infer them.


    Of course, there IS a "subtle" trick here -- I write x*x rather than
    pow(x,2.0). Anybody whose instincts fail to rebel against "pow(x,2.0)"
    (or x**2, for that matter) doesn't _deserve_ to do numeric computation...
    it's the first trick in the book, routinely taught to every freshman
    programmer before they're entrusted to punch in the first card of their
    first Fortran program (or at least, so it was in my time in university,
    both as a student and as a professor).

    Correcting this idiocy in the C code (and removing the return 1 since
    we're at it -- return 0 is the only sensible choice, of course:) we
    turn C's performance from the previous:

    [alex@lancelot swig_wrappers]$ time ./gonzi
    519003.933831Command exited with non-zero status 1
    0.37user 0.01system 0:00.39elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (107major+13minor)pagefaults 0swaps

    to a more respectable:
    [alex@lancelot swig_wrappers]$ time ./gonzi
    519003.9338310.20user 0.00system 0:00.19elapsed 103%CPU (0avgtext+0avgdata
    0maxresident)k
    0inputs+0outputs (105major+13minor)pagefaults 0swaps

    (the "103%" of CPU being a funny artefact of my Linux kernel, no doubt).

    So, about HALF the elapsed time was being squandered in that absurd call
    to pow -- so much for Mr Gonzi's abilities as a numerical programmer:).

    With the program having been made decent, C's faster than optimized Python
    again, not in CPU time (0.20 all usermode for C, 0.15 usermode + 0.02
    systemmode for Python) but in elapsed time (0.19 for C vs 0.24 for
    Python) -- the inversion being accounted for in psyco's lavish use of
    memory and resulting pagination.

    Still, the performance ratio of psyco-optimized Python vs C on my
    machine is much better than that of bigloo vs C on Mr Gonzi's Celeron,
    and with no need for type declarations either. So much, then, for
    Mr Gonzi's claims about Python being "more or less crap"!-)


    Alex
     
    Alex Martelli, Aug 4, 2003
    #5
  6. Alex Martelli wrote:

    > Still, the performance ratio of psyco-optimized Python vs C on my
    > machine is much better than that of bigloo vs C on Mr Gonzi's Celeron,
    > and with no need for type declarations either. So much, then, for
    > Mr Gonzi's claims about Python being "more or less crap"!-)


    Oh man. I forget to tell if you comment out

    (x (exact->inexact x))

    the Bigloo version calculates things in 0.25 seconds (as compared to 0.5
    seconds of the C version).

    Okay, a lot of people have learned a lot from your post. Maybe they can
    use some techniques for their own Python programming.

    But still Python is crap. Sorry to tell you the truth. It is not only
    speed. Look if I do not use types in Bigloo it is 10 times slower than
    C. So performance is not everything; at least for me.

    But Mr. Martelli your post was very funny. It is always a pleasure for
    me to make loosers upset (yes I know your contribution to Python is huge
    especially because you are book author). Oh, man I always thought such
    individuals are just in the CommonLisp community.

    If you are pragamatic Python is okay and has a lot to offer.

    S. Gonzi
     
    Siegfried Gonzi, Aug 4, 2003
    #6
  7. Siegfried Gonzi wrote:

    > Alex Martelli wrote:
    >
    >> Still, the performance ratio of psyco-optimized Python vs C on my
    >> machine is much better than that of bigloo vs C on Mr Gonzi's Celeron,
    >> and with no need for type declarations either. So much, then, for
    >> Mr Gonzi's claims about Python being "more or less crap"!-)

    >
    > Oh man. I forget to tell if you comment out
    >
    > (x (exact->inexact x))


    ....presumably avoiding floating-point in favour of rational...

    > the Bigloo version calculates things in 0.25 seconds (as compared to 0.5
    > seconds of the C version).


    If true, this suggests unbelievably bad performance in your Celeron's
    floating-point hardware -- there's no other explanation as to why
    (software-implemented) rational arithmetic could outperform (hardware-
    implemented) float arithmetic.


    > Okay, a lot of people have learned a lot from your post. Maybe they can
    > use some techniques for their own Python programming.


    Particularly given that the Python-specific "techniques" amount (in all)
    to using a good optimizer (aka just-in-time compiler), psyco, I'm quite
    confident that many people can indeed use that. The idea of writing
    x*x instead of pow(x, 2.0) is just as good in C (as I've shown -- just
    that one change speeds up the C program by about two times) or Fortran
    (as I mentioned, it was for Fortran, over a quarter of a century ago,
    that I first learned of it) as just about any other language, so it's
    no doubt going to be even more widely applicable.


    > But still Python is crap. Sorry to tell you the truth. It is not only
    > speed. Look if I do not use types in Bigloo it is 10 times slower than
    > C. So performance is not everything; at least for me.


    Python is demonstrably more productive than lower-level languages (such
    as C) for application development, and demonstrably more acceptable to
    most programmers than languages of similar semantic level but with prefix
    rather than infix syntax. Therefore, your repeated flame-bait assertion
    that "still Python is crap", now totally unsupported, has sunk to abysmal
    levels (I don't see what more you could do to further lower your
    credibility).

    You've shown how good you are at numerical programming by coding
    "pow(x,2.0)" where any decently experienced coder would have coded
    "x*x" and thereby slowing down a whole C program by a factor of two. Now
    you show that your ability in evaluating programming languages is
    on a par with your ability in numerical programming -- unsurprising.


    > But Mr. Martelli your post was very funny. It is always a pleasure for
    > me to make loosers upset (yes I know your contribution to Python is huge
    > especially because you are book author). Oh, man I always thought such
    > individuals are just in the CommonLisp community.


    Is a "looser" somebody who is more loose (less uptight) than you, or
    somebody who looses (as in, eases, facilitates) things? Or is your
    ability at spelling on a par with your ability at numerical programming
    and language evaluation? In the latter case, you're surely reaching
    for an interesting "across the board" overall score.

    My contributions to Python have been pretty minor -- writing books is
    nice, sure, but of course it can't compare with the real contributions
    of the "core" Pythonlabs developers and those of many others. Nor did
    you make me _upset_ -- disgusted, yes, because I'm an optimist and like
    human beings in general, and it's always sad to see such a sad specimen
    as you attempt to pass itself off as a human being. As for "such
    individuals" (such as?) being "just in the Common Lisp community", what
    would that be describing? Was your working hypothesis that, when you
    post to a newsgroup about language X a flamebait about X being crap,
    accompanied by technically faulty examples in non-X languages, somebody
    will point out your idiocy only if X == "Common Lisp"? If so, then your
    understanding of Usenet is on a par with your ability at numerical
    programming, and so on -- truly, truly a sad ersatz-human being there.


    > If you are pragamatic Python is okay and has a lot to offer.


    More fodder for the "he spells as well as he programs" theory, I see.
    Not to mention that "is crap" and "is okay" are compatible only in
    the field of natural fertilizers (a field I heartily recomment you
    turn to, given your proven abilities in spewing male bovine exrement).


    Alex
     
    Alex Martelli, Aug 4, 2003
    #7
  8. Alex Martelli wrote:

    > If true, this suggests unbelievably bad performance in your Celeron's
    > floating-point hardware -- there's no other explanation as to why
    > (software-implemented) rational arithmetic could outperform (hardware-
    > implemented) float arithmetic.


    Sorry I know that the Celeron is very poor at floating point
    calculations. My stationary Pentium II 450 Mhz at my university is as
    fast as my 1000 MHz Celeron.

    So what and who cares?


    > Particularly given that the Python-specific "techniques" amount (in all)
    > to using a good optimizer (aka just-in-time compiler), psyco, I'm quite
    > confident that many people can indeed use that. The idea of writing
    > x*x instead of pow(x, 2.0) is just as good in C (as I've shown -- just
    > that one change speeds up the C program by about two times) or Fortran
    > (as I mentioned, it was for Fortran, over a quarter of a century ago,
    > that I first learned of it) as just about any other language, so it's
    > no doubt going to be even more widely applicable.


    Maybe you cannot read. But I wrote in my first post that I blindly "copy
    and pasted" the original code and that I didn't check wehter (* x x) is
    faster. This was not the point.

    Again, my intention simply was: there is more than just Python. People,
    if their time budget allows it, should investigate those alternatives.
    If they think Scheme is shit oh Lord nobody cares and nobody will impede
    them in going/comming back to Python.

    Sorry, Alex you are one of the idiots and bigots who believe that Python
    is the best since sliced bred and butter.

    When I was younger it happend that I was a similar idiot and believed
    that "functional programming" in all its glory will salvage this world.

    For me Python is crap and not any longer worth to consider. But look, I
    even introduced Python at our institution some month ago. A colleague
    asked me and I showed him Scheme. He didn't like the parantheses and I
    adviced him to buy some Python books. Indeed he did it. What is
    important here: he is happy that I am not any of this idiots who falls
    for and believes that his own programming language is the best thing.

    I will stop this discussion because I am used to discuss with people who
    can demonstrate to have at least a minimal amount of brain.

    S. Gonzi
     
    Siegfried Gonzi, Aug 4, 2003
    #8
  9. Siegfried Gonzi wrote:
    ...
    > Maybe you cannot read. But I wrote in my first post that I blindly "copy
    > and pasted" the original code and that I didn't check wehter (* x x) is
    > faster. This was not the point.


    I can read better than you can write (a criterion that is not hard to
    meet). You used neither the phrase "copy and paste" NOR the adverb
    "blindy" in your "first post" (to this thread) -- liar. What you wrote
    was quite different and "bigloo-specific":

    """
    The Bigloo code could be a bit improved because I do not know wheter
    using (expn x 2.0) introduces a bottleneck in Bigloo. If there are only
    """

    Apart from your creative innovation in mis-spellings of the poor innocent
    word "whether", it's clear that you do not know whether raising-to-the-
    power-of-two is importantly slower than multiplying-by-itself in just
    about ANY programming language -- what I keep pointing out is that the
    _C_ code would surely be improved by this tiny change (it speeds up by
    JUST two times on my machine... trifles, surely...?). This shows you're
    not an experienced coder of numerically intensive codes, period.


    > Again, my intention simply was: there is more than just Python. People,


    Nobody ever denied that. Python's own interpreter is coded in C (though
    in the pypy project we're trying to do something about that;-), so it's
    obvious to everybody that "there is more than just Python".

    Python just happens to be the best overall choice for application-level
    programming (as opposed to, say, operating system kernels, device drivers,
    and the like) in most situations. This fact stands in sharp contrast to
    your previous idiotic assertion that "it's crap" (currently softened to
    "there is more than just it", I see) -- interestingly accompanied in your
    own previous posts by the contradictory assertion that "it's okay" (if,
    that is, one is pragmatic).

    > if their time budget allows it, should investigate those alternatives.
    > If they think Scheme is shit oh Lord nobody cares and nobody will impede
    > them in going/comming back to Python.


    If they have nothing better to do with their time, investigating a huge
    variety of programming languages surely does appear a neat idea to me
    (but then, like many other computer enthusiasts, I do like programming
    languages for their own sake -- most users consider learning such tools
    a price to be paid in order to be able to solve their problems, so their
    evaluation of your suggestion may differ from mine). In the galaxy of
    programming languages, Scheme is definitely an interesting one (the
    "stalin" compiler, back when I last tried several extensively, seemed
    even faster than the "bigloo" one, but the underlying language is still
    Scheme in both cases), particularly thanks to the excellent book "SICP"
    (now freely available on the net, and very, very instructive). But if
    you do want to suggest to people that they explore other alternatives,
    you'll find out that starting out by describing their current choice
    as "crap" is definitely not the best way to "make friends and influence
    people". Your skill at that appears to match that at numerically
    intensive programming, spelling, and other fields already mentioned.


    > Sorry, Alex you are one of the idiots and bigots who believe that Python
    > is the best since sliced bred and butter.


    Assuming "bred" is meant to stand for "bread" (rather than being the
    past form of the verb "to breed", which is what one might normally
    assume;-) -- I don't particularly care for pre-sliced bread, nor for
    putting butter on my bread (I'm Italian, remember?). I do believe
    that Python is currently the best alternative for application-level
    programming, but you have not shown any support for your insults
    against me on this score (nor for just about any of your assertions).

    I know Scheme (and many dozens of other languages), and use the most
    appropriate one for each task -- these days, my opinion (supported by
    very substantial evidence) is that Python happens to be the most
    appropriate language for most tasks I tackle (except that C keeps
    being preferable in several cases, when I work on lower-level code).
    Since my choices are (obviously -- I'm an engineer!) "pragmatic"
    ones (i.e., ones oriented to get the best results IN PRACTICE), then
    by your own previous admission my choice is OK. So how can that
    choice, by itself, identify me as an idiot and a bigot? Thus, your
    insults are not just unjustified and unsupported -- they're actually
    self-contradictory with respect to other recent assertions of yours.
    In other words, you keep justifying and reinforcing my opinion that
    you're a sad travesty of a human being.

    > When I was younger it happend that I was a similar idiot and believed
    > that "functional programming" in all its glory will salvage this world.


    Oh, and were you convinced you could spell, too?

    Functional Programming is a very neat mental toy, and maybe one day
    I'll come upon a real-world reason to USE it for production code. I'm
    not holding my breath, though. My opinion that Python is the best
    currently available language for most tasks isn't based on some kind
    of preconceived evaluation: it's based on real-world experience over
    a huge variety of programming tasks, which I have, over the decades,
    tackled using a similarly huge variety of languages, in some cases by
    myself, in most cases as a part of a team of programmers. I've seen
    excellent programmers just fail to GET such (intrinsically excellent)
    languages as Lisp and Scheme variants of all sorts, Prolog and its ilk,
    functional programming languages -- try and fail to get any real
    productivity with them. I've seen excellent programmers dive head-first
    into complex higher-level languages such as Perl, and come up with huge
    masses of unmaintainable code. SOME people can no doubt make very
    effective use of each and every one of these tools, but experience has
    shown me that they just don't generalize well. For other higher level
    languages, such as Rexx, Icon, Python, and Ruby, my experience suggests
    instead that programmers (including both experienced ones and ones with
    less experience) tend to become very productive with them, very fast,
    and write good code, suitable for team-work and maintenance. Out of
    these, Python is currently my choice (and Ruby a close second, but there
    are aspects of Ruby -- signally its "dynamic-all-the-way" nature -- that
    suggests to me that, while it may be even better than Python for such
    purposes as "tinkering", it's intrinsically inferior for the purpose of
    building very large and complex system which will need to be maintained
    for many years by a large variety of people) -- in part for pragmatical
    reasons, and I see nothing shameful in that.


    > For me Python is crap and not any longer worth to consider. But look, I


    If so, then hanging out on this newsgroup shows your ability to manage
    your own time in doing things of interest to you is on a par with the
    several other intellectual skills we've already mentioned.

    > even introduced Python at our institution some month ago. A colleague


    If you DO think it's crap, as you repeatedly said, then such
    behavior is inexcusable -- you deliberately _damaged_ your "institution"
    (once a common euphemism for "mental hospital", you know...) by
    introducing there what you consider "crap". Again, the amount of
    internal contradiction in your posts is either laughable or very,
    very sad, depending on one's viewpoint.

    > asked me and I showed him Scheme. He didn't like the parantheses and I
    > adviced him to buy some Python books. Indeed he did it. What is
    > important here: he is happy that I am not any of this idiots who falls
    > for and believes that his own programming language is the best thing.


    Python is not "my own" programming language (if anybody's, it's Guido
    van Rossum's) -- it's simply the one I currently consider as the best
    available for most production tasks in application development. I, in
    turn, have repeatedly advised (note the correct spelling) people who
    came to this newsgroup in order to ask for changes to Python, to take
    up other languages instead (e.g., Scheme, Dylan, or Common Lisp, if
    they're *really* keen to have powerful macros in their language). The
    difference, of course, is that I do not consider such languages to be
    "crap", as you have stated about Python -- I would not damage another
    human being by suggesting he use something I consider to be "crap".


    > I will stop this discussion because I am used to discuss with people who
    > can demonstrate to have at least a minimal amount of brain.


    We'll see if you're a liar once again (wouldn't be surprising, considering
    the amount of lies we've already seen in a few posts of yours) or if for
    once you keep your word. Your stated reason for "stopping this discussion",
    of course, doesn't hold water -- you've already repeatedly (if grudgingly)
    conceded some of my points (indeed, you've explicitly said you thought one
    of my posts would be useful to others) and therefore you've already,
    unwittingly to be sure!, demonstrated that you admit I do have "at least
    a minimal amount of brain". But so what -- lies, obfuscation, muddled
    thinking, insults, confusion, self-contradition -- I've seen nothing but
    that in your posts; you appear to think as well as you spell, which IS
    saying something. So long (hopefully)...


    Alex
     
    Alex Martelli, Aug 4, 2003
    #9
  10. Greg Brunet

    Alan Kennedy Guest

    [Siegfried Gonzi wrote]
    > For me Python is crap and not any longer worth to consider.


    Then move on, and give us all a rest.

    --
    alan kennedy
    -----------------------------------------------------
    check http headers here: http://xhaus.com/headers
    email alan: http://xhaus.com/mailto/alan
     
    Alan Kennedy, Aug 4, 2003
    #10
  11. Alex Martelli wrote:
    > [nice flame, fun to read]


    I interpreted Mr. Gonzi's statement "Python is crap" to be meant for
    numerical programming. Which I can support, unless you use third-party
    libraries like Numeric, psyco or others.

    Perhaps it was a misunderstanding and you two can calm down now.

    Or just continue your flames, they're fun to read :)

    -- Gerhard
     
    =?ISO-8859-1?Q?Gerhard_H=E4ring?=, Aug 4, 2003
    #11
  12. On Monday 04 August 2003 04:27 pm, Gerhard Häring wrote:
    > Alex Martelli wrote:
    > > [nice flame, fun to read]


    Glad you liked it:).

    > I interpreted Mr. Gonzi's statement "Python is crap" to be meant for
    > numerical programming. Which I can support, unless you use third-party
    > libraries like Numeric, psyco or others.


    <shrug> that's like saying, say, that "C is crap" for multimedia
    programming... unless you use third-party libraries like SDL. Of _course_
    you'll use the appropriate tools for the kind of applications you're writing
    (what languages, in turn, such tools/libraries are implemented in, is quite
    secondary -- if and when the pypy project is done, it will not change the
    nature of Python programming, even though extensions may well at that
    time have to be similarly reimplemented in Python).

    Using psyco is as hard as inserting _two_ statements into your code.

    You may call it "using a library", it that floats your boat, but to me it
    feels much closer to using 3rd-party optimizer tools for Fortran matrix
    computations (I still remember the early-90's release of such a tool as
    totally busting the "specmarks"...), using a jit-enabled JVM rather than
    a non-jitting one for Java, etc. It doesn't change the way you write
    your code, as "using a library" normally implies -- it just makes your
    code faster (if you're lucky;-). How does that differ from, say, using a
    newer and better optimizer as part of your favourite compiler for any
    given language? Why is it crucial to you whether such an optimizer is
    "third-party" or rather sold by the same supplier as your base compiler?

    If a language "is crap" as long as a needed optimizer is supplied by
    a third party, then what would the magical process be that would
    suddenly make it "non-crap" if the base compiler's seller bought out
    the optimizer-selling company and released the oprimizer itself? How
    would such a purely commercial operation change the language from
    "crap" into "non-crap"?-)

    I'm afraid these observations suggest you may not have thought the
    issues through.


    > Perhaps it was a misunderstanding and you two can calm down now.


    I'm quite calm, thanks (the flames being as fun to write as they are to
    read:). And Mr Gonzi has asserted he won't take further part in the
    discussion, so, unless he wants to show himself up as an outright liar (not
    for the first time), I guess your recommendations can't affect him now.


    > Or just continue your flames, they're fun to read :)


    Glad to hear this! I'll no doubt flame again when the occasion should
    arise (I _am_ quite prone to doing that, as is well known).


    Alex
     
    Alex Martelli, Aug 4, 2003
    #12
  13. Alex Martelli wrote:
    > On Monday 04 August 2003 04:27 pm, Gerhard Häring wrote:
    >>I interpreted Mr. Gonzi's statement "Python is crap" to be meant for
    >>numerical programming. Which I can support, unless you use third-party
    >>libraries like Numeric, psyco or others.

    >
    > [...] Using psyco is as hard as inserting _two_ statements into your code.
    >
    > You may call it "using a library", [...]
    > I'm afraid these observations suggest you may not have thought the
    > issues through.


    I'm well aware of what Psyco is and was even aware that 'library' was
    not really describing it very well while typing my post (though you
    'use' it as a library from within your Python programs!). I should have
    been less lazy and replaced 'library' with 'addon' ;-)

    -- Gerhard
     
    =?ISO-8859-1?Q?Gerhard_H=E4ring?=, Aug 4, 2003
    #13
  14. Alex Martelli <> wrote in message news:<0MoXa.21930$>...
    > import math
    >
    > def erfc(x):
    > exp = math.exp
    >
    > p = 0.3275911
    > a1 = 0.254829592
    > a2 = -0.284496736
    > a3 = 1.421413741
    > a4 = -1.453152027
    > a5 = 1.061405429
    >
    > t = 1.0 / (1.0 + p*x)
    > erfcx = ( (a1 + (a2 + (a3 +
    > (a4 + a5*t)*t)*t)*t)*t ) * exp(-x*x)
    > return erfcx
    >
    > def main():
    > erg = 0.0
    >
    > for i in xrange(1000000):
    > erg += erfc(0.456)
    >
    > print "%f" % erg
    >
    > if __name__ == '__main__':
    > main()
    >


    Just for fun, I tested your scripts on my machine and actually my
    results also substain the (heretic?) argument that Python (with psyco)
    is *faster* than C for numeric computations:

    Time Relative to (optimized) C

    python+psyco 0.41s 0.59
    c (-O option) 0.69s 1
    c (normal) 0.80s 1.15
    pure python 17.8s 26

    This means that (in this computation) normal Python is 26 times
    slower than optimized C; however Psyco gives a 43x speed-up and it
    ends up to be 70% faster!

    It took my breath away.

    Kudos to Armin Rigo and Psyco!

    Michele


    P.S. Red Hat Linux 7.2, 500 GHz PIII, time measured with 'time',
    Python 2.3 and Psyco 1.0, Alex Martelli scripts (with pow(x,2)-> x*x).
     
    Michele Simionato, Aug 4, 2003
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin v. =?iso-8859-15?q?L=F6wis?=

    Re: Python speed vs csharp

    Martin v. =?iso-8859-15?q?L=F6wis?=, Jul 31, 2003, in forum: Python
    Replies:
    1
    Views:
    441
    Bengt Richter
    Jul 31, 2003
  2. Richie Hindle

    Re: Python speed vs csharp

    Richie Hindle, Jul 31, 2003, in forum: Python
    Replies:
    3
    Views:
    436
    Richie Hindle
    Aug 1, 2003
  3. David M. Cooke

    Re: Python speed vs csharp

    David M. Cooke, Jul 31, 2003, in forum: Python
    Replies:
    4
    Views:
    466
    Andrew Dalke
    Aug 1, 2003
  4. Bengt Richter

    Re: Python speed vs csharp

    Bengt Richter, Aug 1, 2003, in forum: Python
    Replies:
    1
    Views:
    349
    John Machin
    Aug 2, 2003
  5. Mike

    Re: Python speed vs csharp

    Mike, Aug 2, 2003, in forum: Python
    Replies:
    2
    Views:
    316
Loading...

Share This Page