Fastest Perl Interpreter

Discussion in 'Perl Misc' started by Michael J. Astrauskas, Oct 25, 2003.

  1. I'm attempting build a system that needs to run a perl script very
    quickly. There will be no disk access, but the system will be doing an
    intense amount of network and processor work. Is there any particular
    processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    operating system, and interpreter that are known to be the most powerful
    combination?

    My current idea is to use a dual Xeon with a gigabyte ethernet port and
    at least 2 GB of RAM.

    Thank you for any advice, recommendations, and pointers!

    --
    - Michael J. Astrauskas
     
    Michael J. Astrauskas, Oct 25, 2003
    #1
    1. Advertising

  2. Michael J. Astrauskas wrote:

    > I'm attempting build a system that needs to run a perl script very
    > quickly. There will be no disk access, but the system will be doing an
    > intense amount of network and processor work. Is there any particular
    > processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    > operating system, and interpreter that are known to be the most powerful
    > combination?


    My guess, then, is that you want something that has a big network pipe
    and a fast processor. Perl is perl is perl - the only difference
    between the platforms is going to be the C optimiser that you compile
    perl itself with. Well, maybe not *only*, but that will have the
    largest effect other than the hardware itself.

    For example, Intel promises a percentage-boost simply by compiling with
    their Proton or Electron compilers over using MSVC or gcc on the same
    platform. If you compile perl 5.8.1 with the Electron compiler on
    Linux/ia32, you'll probably be doing alright for your system.

    > My current idea is to use a dual Xeon with a gigabyte ethernet port and
    > at least 2 GB of RAM.


    As soon as you have multiple CPUs, you'll only see any benefits if you
    actually have a multi-threaded or multi-process system running. That
    is, at least one thread of activity per CPU. If your program can only
    do one thing at a time, that second CPU will be 90%+ wasted.

    If, however, your program can run multithreaded (dangerous in perl,
    last I heard) or multiprocess (i.e. fork() and do stuff in the child
    process), then by all means go with the SMP setup. Note that perl
    likes fork()'s, and Windows doesn't, so you might be best off here
    going with Linux instead of Windows.

    > Thank you for any advice, recommendations, and pointers!


    As long as you're going with commodity hardware, dual P4s will probably
    saturate your gigabit ethernet. Depending on what you're doing, you
    may want dual gigabit ethernet cards, and go with 4 or more Pentium4's
    for better throughput. This only helps, of course, if the data you're
    processing can come in from multiple networks or subnets. It can
    eliminate a hop for people coming in from more than one router away.

    But that doesn't change much if you go away from commodity hardware.
    In general, the commercial-unix hardware (RS6000, current SPARCs, etc),
    even if not running commercial unix (e.g. Linux on PPC hardware rather
    than AIX on the same hardware) may get you better performance, and
    possibly less downtime. But you'll still want gigabit ethernet, and
    possibly more than one. And you'll still want SMP, if your program can
    handle it.

    There are so many possibilities to keep aware of that your vague
    question can only get you vague answers ... but they may point you in
    the right way for your situation.
     
    Darin McBride, Oct 26, 2003
    #2
    1. Advertising

  3. On Sat, 25 Oct 2003 15:34:51 -0700, "Michael J. Astrauskas" <>
    wrote:

    >I'm attempting build a system that needs to run a perl script very
    >quickly. There will be no disk access, but the system will be doing an
    >intense amount of network and processor work.


    In most cases, unless there is a large amount of calculation or disk searching
    involved, this will result in an i/o bound system, where most of the CPU
    cycles are spent waiting for the network i/o to complete. In such a case,
    system CPU speed will be secondary in system speed impact to network latency
    issues. This may guide selection of hardware--spend more on speeding your I/O,
    not necessarily your CPU.

    OTOH, if your app is really CPU bound, not network bound, maybe you should not
    use Perl. Use something compiled.


    ---
    Use the domain skylightview (dot) com for the reply address instead.
     
    William Herrera, Oct 26, 2003
    #3
  4. Michael J. Astrauskas

    Juha Laiho Guest

    "Michael J. Astrauskas" <> said:
    >I'm attempting build a system that needs to run a perl script very
    >quickly. There will be no disk access, but the system will be doing an
    >intense amount of network and processor work. Is there any particular
    >processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    >operating system, and interpreter that are known to be the most powerful
    >combination?
    >
    >My current idea is to use a dual Xeon with a gigabyte ethernet port and
    >at least 2 GB of RAM.


    If you're really going to need that amount of RAM for your processing,
    then the memory latency _and_ bandwidth may play big parts in overall
    performance. Try to find this info for the choices you're considering.
    When reading the info, try to calculate ratios between different speeds
    rather than absolute differences - ratios often tell more. For this there
    are two factors: the speeds supported by the motherboard, and the speeds
    supported by the memory modules.

    As for raw CPU performance, the current Intel/AMD setups bring more
    "bang for buck" than traditional Unix platforms (IBM Power CPUs,
    Solaris Sparc, HP PA-RISC), but may be more limited in I/O bandwidth
    and latency. However, for just one 1Gbit/s network adapter, the "PC"
    solutions should still be ok. If you were asking for multiple 1Gbit/s
    channels and multiple fast disk channels, then I'd rather recommend
    something other than "PC" hardware -- or at least would direct you
    towards the high-end PC servers.

    Then, do you really mean gigabyte ethernet port, i.e. roughly 10 gigabits/s,
    or just one gigabit/s? Pay attention, the difference is huge.

    When you're talking about 1Gbit/s network speeds, you'll need to look at
    the bus architecture of the system: the traditional 32bit/33MHz PCI bus
    has theoretical bus bandwidth of just over 1Gbit/s, so it's not enough to
    feed a gigabit ethernet channel - you'll need something faster. 64bit/66MHz
    PCI bus will do nicely, but will limit the possible hardware choices
    (and you can forget the prices of commodity motherboards).
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
     
    Juha Laiho, Oct 26, 2003
    #4
  5. Michael J. Astrauskas

    Peter Cooper Guest

    "Michael J. Astrauskas" <> wrote:
    > I'm attempting build a system that needs to run a perl script very
    > quickly. There will be no disk access, but the system will be doing an
    > intense amount of network and processor work. Is there any particular
    > processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    > operating system, and interpreter that are known to be the most powerful
    > combination?
    >
    > My current idea is to use a dual Xeon with a gigabyte ethernet port and
    > at least 2 GB of RAM.


    From a pure 'server speed' point of view (you've already received a few good
    opinions on the specifics), I'd reserve dual Opterons, without a doubt.
    They're faster than the Xeons in UNIX/Linux server scenarios (but not
    workstation scenarios), and cheaper to setup too. You may also get a benefit
    from the 64 bit compatability (Perl can be compiled to a 64 bit executable -
    see perl.64bit on nntp.perl.org)

    http://www.tomshardware.com/cpu/20030422/index.html

    Also see these, mostly workstation oriented, benchmarks for G5/Opteron/P4
    comparisons:

    http://www.pcworld.com/news/article/0,aid,112749,pg,8,00.asp

    The Opteron wins almost all tests. The Firing Squad have also produced an
    article on building an Opteron workstation, which may be of some ancillary
    interest:

    http://firingsquad.com/hardware/building_gaming_opteron_2003_Part1/default.a
    sp

    If you could elaborate on your 'intense amount of network and processor
    work' we might be able to narrow things down a bit. For example, your
    process might not be memory intensive, meaning money saved there could go
    into other areas of the system architecture.

    I'd also echo the comments of another respondant, and recommend you look
    into producing a compiled version of whatever it is you want to do. The
    increased power would, in most cases, pay for itself if the project is over
    a certain length, unless the application is too complex.

    Pete
     
    Peter Cooper, Oct 26, 2003
    #5
  6. Michael J. Astrauskas

    sk Guest

    Michael J. Astrauskas wrote:

    > I'm attempting build a system that needs to run a perl script very
    > quickly. There will be no disk access, but the system will be doing an
    > intense amount of network and processor work. Is there any particular
    > processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    > operating system, and interpreter that are known to be the most powerful
    > combination?


    Is it going to be running a large number of short tasks or a small
    number of long ones? Starting up a Perl interpreter each time will be an
    issue if it's the former. If that's the case, you probably want to write
    your Perl program as a server that launches once and handles repeated
    requests or tasks without exiting. As long as you're not spawning perl
    interpreters over and over again, your performance should be good and it
    will make it unnecessary to output "compiled" Perl, which is just a
    snapshot of what really gets executed once the interpreter chews through
    the raw code.

    Apart from that, your question is really vague. "Intense amount of
    network and processor work" doesn't tell us anything, much less whether
    Perl is the right language for the job at all. Is it doing one linear
    task or lots of small tasks in parallel? Is it handling small chunks of
    data or huge ones? All of which points more to the language and the
    compiler used to build the language than to the shininess of a brand of
    CPU or bus speed.
     
    sk, Oct 26, 2003
    #6
  7. Michael J. Astrauskas

    Tom Guest

    An option maybe to split the processing between multiple machines? A cheap
    option if you have some oldish systems, however that would require
    considerable work to enable.

    Cheers,
    Tom

    "Michael J. Astrauskas" <> wrote in message
    news:4UCmb.80044$vj2.6293@fed1read06...
    > I'm attempting build a system that needs to run a perl script very
    > quickly. There will be no disk access, but the system will be doing an
    > intense amount of network and processor work. Is there any particular
    > processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    > operating system, and interpreter that are known to be the most powerful
    > combination?
    >
    > My current idea is to use a dual Xeon with a gigabyte ethernet port and
    > at least 2 GB of RAM.
    >
    > Thank you for any advice, recommendations, and pointers!
    >
    > --
    > - Michael J. Astrauskas
    >
     
    Tom, Oct 26, 2003
    #7
  8. Michael J. Astrauskas

    W K Guest

    "Purl Gurl" <> wrote in message
    news:...
    > Abigail wrote:
    >
    > > Michael J. Astrauskas wrote:

    >
    > > > I'm attempting build a system that needs to run a perl script very
    > > > quickly. There will be no disk access, but the system will be doing

    an
    > > > intense amount of network and processor work. Is there any particular
    > > > processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    > > > operating system, and interpreter that are known to be the most

    powerful
    > > > combination?

    >
    > > Last week, this question had an easy answer: a laptop on the Concorde.
    > > But they aren't flying those planes anymore.


    Do you think concorde passengers write perl?
    Easier and cheaper to not bother with trying to optomise speed and just go
    on a 747 - or even an A330 (!).

    > You have forgotten about space shuttles and orbiting space labs,
    > all of which travel at relative speeds of eighteen-thousand miles
    > per hour or greater.


    Space shuttles?
     
    W K, Oct 28, 2003
    #8
  9. Peter Cooper wrote:

    > If you could elaborate on your 'intense amount of network and processor
    > work' we might be able to narrow things down a bit. For example, your
    > process might not be memory intensive, meaning money saved there could go
    > into other areas of the system architecture.


    The task is basically a head NNTP server. It will be balancing incoming
    loads to various other servers on the network. Apparently CPU isn't so
    important as network i/o.

    > I'd also echo the comments of another respondant, and recommend you look
    > into producing a compiled version of whatever it is you want to do. The
    > increased power would, in most cases, pay for itself if the project is over
    > a certain length, unless the application is too complex.


    It's for a contest, more or less, so I can't choose what the task is.
    It's a Perl script not written by myself.

    --
    - Michael J. Astrauskas
     
    Michael J. Astrauskas, Oct 30, 2003
    #9
  10. William Herrera wrote:

    > On Sat, 25 Oct 2003 15:34:51 -0700, "Michael J. Astrauskas" <>
    > wrote:
    >
    >
    >>I'm attempting build a system that needs to run a perl script very
    >>quickly. There will be no disk access, but the system will be doing an
    >>intense amount of network and processor work.

    >
    >
    > In most cases, unless there is a large amount of calculation or disk searching
    > involved, this will result in an i/o bound system, where most of the CPU
    > cycles are spent waiting for the network i/o to complete. In such a case,
    > system CPU speed will be secondary in system speed impact to network latency
    > issues. This may guide selection of hardware--spend more on speeding your I/O,
    > not necessarily your CPU.


    It'll basically be a front end NNTP server. Network I/O will be intense.
    About 300 copies of the script will be running at any time.

    > OTOH, if your app is really CPU bound, not network bound, maybe you should not
    > use Perl. Use something compiled.


    Sadly, it's for a contest and the language and script are not of my choice.

    --
    - Michael J. Astrauskas
     
    Michael J. Astrauskas, Nov 12, 2003
    #10
  11. Darin McBride wrote:

    > Michael J. Astrauskas wrote:
    >
    >>I'm attempting build a system that needs to run a perl script very
    >>quickly. There will be no disk access, but the system will be doing an
    >>intense amount of network and processor work. Is there any particular
    >>processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    >>operating system, and interpreter that are known to be the most powerful
    >>combination?

    >
    > My guess, then, is that you want something that has a big network pipe
    > and a fast processor. Perl is perl is perl - the only difference
    > between the platforms is going to be the C optimiser that you compile
    > perl itself with. Well, maybe not *only*, but that will have the
    > largest effect other than the hardware itself.


    It's for a contest and the requirement is actually dual gigabit Ethernet
    ports.

    > For example, Intel promises a percentage-boost simply by compiling with
    > their Proton or Electron compilers over using MSVC or gcc on the same
    > platform. If you compile perl 5.8.1 with the Electron compiler on
    > Linux/ia32, you'll probably be doing alright for your system.


    I'm definitely going to keep this in mind. Thank you.

    >>My current idea is to use a dual Xeon with a gigabyte ethernet port and
    >>at least 2 GB of RAM.

    >
    > As soon as you have multiple CPUs, you'll only see any benefits if you
    > actually have a multi-threaded or multi-process system running. That
    > is, at least one thread of activity per CPU. If your program can only
    > do one thing at a time, that second CPU will be 90%+ wasted.
    >
    > If, however, your program can run multithreaded (dangerous in perl,
    > last I heard) or multiprocess (i.e. fork() and do stuff in the child
    > process), then by all means go with the SMP setup. Note that perl
    > likes fork()'s, and Windows doesn't, so you might be best off here
    > going with Linux instead of Windows.


    The script is single-threaded but there will be many instances of it
    running.

    >>Thank you for any advice, recommendations, and pointers!

    >
    > As long as you're going with commodity hardware, dual P4s will probably
    > saturate your gigabit ethernet. Depending on what you're doing, you
    > may want dual gigabit ethernet cards, and go with 4 or more Pentium4's
    > for better throughput. This only helps, of course, if the data you're
    > processing can come in from multiple networks or subnets. It can
    > eliminate a hop for people coming in from more than one router away.


    I was looking at some benchmarks and P4s did quite well, but dual
    Opterons did better in most regards (over dual Xeons, as well). Not all,
    though, which makes my decision all that much harder.

    --
    - Michael J. Astrauskas
     
    Michael J. Astrauskas, Nov 12, 2003
    #11
  12. Michael J. Astrauskas wrote:

    > Darin McBride wrote:
    >
    >> Michael J. Astrauskas wrote:
    >>
    >>>I'm attempting build a system that needs to run a perl script very
    >>>quickly. There will be no disk access, but the system will be doing an
    >>>intense amount of network and processor work. Is there any particular
    >>>processor architecture (32-bit AMD/Intel, Opteron, Sun, Apple, etc.),
    >>>operating system, and interpreter that are known to be the most powerful
    >>>combination?

    >>
    >> My guess, then, is that you want something that has a big network pipe
    >> and a fast processor. Perl is perl is perl - the only difference
    >> between the platforms is going to be the C optimiser that you compile
    >> perl itself with. Well, maybe not *only*, but that will have the
    >> largest effect other than the hardware itself.

    >
    > It's for a contest and the requirement is actually dual gigabit Ethernet
    > ports.


    I see I nailed that one already by suggesting it. ;->

    >> For example, Intel promises a percentage-boost simply by compiling with
    >> their Proton or Electron compilers over using MSVC or gcc on the same
    >> platform. If you compile perl 5.8.1 with the Electron compiler on
    >> Linux/ia32, you'll probably be doing alright for your system.

    >
    > I'm definitely going to keep this in mind. Thank you.


    Just note that these compilers cost $$$, whereas MSVC only costs $, and
    gcc, of course, has no cost. ;->

    >>>My current idea is to use a dual Xeon with a gigabyte ethernet port and
    >>>at least 2 GB of RAM.

    >>
    >> As soon as you have multiple CPUs, you'll only see any benefits if you
    >> actually have a multi-threaded or multi-process system running. That
    >> is, at least one thread of activity per CPU. If your program can only
    >> do one thing at a time, that second CPU will be 90%+ wasted.
    >>
    >> If, however, your program can run multithreaded (dangerous in perl,
    >> last I heard) or multiprocess (i.e. fork() and do stuff in the child
    >> process), then by all means go with the SMP setup. Note that perl
    >> likes fork()'s, and Windows doesn't, so you might be best off here
    >> going with Linux instead of Windows.

    >
    > The script is single-threaded but there will be many instances of it
    > running.


    That is multiprocess. Obviously, I should have used "e.g." rather than
    "i.e.". Thus, SMP is helpful. If you can change the code slightly to
    use fork after loading all the modules and you can use Linux, I would
    say that this would get a small speed boost as your script would only
    get compiled once for all the processes, and this may help the OS
    overlap things in memory for more speed boosts during runtime (fewer
    cache misses, possibly).

    >>>Thank you for any advice, recommendations, and pointers!

    >>
    >> As long as you're going with commodity hardware, dual P4s will probably
    >> saturate your gigabit ethernet. Depending on what you're doing, you
    >> may want dual gigabit ethernet cards, and go with 4 or more Pentium4's
    >> for better throughput. This only helps, of course, if the data you're
    >> processing can come in from multiple networks or subnets. It can
    >> eliminate a hop for people coming in from more than one router away.

    >
    > I was looking at some benchmarks and P4s did quite well, but dual
    > Opterons did better in most regards (over dual Xeons, as well). Not all,
    > though, which makes my decision all that much harder.


    Yes - unless you can get the hardware side-by-side running your
    application, it'll be a fair bit of guesswork.

    Best of luck!
     
    Darin McBride, Nov 12, 2003
    #12
  13. Michael J. Astrauskas

    Ben Morrow Guest

    Darin McBride <> wrote:
    > Michael J. Astrauskas wrote:
    > > Darin McBride wrote:
    > >> For example, Intel promises a percentage-boost simply by compiling with
    > >> their Proton or Electron compilers over using MSVC or gcc on the same
    > >> platform. If you compile perl 5.8.1 with the Electron compiler on
    > >> Linux/ia32, you'll probably be doing alright for your system.

    > >
    > > I'm definitely going to keep this in mind. Thank you.

    >
    > Just note that these compilers cost $$$, whereas MSVC only costs $, and
    > gcc, of course, has no cost. ;->


    Is there significant advantage to using Intel's free icc over gcc?

    Ben

    --
    "If a book is worth reading when you are six, *
    it is worth reading when you are sixty." - C.S.Lewis
     
    Ben Morrow, Nov 12, 2003
    #13
  14. Also sprach Ben Morrow:

    > Darin McBride <> wrote:
    >> Michael J. Astrauskas wrote:
    >> > Darin McBride wrote:
    >> >> For example, Intel promises a percentage-boost simply by compiling with
    >> >> their Proton or Electron compilers over using MSVC or gcc on the same
    >> >> platform. If you compile perl 5.8.1 with the Electron compiler on
    >> >> Linux/ia32, you'll probably be doing alright for your system.
    >> >
    >> > I'm definitely going to keep this in mind. Thank you.

    >>
    >> Just note that these compilers cost $$$, whereas MSVC only costs $, and
    >> gcc, of course, has no cost. ;->

    >
    > Is there significant advantage to using Intel's free icc over gcc?


    It's said to give faster binaries than gcc. I, however, was not able to
    confirm this when comparing its result with a gcc > v3. But then again,
    I don't have an Intel processor.

    One thing however could be significant. Intel's icc enforces stricter
    programming habits. My experience with gcc is that it makes you lax and
    you could end up with code that wont compile on some legacy compilers
    without some modifications. Particularly, it doesn't have all those gcc
    extensions that can be quite a spoiler when you intend to be portable.

    So it's become a habit of me to also test my stuff with the icc. It's a
    good indication as to whether it will work with some of the stricter
    compilers (like that of SUN or Microsoft).

    Tassilo
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
     
    Tassilo v. Parseval, Nov 12, 2003
    #14
  15. Michael J. Astrauskas wrote:
    > William Herrera wrote:
    >> On Sat, 25 Oct 2003 15:34:51 -0700, "Michael J. Astrauskas"
    >> <>
    >> wrote:

    >
    > It'll basically be a front end NNTP server. Network I/O will be intense.
    > About 300 copies of the script will be running at any time.


    NNTP? Sounds like a strange contest. Is this a coding contest or a
    contest contest? SMTP, POP, IMAP, HTTP and maybe an IM protocol I can
    see, but NNTP, huh? All right. Are there even 300 regular users of NNTP
    left? :) Okay, okay. No matter.

    Regardless of what protocol you're building this out of, "running 300
    copies of the script" simultaneously is an incredibly bad idea. Doing so
    with an interpreted language like Perl, Python, Tcl, VBScript, LISP,
    whatever will certainly need heavy duty hardwarte, but not for the
    actual work of your script. The CPU and memory and probably the disks
    too will all be occupied initializing and tearing down all those
    interpreters. The actual meat of what your script does will use only a
    tiny fraction of the resources, and you'll need many times the memory
    and CPU than you would otherwise.

    Perl is fine for what you want to do, but you want to do it
    *multithreaded*, with one instance of the script running per box as a
    daemon. That ought to be plenty fast given adequate hardware, and your
    choice of CPU architecture, compiler and compiler optimizations should
    be mostly irrelevant. Throw an adequate number of MIPS at it focus more
    on writing properly optimized Perl and making sure your disk and network
    I/O are adequate.

    If you or someone else insists on implementing this with hundreds of
    separate processes, then it's hard to imagine a worse design decision
    than spawning hundreds of interpreters simultaneously with tens or
    hundreds of thousands of launches and teardowns per day. If you want
    separate processes, you should be using C/C++ or something else that
    compiles to tight binaries, period.

    Splitting hairs over Opterons vs. Xeons vs. supercooled Athlons or
    mastodons is pointless. You should have hardware capable of handling
    your largest realistically-projected traffic spikes with a good amount
    of headroom remaining, period. You can do it with Celerons if you really
    want to: just pick hardware that gives you the SPECmarks, the I/O and
    the uptime you need at a good price. If you're running it on one box
    rather than load-balancing a few smaller ones, and have nothing
    "collecting" requests during downtime, then redundant and/or
    hot-swappable components (especially disk and power supplies) become
    more important. Trying to get a "perfect fit" with little or no headroom
    is completely wrong.

    Indeed, if availability is critical, you should either design the system
    to be load balanced across 1..n machines with no single point of
    failure, or you should be holding your contest over a protocol that can
    store-and-forward gracefully, unlike private NNTP. With something like
    HTTP you can load-balance straightforwardly and run a few smaller and
    more disposable servers instead of one big high-availability one. With
    an email-based contest, on the other hand, you can have dumb
    store-and-forward MX hosts specified in DNS that will catch inbound
    entries and pass them along automatically in the event of downtime on
    your "collector", effectively offloading the job of inbound-message
    fault tolerance to your ISP.

    >> OTOH, if your app is really CPU bound, not network bound, maybe you
    >> should not
    >> use Perl. Use something compiled.

    >
    > Sadly, it's for a contest and the language and script are not of my choice.
     
    Steve Koppelman, Nov 20, 2003
    #15
    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. Bryan Krone

    perl efficiency -- fastest grepping?

    Bryan Krone, Nov 5, 2004, in forum: Perl
    Replies:
    1
    Views:
    1,477
    Jim Gibson
    Nov 8, 2004
  2. Replies:
    3
    Views:
    762
    Ziga Seilnacht
    Jan 3, 2007
  3. Pablo S

    Fastest versions of perl?

    Pablo S, Sep 1, 2004, in forum: Perl Misc
    Replies:
    5
    Views:
    130
    Tore Aursand
    Sep 1, 2004
  4. Bryan Krone

    perl efficiency -- fastest grepping?

    Bryan Krone, Nov 16, 2004, in forum: Perl Misc
    Replies:
    5
    Views:
    150
    Uri Guttman
    Nov 16, 2004
  5. Mark Richards
    Replies:
    6
    Views:
    264
    A. Sinan Unur
    Nov 18, 2007
Loading...

Share This Page