Perl is too slow - A statement

Discussion in 'Perl Misc' started by mercurish@googlemail.com, Apr 25, 2009.

  1. Guest

    We hear this all too common:
    "I have one huge problem with Perl; it is too slow."

    But is Perl realy slow, could perl be slow at all?

    The problem is that most programmers associate an implementation of a
    programming
    language with the language it self. The current interpreter is too
    slow and hence programmers
    think that 'Perl' is too slow.

    Perl5 doesn't perform anything to make Perl machine like-able, Perl5
    is infact hated by machines
    where the Perl5 program is being executed.

    Though however, with Perl6 the maintainers of the programming language
    are hoping to reduce the
    runtime overhead of using Perl over the traditional programming
    languages such as C.

    But is Perl ready to be used for huge projects or is other languges
    such as Python taking over??

    What are we going to do??


    -- Kasra
     
    , Apr 25, 2009
    #1
    1. Advertising

  2. Uri Guttman Guest

    >>>>> "m" == mercurish <> writes:

    m> What are we going to do??

    *'WE'* are going to ignore trolls like you who don't know from slow vs
    fast. you can create slow programs in any language. i can write perl
    that runs faster than most people can in their favorite language. you
    question is useless.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 25, 2009
    #2
    1. Advertising

  3. In article
    <>,
    wrote:

    > We hear this all too common:
    > "I have one huge problem with Perl; it is too slow."
    >
    > But is Perl realy slow, could perl be slow at all?
    >
    > The problem is that most programmers associate an implementation of a
    > programming
    > language with the language it self. The current interpreter is too
    > slow and hence programmers
    > think that 'Perl' is too slow.
    >
    > Perl5 doesn't perform anything to make Perl machine like-able, Perl5
    > is infact hated by machines
    > where the Perl5 program is being executed.
    >
    > Though however, with Perl6 the maintainers of the programming language
    > are hoping to reduce the
    > runtime overhead of using Perl over the traditional programming
    > languages such as C.
    >
    > But is Perl ready to be used for huge projects or is other languges
    > such as Python taking over??
    >
    > What are we going to do??
    >
    >
    > -- Kasra


    As a recovering sysadmin, I find perl to be more than excellent at doing
    the day-to-day stuff. It's my tool of choice unless I can bang
    something out in the shell in 5 minutes.

    As to generalized trollish comments about performance, I find it's
    usually not the tool that's needs performance enhancement, it's the
    performer that needs enhancement.

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...
    [I filter all Goggle Groups posts, so any reply may be automatically by ignored]
     
    Michael Vilain, Apr 25, 2009
    #3
  4. neilsolent Guest

    > We hear this all too common:
    >             "I have one huge problem with Perl; it is too slow."
    >
    > But is Perl realy slow, could perl be slow at all?


    In my experience Perl is fast, in fact breath-takingly fast for an
    interpreted language, and given the huge high-level functionality it
    provides.
    I don't have any benchmarks to back this up, but I think it is a known
    fact that it compares reasonably to even optimised C code, performing
    similar tasks. Obviously it really depends what tasks we are talking
    about.
    Why don't you post some simple scripts doing what you think Perl is
    slow at - and show us how it can be done faster in some other language?
     
    neilsolent, Apr 26, 2009
    #4
  5. >>>>> "m" == mercurish <> writes:

    m> But is Perl ready to be used for huge projects or is other
    m> languges such as Python taking over??

    You might have asked this question a decade and a half ago, and gotten
    an interesting debate. As it is, Perl is not only ready to be used for
    huge projects, but is actually currently being used for large projects.

    m> What are we going to do??

    We are going to continue working on our codebases of hundreds of
    thousands of lines of Perl. What are *you* going to do?

    Charlton






    --
    Charlton Wilbur
     
    Charlton Wilbur, Apr 26, 2009
    #5
  6. Guest

    On Sun, 26 Apr 2009 01:21:30 -0700 (PDT), neilsolent <> wrote:

    >> We hear this all too common:
    >>             "I have one huge problem with Perl; it is too slow."
    >>
    >> But is Perl realy slow, could perl be slow at all?

    >
    >In my experience Perl is fast, in fact breath-takingly fast for an
    >interpreted language, and given the huge high-level functionality it
    >provides.
    >I don't have any benchmarks to back this up, but I think it is a known
    >fact that it compares reasonably to even optimised C code, performing
    >similar tasks. Obviously it really depends what tasks we are talking
    >about.
    >Why don't you post some simple scripts doing what you think Perl is
    >slow at - and show us how it can be done faster in some other language?


    char *str = "This is a long sentence";
    printf ("%s", &str[10]);

    ----------------

    my $str = "This is a long sentence";
    my @words = split ' ', $str;
    printf ("%s %s", @words[3,4]);


    -sln
     
    , Apr 26, 2009
    #6
  7. <> wrote:
    > On Sun, 26 Apr 2009 01:21:30 -0700 (PDT), neilsolent <> wrote:
    >
    >>> We hear this all too common:
    >>>             "I have one huge problem with Perl; it is too slow."
    >>>
    >>> But is Perl realy slow, could perl be slow at all?

    >>
    >>In my experience Perl is fast, in fact breath-takingly fast for an
    >>interpreted language, and given the huge high-level functionality it
    >>provides.
    >>I don't have any benchmarks to back this up, but I think it is a known
    >>fact that it compares reasonably to even optimised C code, performing
    >>similar tasks. Obviously it really depends what tasks we are talking
    >>about.
    >>Why don't you post some simple scripts doing what you think Perl is
    >>slow at - and show us how it can be done faster in some other language?

    >
    > char *str = "This is a long sentence";
    > printf ("%s", &str[10]);
    >
    > ----------------
    >
    > my $str = "This is a long sentence";



    print substr($str, 10);


    --
    Tad McClellan
    email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
     
    Tad J McClellan, Apr 26, 2009
    #7
  8. neilsolent Guest

    On 26 Apr, 22:33, Tad J McClellan <> wrote:
    > <> wrote:
    > > On Sun, 26 Apr 2009 01:21:30 -0700 (PDT), neilsolent <> wrote:

    >
    > >>> We hear this all too common:
    > >>>             "I have one huge problem with Perl; it is tooslow."

    >
    > >>> But is Perl realy slow, could perl be slow at all?

    >
    > >>In my experience Perl is fast, in fact breath-takingly fast for an
    > >>interpreted language, and given the huge high-level functionality it
    > >>provides.
    > >>I don't have any benchmarks to back this up, but I think it is a known
    > >>fact that it compares reasonably to even optimised C code, performing
    > >>similar tasks. Obviously it really depends what tasks we are talking
    > >>about.
    > >>Why don't you post some simple scripts doing what you think Perl is
    > >>slow at - and show us how it can be done faster in some other language?

    >
    > > char *str = "This is a long sentence";
    > > printf ("%s", &str[10]);

    >
    > > ----------------

    >
    > > my $str = "This is a long sentence";

    >
    >     print substr($str, 10);
    >
    > --
    > Tad McClellan
    > email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"- Hide quoted text -
    >
    > - Show quoted text -


    Running these "equivalent" bits of Perl an C in a tight loop (1000000
    iterations) - shows on my machine:

    approx 0.3s run time for the C
    approx 0.9s run time for Perl

    I think this is pretty good considering Perl is interpreted and (I
    suspect) the example is deliberately picked to find something C is
    faster at!
     
    neilsolent, Apr 27, 2009
    #8
  9. Uri Guttman Guest

    >>>>> "n" == neilsolent <> writes:

    >> > char *str = "This is a long sentence";
    >> > printf ("%s", &str[10]);
    >> > ----------------
    >> > my $str = "This is a long sentence";

    >>     print substr($str, 10);


    n> Running these "equivalent" bits of Perl an C in a tight loop (1000000
    n> iterations) - shows on my machine:

    n> approx 0.3s run time for the C
    n> approx 0.9s run time for Perl

    n> I think this is pretty good considering Perl is interpreted and (I
    n> suspect) the example is deliberately picked to find something C is
    n> faster at!

    it also shows you have no clue about what is important these
    days. development time is way more expensive than running time. you can
    always get a faster computer but you rarely can speed up a development
    schedule.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 27, 2009
    #9
  10. wrote:
    > On Sun, 26 Apr 2009 01:21:30 -0700 (PDT), neilsolent
    > <> wrote:
    >
    >> Why don't you post some simple scripts doing what you think Perl is
    >> slow at - and show us how it can be done faster in some other
    >> language?

    >
    > char *str = "This is a long sentence";
    > printf ("%s", &str[10]);
    >
    > ----------------
    >
    > my $str = "This is a long sentence";
    > my @words = split ' ', $str;
    > printf ("%s %s", @words[3,4]);
    >


    Bad!

    my $str = "This is a long sentence";
    print substr($str, 10);

    --
    Petr Vileta, Czech Republic
    (My server rejects all messages from Yahoo and Hotmail.
    Send me your mail from another non-spammer site please.)
    Please reply to <petr AT practisoft DOT cz>
     
    Petr Vileta \fidokomik\, Apr 27, 2009
    #10
  11. On 2009-04-27 21:14, cherryplankton <> wrote:
    ><> wrote:
    >> We hear this all too common:
    >> "I have one huge problem with Perl; it is too slow."
    >>
    >> But is Perl realy slow, could perl be slow at all?
    >>
    >> The problem is that most programmers associate an implementation of a
    >> programming
    >> language with the language it self. The current interpreter is too
    >> slow and hence programmers
    >> think that 'Perl' is too slow.

    [...]
    > You want to see slow? Try a bad SQL join called from PHP with Firefox on
    > a slow one-core machine.


    If you have a bad SQL join it is completely irrelevant whether you call
    it from PHP or Perl or C, and whether your PHP/Perl/C code is in turn
    invoked by a request from Firefox or Opera or IE. All your PHP/Perl/C
    code will do is wait while the RDBMS is slogging through gigabytes of
    data, and all your browser will do is wait for your PHP/Perl/C code.

    hp
     
    Peter J. Holzer, Apr 28, 2009
    #11
  12. Uri Guttman Guest

    >>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:

    b> Uri Guttman wrote:

    >> it also shows you have no clue about what is important these
    >> days. development time is way more expensive than running time. you can
    >> always get a faster computer but you rarely can speed up a development
    >> schedule.


    b> Agreed; further, algorithm developement gives
    b> greater speed up than "cycle counting".

    better algorithms is not the same as dev time vs cpu time. in the olden
    days cpu time was expensive and programs were smaller so you had to pay
    for cpu usage and it was monitored carefully. today cpu time is dirt
    cheap so it is rarely accounted but programs are larger and take more
    labor costs to write.

    b> Jon Bentley, in a rather old book, shows a quicksort
    b> in Basic on a TRS-80 outrunning a fully optimised
    b> bubble sort on a Cray-1 (*)

    that would also depend on the data set size. i am sure the picked a size
    large enough to make that happen. you are comparing O(N log N) to O( N
    ** 2) and the bubble sort will grow much faster until its slow algorithm
    swamps the cpu speed differences.

    b> (*) I did say the book was old!

    the point is still valid even if the boxes are antiquated.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 28, 2009
    #12
  13. >>>>> "PJH" == Peter J Holzer <> writes:

    PJH> If you have a bad SQL join it is completely irrelevant whether
    PJH> you call it from PHP or Perl or C, and whether your PHP/Perl/C
    PJH> code is in turn invoked by a request from Firefox or Opera or
    PJH> IE. All your PHP/Perl/C code will do is wait while the RDBMS is
    PJH> slogging through gigabytes of data, and all your browser will
    PJH> do is wait for your PHP/Perl/C code.

    Which touches off another argument: even if you have a *good* SQL join,
    and your database is perfectly tuned, the I/O will still probably take
    an order of magnitude more time than any computation you do with the
    data.

    In other words: it doesn't really matter if a tight loop executes in 3
    milliseconds or 10 milliseconds, if it takes 300 milliseconds before you
    get the data you need to operate on from the database.

    Charlton


    --
    Charlton Wilbur
     
    Charlton Wilbur, Apr 28, 2009
    #13
  14. Ted Zlatanov Guest

    On Mon, 27 Apr 2009 11:58:56 -0400 Uri Guttman <> wrote:

    UG> development time is way more expensive than running time. you can
    UG> always get a faster computer but you rarely can speed up a
    UG> development schedule.

    There are many cases where Perl is simply the wrong tool because the
    equivalent C or C++ or even assembler code would run many times faster.
    Inlining the C code is not the answer if 95% of the code is
    time-critical. So you write a library and call it from Perl; at that
    point you're not writing code in Perl but calling it from Perl.

    This is unavoidable. There will always be the need to run as fast as
    possible for particular tasks, at the expense of development schedule
    and whatever else falls under the carriage. This is not a Perl vs. X
    problem, it's a niche that Perl and many others just don't fill.

    The important thing is to realize when Perl is appropriate and when it
    isn't. Unfortunately the single best way to predict this is to have
    done it already, so prototyping time-critical Perl code with the real
    data is really important.

    Ted
     
    Ted Zlatanov, Apr 28, 2009
    #14
  15. Nathan Keel Guest

    Uri Guttman wrote:

    >>>>>> "n" == neilsolent <> writes:

    >
    > >> > char *str = "This is a long sentence";
    > >> > printf ("%s", &str[10]);
    > >> > ----------------
    > >> > my $str = "This is a long sentence";
    > >> print substr($str, 10);

    >
    > n> Running these "equivalent" bits of Perl an C in a tight loop
    > (1000000 n> iterations) - shows on my machine:
    >
    > n> approx 0.3s run time for the C
    > n> approx 0.9s run time for Perl
    >
    > n> I think this is pretty good considering Perl is interpreted and
    > (I n> suspect) the example is deliberately picked to find something
    > C is n> faster at!
    >
    > it also shows you have no clue about what is important these
    > days. development time is way more expensive than running time. you
    > can always get a faster computer but you rarely can speed up a
    > development schedule.
    >
    > uri
    >


    Are you being sarcastic? If not, too bad, and that's scary. About 10
    years ago I had some guy try and steal me away from the company I was
    working at and things looked good, until he wanted to do everything in
    Visual Basic and using MS Access databases over C/C++ and MySQL or
    equivalent.

    If you know the language, development time isn't an issue, so comparing
    an experience C programmer (whom will have libraries (their own),
    template scripts, etc. to re-use, unless they are an idiot) and compare
    it to an interpreted language and development time, it's likely not
    going to be a whole lot different. And, the compiled code, if it's
    written well, will easily out perform the interpreted code.

    I quickly turned down the guy's offer, because he said exactly what you
    did above "If people want the program to run faster, they can get a
    faster computer". That's an awful and often ignorant attitude. Never
    settle for code that's inefficient for the sake of a quick turn around
    time. Perl is my favorite language, but if I care about speed (and I
    mean really care), I'll plan to write it in C. If you are speaking
    from experience and how "in the real world", it's important to consider
    that you won't get jobs if you want to create the best programs, that's
    one thing, but hopefully not many people have to work for shitty
    companies that are that clueless (or people above them that force them
    into that situation due to lack of planning or understanding the
    project). But, to each their own. I just hope I never end up having
    to work for someone like that, and luckily I've always been able to
    tell them to f--- off.
     
    Nathan Keel, Apr 29, 2009
    #15
  16. Uri Guttman Guest

    >>>>> "NK" == Nathan Keel <> writes:

    NK> Uri Guttman wrote:

    >> it also shows you have no clue about what is important these
    >> days. development time is way more expensive than running time. you
    >> can always get a faster computer but you rarely can speed up a
    >> development schedule.


    NK> If you know the language, development time isn't an issue, so comparing
    NK> an experience C programmer (whom will have libraries (their own),
    NK> template scripts, etc. to re-use, unless they are an idiot) and compare
    NK> it to an interpreted language and development time, it's likely not
    NK> going to be a whole lot different. And, the compiled code, if it's
    NK> written well, will easily out perform the interpreted code.

    study some computer history and come back when you have finished. have
    you ever worked on a computer which actually accounted for your cpu
    time? you don't understand my point which is well known and
    supported. cpu time used to be the major expense in those days,
    developer time is the major expense now.

    NK> I quickly turned down the guy's offer, because he said exactly what you
    NK> did above "If people want the program to run faster, they can get a
    NK> faster computer". That's an awful and often ignorant attitude. Never
    NK> settle for code that's inefficient for the sake of a quick turn around
    NK> time. Perl is my favorite language, but if I care about speed (and I
    NK> mean really care), I'll plan to write it in C. If you are speaking
    NK> from experience and how "in the real world", it's important to consider
    NK> that you won't get jobs if you want to create the best programs, that's
    NK> one thing, but hopefully not many people have to work for shitty
    NK> companies that are that clueless (or people above them that force them
    NK> into that situation due to lack of planning or understanding the
    NK> project). But, to each their own. I just hope I never end up having
    NK> to work for someone like that, and luckily I've always been able to
    NK> tell them to f--- off.

    you don't get it. study some history as i said. computer power is dirt
    cheap today. cheaper than you realize. developer cost is way more
    expensive. so buying more/faster computers is usually more economical
    than hiring more and better developers. of course this isn't always
    possible but it is a very strong rule of thumb. and note, i am a speed
    freak coder. most of my cpan modules (id: uri) are about doing things as
    fast as possible. and they usually succeed. :)

    for a starter, read the mythical man month.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 29, 2009
    #16
  17. In article <>,
    Uri Guttman <> wrote:

    > >>>>> "NK" == Nathan Keel <> writes:

    >
    > NK> Uri Guttman wrote:
    >
    > >> it also shows you have no clue about what is important these
    > >> days. development time is way more expensive than running time. you
    > >> can always get a faster computer but you rarely can speed up a
    > >> development schedule.

    >
    > NK> If you know the language, development time isn't an issue, so comparing
    > NK> an experience C programmer (whom will have libraries (their own),
    > NK> template scripts, etc. to re-use, unless they are an idiot) and compare
    > NK> it to an interpreted language and development time, it's likely not
    > NK> going to be a whole lot different. And, the compiled code, if it's
    > NK> written well, will easily out perform the interpreted code.
    >
    > study some computer history and come back when you have finished. have
    > you ever worked on a computer which actually accounted for your cpu
    > time? you don't understand my point which is well known and
    > supported. cpu time used to be the major expense in those days,
    > developer time is the major expense now.
    >
    > NK> I quickly turned down the guy's offer, because he said exactly what you
    > NK> did above "If people want the program to run faster, they can get a
    > NK> faster computer". That's an awful and often ignorant attitude. Never
    > NK> settle for code that's inefficient for the sake of a quick turn around
    > NK> time. Perl is my favorite language, but if I care about speed (and I
    > NK> mean really care), I'll plan to write it in C. If you are speaking
    > NK> from experience and how "in the real world", it's important to consider
    > NK> that you won't get jobs if you want to create the best programs, that's
    > NK> one thing, but hopefully not many people have to work for shitty
    > NK> companies that are that clueless (or people above them that force them
    > NK> into that situation due to lack of planning or understanding the
    > NK> project). But, to each their own. I just hope I never end up having
    > NK> to work for someone like that, and luckily I've always been able to
    > NK> tell them to f--- off.
    >
    > you don't get it. study some history as i said. computer power is dirt
    > cheap today. cheaper than you realize. developer cost is way more
    > expensive. so buying more/faster computers is usually more economical
    > than hiring more and better developers. of course this isn't always
    > possible but it is a very strong rule of thumb. and note, i am a speed
    > freak coder. most of my cpan modules (id: uri) are about doing things as
    > fast as possible. and they usually succeed. :)
    >
    > for a starter, read the mythical man month.
    >
    > uri


    Uri,

    I've been around since the mid-1970's and I wrote some of the accounting
    packages for systems that didn't have them to charge for CPU time (the
    main frame had it but the VAXes didn't, so I wrote the code to do the
    accounting for the company).

    As a sysadmin, I know full well any tools I write won't be for
    day-to-day production use. I was the only admin that could code in C,
    FORTRAN, perl, and sh. God knows where this company hired from, but
    they didn't seem to hire programmers. I got all the requests for weird
    stuff and updates (we've got this program that doesn't work any
    more...can you look at it). My boss told me to ignore such requests.

    Yes, companies can just "buy bigger computers" but at some point, that's
    a waste. Guess you haven't gotten the memo that companies aren't buying
    new systems right now. They want to extend the use of their systems
    another couple years. You're don't seem to be bothering enough or care
    enough about making something better, which is one of my criteria for
    being in programming. It's good know where you stand on the mediocracy
    scale. A recent slashdot article on programmers talked about a manager
    trying to figure out how to balance out his team. He had a couple
    really good code monkeys, about 6 hard working, get-it-done people, and
    two wastes of airspace. He wanted to know what to do with those last
    two. If he has an opening, maybe you should give him a call.

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...
    [I filter all Goggle Groups posts, so any reply may be automatically by ignored]
     
    Michael Vilain, Apr 29, 2009
    #17
  18. Dr.Ruud Guest

    Uri Guttman wrote:

    > you don't get it. study some history as i said. computer power is dirt
    > cheap today. cheaper than you realize. developer cost is way more
    > expensive. so buying more/faster computers is usually more economical
    > than hiring more and better developers. of course this isn't always
    > possible but it is a very strong rule of thumb. and note, i am a speed
    > freak coder. most of my cpan modules (id: uri) are about doing things as
    > fast as possible. and they usually succeed. :)
    >
    > for a starter, read the mythical man month.


    Uri, please stop wasting your precious developer's time on these types,
    because they will never get it.

    We could also discuss algorithms that run processes in parallel that
    wastefully produce overlapping results which are then merged and deduped
    in order to get the final result much much earlier then when we would
    let a speed addict touch it. But we can't discuss them if we are too
    busy implementing them. :)

    --
    Ruud
     
    Dr.Ruud, Apr 29, 2009
    #18
  19. Uri Guttman Guest

    >>>>> "MV" == Michael Vilain <> writes:

    MV> Yes, companies can just "buy bigger computers" but at some point, that's
    MV> a waste. Guess you haven't gotten the memo that companies aren't buying
    MV> new systems right now. They want to extend the use of their systems
    MV> another couple years. You're don't seem to be bothering enough or care
    MV> enough about making something better, which is one of my criteria for
    MV> being in programming. It's good know where you stand on the mediocracy
    MV> scale. A recent slashdot article on programmers talked about a manager
    MV> trying to figure out how to balance out his team. He had a couple
    MV> really good code monkeys, about 6 hard working, get-it-done people, and
    MV> two wastes of airspace. He wanted to know what to do with those last
    MV> two. If he has an opening, maybe you should give him a call.

    you don't know where i stand on anything from a stupid usenet
    thread. sure you can program better and get more from a cpu. i do that
    all the time (as i noted about my cpan modules). it is just that some
    people don't know how to do that well or don't get the
    cost/effectiveness tradeoffs. and my main point (regardless of budgets)
    is that development time is way more expensive than cpu time these
    days. and that isn't disputed. that doesn't mean i or someone else can't
    or won't write faster code. it just means that you have to look at many
    ways get a faster system. i have to have strengths in scaling systems
    which is not even programming but more architecture and not a common
    skill. but it means i have to think in multiple dimensions including how
    many cpus to buy vs how long it would take to code something up. cloud
    computing is the latest way to balance this. you can rent cpus by the
    minute (history repeating itself) but you need to have a distributed
    architecture to take advantage of that.

    so stop assuming i only push for more cpu vs better coding. i do both as
    needed. but assuming that better development is the only solution for
    more speed is just as dumb as the other way around. knowing their true
    costs and balancing is the issue.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 29, 2009
    #19
  20. Uri Guttman Guest

    >>>>> "R" == Ruud <> writes:

    R> Uri Guttman wrote:
    >> you don't get it. study some history as i said. computer power is dirt
    >> cheap today. cheaper than you realize. developer cost is way more
    >> expensive. so buying more/faster computers is usually more economical
    >> than hiring more and better developers. of course this isn't always
    >> possible but it is a very strong rule of thumb. and note, i am a speed
    >> freak coder. most of my cpan modules (id: uri) are about doing things as
    >> fast as possible. and they usually succeed. :)
    >>
    >> for a starter, read the mythical man month.


    R> Uri, please stop wasting your precious developer's time on these
    R> types, because they will never get it.

    R> We could also discuss algorithms that run processes in parallel that
    R> wastefully produce overlapping results which are then merged and
    R> deduped in order to get the final result much much earlier then when
    R> we would let a speed addict touch it. But we can't discuss them if we
    R> are too busy implementing them. :)

    agreed. 'nuff said.

    but my point about reading MMM is still very valid! :)

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Free Perl Training --- http://perlhunter.com/college.html ---------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Apr 29, 2009
    #20
    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
    Replies:
    0
    Views:
    494
    Martin
    Aug 4, 2004
  2. SB
    Replies:
    0
    Views:
    397
  3. Mike Foster
    Replies:
    0
    Views:
    931
    Mike Foster
    Jun 23, 2003
  4. Mark Parnell
    Replies:
    0
    Views:
    837
    Mark Parnell
    Jun 24, 2003
  5. nolo contendere
    Replies:
    7
    Views:
    174
    Thomas 'PointedEars' Lahn
    Nov 9, 2007
Loading...

Share This Page