8 ms·

DDG is using dynamic language like Perl[1] to achieve high-scalability which is slowest of all languages. This proves languages don't matter much, its all about

DDG is using dynamic language like Perl[1] to achieve high-scalability which is slowest of all languages. This proves languages don't matter much, its all about architecture. I guess its time to stop worrying about performance of your programming language & start building better high-salable architectures. [1] Slowest of all languages http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fastest.php?gcc=on&gpp=on&ifc=on&java=on&v8=on&hipe=on&jruby=on&php=on&python3=on&yarv=on&perl=on&calc=chart http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

afsina 14y ago
This is simply not true. Not every problem can be solved with caching. If DuckDuckGo would be a real search engine, they would not even touch with a 10 foot pole to Perl for any non trivial algorithm/function. edit: fix the name
- randomstring 14y ago
  Uh, hello!? Blekko is a web scale search engine that is built using Perl. It's not the language that makes handling big data slow. It's the algorithms and how you move the bits around.
  - rieter 14y ago
    Uhm, no. Google can't be implemented in Perl.
  - afsina 14y ago
    Well, sure if you want to use 1000 servers instead of 100, go ahead and use it. No wonder Facebook noticed this and desperately trying to compile Php to C. Perhaps if Blekko ever gets popular we will see if their choice will bite them. Also an anecdotal example. Two months ago a friend of mine wrote a rather complex algorithm in Perl (He is very fluent with it). It was a novel sentence alignment algorithm using Gibbs sampling. Algorithm was hard to make parallel and not cache friendly. He needed to wait more than a day for training the system in a server. Well, long story short, with his help another developer converted it to Java in short time it worked around 200 times faster. So there. Moving bits around did not help Perl here at all.
    - kamaal 14y ago
      >>Blekko ever gets popular we will see if their choice will bite them. What choice? The only reason why Blekko or Facebook is even able to launch and turn around things quickly to survive in competition is because they opt to use dynamic languages like Php and Perl. If they started doing their projects in C, with the current growth in rate of complexity they will never finish their projects ever. >>No wonder Facebook noticed this and desperately trying to compile Php to C. Dynamic languages aren't slower because they are not C. They are slow because they do a lot of magic. C is fast because the magic is left for you to perform. I can't see how any one pull out pace out of compiling Php to C directly, unless they sacrifice things along the way. Which really defeats the purpose of using Php at the first place. >>Well, long story short, with his help another developer converted it to Java in short time it worked around 200 times faster. So there. Moving bits around did not help Perl here at all. Number of programmers who even need to here the word 'bits' in their day to day activities(Talking of application programmers) are rare enough to make their case totally exceptional. Besides there are places where C makes perfect sense. There is hardly any other language heard of in the embedded programming world.
  - runarb 14y ago
    Is the backend/search kernel in Perl to? I wrote the first prototype of Boitho (Norwegian internet search engine, now defunct) in Perl in 2000. That did not work at all because memory access and sorting was so slow. We had to write the next version in C. Of course a lot has happen with Perl in the last 13 years, but search kernel in Perl still sounds odd in my ears.
    - randomstring 14y ago
      Granted, sometimes flipping bits is important. Then you write that part in C. There is no reason to pay the development tax of C for everything else. Not when you can build it in Perl, get it working, and then find the hotspots and convert those to C.
      - badgar 14y ago
        > There is no reason to pay the development tax of C for everything else. Not when you can build it in Perl, get it working, and then find the hotspots and convert those to C. Certainly not with fewer than 20 million req/day.
- kamaal 14y ago
  Modern day software architecture is too complicated to run on one and only one programming language. But regardless of that Perl continues to power some very serious work happening some very important places all over the world. And that is not likely to change sooner. No matter how many web frameworks get written in Php, Ruby or Python. The reason for that is Perl has little or almost no competition in the niche it occupies. And anything that is likely to be invented to replace Perl will by and large like 99% look like Perl(Read: Perl 6 or whatever). This being the case we are likely to be using Perl(or a Perl like language) very far into the future.
johansch 14y ago
1 million searches per day is not really that much. If evenly distributed, it's only 11.6 searches per second.
- yegg 14y ago
  We also do about 12M API requests per day: http://duckduckgo.com/traffic.html http://duckduckgo.com/traffic.html
  - ithkuil 14y ago
    The interesting measure is what is the peak rps EDIT: I mean, it ~150 doesn't seem that much, but I'm sure the requests are not uniformly distributed, so the system should be able to handle much more than that within reasonable latency bounds.
    - badgar 14y ago
      > within reasonable latency bounds Have you used DDG? Requests take over 500-600ms regularly for me. Compare to Google's instant search and excellent latency for non-instant queries... which handle orders of magnitude more traffic.
      - ithkuil 14y ago
        I'm not a DDG user, but it's easy to measure: $ time I=$((I+1)) curl -s "https://duckduckgo.com/d.js?q=test&t=A&l=us-en&p=1&s=0" >/dev/null I=$((I+1)) curl -s "https://duckduckgo.com/d.js?q=test$i&t=A&l=us-en&p=1&s=0" 0.01s user 0.00s system 3% cpu 0.256 total I saw it go over 800ms a couple of times, anyway, I don't intend to run a DDG benchmark. However, just for the sake of the discussion, about architecture and language choice etc, the interesting part would be to see how many rps before starting to degrade. There is no point bashing it and comparing it to other search engines that have more resources behind them.
    - druiid 14y ago
      Indeed. Peak RPS is what is going to be interesting. Depending on where traffic is from, it's very possible to have 12 mil requests in a day only from 9-5 type of hours and a big huge empty space during the night (This is the kind of traffic my company sees).
runarb 14y ago
DDG is mostly a front end for a bunch of search engines. Perl, PHP and Python are great to make front-ends like that. Because you are for the most part only dispatching queries, parsing xml feeds and build the gui for the end user. Writing an internet scale search engine on the other hand would require different tools. Most successful projects has probably been done i C, C++ and maybe Java.
timr 14y ago
Those benchmarks are extremely suspicious. I remember comparing Perl and Python for bioinformatic work (non-trivial computational workloads), and finding that Perl was about 2x the speed of Python, on average. Later, I did similar, non-trivial benchmarks with Python and Ruby, and found a similar, 2x factor. Ruby has improved since then, but unless Perl has become dramatically slower in the same interval, I suspect that these benchmarks are either trivial (i.e. simple loops), or badly written.
- sreque 14y ago
  Your benchmarks are likely very biased. The vast majority of the work done by your bioinformatics programs should be done in C code, with thin wrappers so that the code can be accessed through Perl and Python. If anything, your benchmarks only comparing specific implementations, such as BioPerl vs BioPython.
  - timr 14y ago
    I wasn't using bioperl or biopython. I wrote the algorithms myself.
- igouy 14y ago
  >> ... extremely suspicious ... I suspect ...<< Please - less FUD and more looking at program source code (which is 2 clicks from the URL you were given).
  - timr 14y ago
    If you want to debug the metrics they're using, you're more than welcome to do it. I've got plenty of direct experience to question the results shown by a random webpage on the internet, and not much incentive to figure out why this particular set of benchmarks looks wrong. A quick inspection of the tests suggests a high enough bogon count that it already begins to confirm my suspicions: there's a "fasta-redux" test for Perl which dramatically outperforms the "fasta" test that's implemented cross-language. Also, many of these tests are written in least-common-denominator style, which doesn't reflect the way the languages are actually used.
igouy 14y ago
Not even the slowest of all language implementations shown on the web page you reference.
draegtun 14y ago
Also see: Which programs are best? - http://benchmarksgame.alioth.debian.org/u32/which-programs-are-best.php http://benchmarksgame.alioth.debian.org/u32/which-programs-a... One useful metric change is to add "memory (usage)" weight - http://benchmarksgame.alioth.debian.org/u32/which-programs-are-best.php?calc=chart&gpp=on&ifc=on&java=on&sbcl=on&ghc=on&csharp=on&dart=on&hipe=on&php=on&python3=on&perl=on&jruby=on&yarv=on&xfullcpu=1&xmem=1&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&fastaredux=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytreesredux=0&binarytrees=1 http://benchmarksgame.alioth.debian.org/u32/which-programs-a... Based on this we should all be using Pascal ;-)
- igouy 14y ago
  Free Pascal statically links programs by default, avoiding libc.
Mithaldu 14y ago
That page shows Perl as being roughly 5% slower than Ruby, however when comparing Ruby and Perl directly, things look significantly different: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... So i have to say i am quite suspicious of the chart on the page you linked.
- igouy 14y ago
  Are you suspicious that you may not have understood what is shown? Do both show the same thing?
  - Mithaldu 14y ago
    In fact, i know i do not understand how the table on this page is generated: http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fastest.php?gcc=on&gpp=on&ifc=on&java=on&v8=on&hipe=on&jruby=on&php=on&python3=on&yarv=on&perl=on&calc=chart http://benchmarksgame.alioth.debian.org/u32/which-programs-a... That is precisely why i am suspicious. I cannot say for a fact that it is deceptive, but it certainly seems deceptive. On that page Ruby is being shown as 10% faster than Perl. Yet on the direct comparison page things look quite different: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... On that page, for all benchmarks that can be compared, Perl has used an overall time of 9255 seconds, while Ruby has used an overall time of 10662 seconds. As such Ruby is actually 10% slower than Perl. Where does this difference come from?
    - igouy 14y ago
      >> but it certainly seems deceptive << You go too far -- your lack of understanding is simply your lack of understanding ;) What are you told the table shows? >> Where does this difference come from? << Check the same thing for 2 other language implementations were the arithmetic should be easy. For example, Java median 2.04 and Smalltalk median 21.22 -- the direct comparison shows 11x as the rounded median of the Smalltalk/Java program times.

afsina 14y ago

This is simply not true. Not every problem can be solved with caching. If DuckDuckGo would be a real search engine, they would not even touch with a 10 foot pole to Perl for any non trivial algorithm/function. edit: fix the name

randomstring 14y ago
Uh, hello!? Blekko is a web scale search engine that is built using Perl. It's not the language that makes handling big data slow. It's the algorithms and how you move the bits around.
- rieter 14y ago
  Uhm, no. Google can't be implemented in Perl.
- afsina 14y ago
  Well, sure if you want to use 1000 servers instead of 100, go ahead and use it. No wonder Facebook noticed this and desperately trying to compile Php to C. Perhaps if Blekko ever gets popular we will see if their choice will bite them. Also an anecdotal example. Two months ago a friend of mine wrote a rather complex algorithm in Perl (He is very fluent with it). It was a novel sentence alignment algorithm using Gibbs sampling. Algorithm was hard to make parallel and not cache friendly. He needed to wait more than a day for training the system in a server. Well, long story short, with his help another developer converted it to Java in short time it worked around 200 times faster. So there. Moving bits around did not help Perl here at all.
  - kamaal 14y ago
    >>Blekko ever gets popular we will see if their choice will bite them. What choice? The only reason why Blekko or Facebook is even able to launch and turn around things quickly to survive in competition is because they opt to use dynamic languages like Php and Perl. If they started doing their projects in C, with the current growth in rate of complexity they will never finish their projects ever. >>No wonder Facebook noticed this and desperately trying to compile Php to C. Dynamic languages aren't slower because they are not C. They are slow because they do a lot of magic. C is fast because the magic is left for you to perform. I can't see how any one pull out pace out of compiling Php to C directly, unless they sacrifice things along the way. Which really defeats the purpose of using Php at the first place. >>Well, long story short, with his help another developer converted it to Java in short time it worked around 200 times faster. So there. Moving bits around did not help Perl here at all. Number of programmers who even need to here the word 'bits' in their day to day activities(Talking of application programmers) are rare enough to make their case totally exceptional. Besides there are places where C makes perfect sense. There is hardly any other language heard of in the embedded programming world.
- runarb 14y ago
  Is the backend/search kernel in Perl to? I wrote the first prototype of Boitho (Norwegian internet search engine, now defunct) in Perl in 2000. That did not work at all because memory access and sorting was so slow. We had to write the next version in C. Of course a lot has happen with Perl in the last 13 years, but search kernel in Perl still sounds odd in my ears.
  - randomstring 14y ago
    Granted, sometimes flipping bits is important. Then you write that part in C. There is no reason to pay the development tax of C for everything else. Not when you can build it in Perl, get it working, and then find the hotspots and convert those to C.
    - badgar 14y ago
      > There is no reason to pay the development tax of C for everything else. Not when you can build it in Perl, get it working, and then find the hotspots and convert those to C. Certainly not with fewer than 20 million req/day.
kamaal 14y ago
Modern day software architecture is too complicated to run on one and only one programming language. But regardless of that Perl continues to power some very serious work happening some very important places all over the world. And that is not likely to change sooner. No matter how many web frameworks get written in Php, Ruby or Python. The reason for that is Perl has little or almost no competition in the niche it occupies. And anything that is likely to be invented to replace Perl will by and large like 99% look like Perl(Read: Perl 6 or whatever). This being the case we are likely to be using Perl(or a Perl like language) very far into the future.

johansch 14y ago

1 million searches per day is not really that much. If evenly distributed, it's only 11.6 searches per second.

yegg 14y ago
We also do about 12M API requests per day: http://duckduckgo.com/traffic.html http://duckduckgo.com/traffic.html
- ithkuil 14y ago
  The interesting measure is what is the peak rps EDIT: I mean, it ~150 doesn't seem that much, but I'm sure the requests are not uniformly distributed, so the system should be able to handle much more than that within reasonable latency bounds.
  - badgar 14y ago
    > within reasonable latency bounds Have you used DDG? Requests take over 500-600ms regularly for me. Compare to Google's instant search and excellent latency for non-instant queries... which handle orders of magnitude more traffic.
    - ithkuil 14y ago
      I'm not a DDG user, but it's easy to measure: $ time I=$((I+1)) curl -s "https://duckduckgo.com/d.js?q=test&t=A&l=us-en&p=1&s=0" >/dev/null I=$((I+1)) curl -s "https://duckduckgo.com/d.js?q=test$i&t=A&l=us-en&p=1&s=0" 0.01s user 0.00s system 3% cpu 0.256 total I saw it go over 800ms a couple of times, anyway, I don't intend to run a DDG benchmark. However, just for the sake of the discussion, about architecture and language choice etc, the interesting part would be to see how many rps before starting to degrade. There is no point bashing it and comparing it to other search engines that have more resources behind them.
  - druiid 14y ago
    Indeed. Peak RPS is what is going to be interesting. Depending on where traffic is from, it's very possible to have 12 mil requests in a day only from 9-5 type of hours and a big huge empty space during the night (This is the kind of traffic my company sees).

runarb 14y ago

DDG is mostly a front end for a bunch of search engines. Perl, PHP and Python are great to make front-ends like that. Because you are for the most part only dispatching queries, parsing xml feeds and build the gui for the end user. Writing an internet scale search engine on the other hand would require different tools. Most successful projects has probably been done i C, C++ and maybe Java.

timr 14y ago

Those benchmarks are extremely suspicious. I remember comparing Perl and Python for bioinformatic work (non-trivial computational workloads), and finding that Perl was about 2x the speed of Python, on average. Later, I did similar, non-trivial benchmarks with Python and Ruby, and found a similar, 2x factor. Ruby has improved since then, but unless Perl has become dramatically slower in the same interval, I suspect that these benchmarks are either trivial (i.e. simple loops), or badly written.

sreque 14y ago
Your benchmarks are likely very biased. The vast majority of the work done by your bioinformatics programs should be done in C code, with thin wrappers so that the code can be accessed through Perl and Python. If anything, your benchmarks only comparing specific implementations, such as BioPerl vs BioPython.
- timr 14y ago
  I wasn't using bioperl or biopython. I wrote the algorithms myself.
igouy 14y ago
>> ... extremely suspicious ... I suspect ...<< Please - less FUD and more looking at program source code (which is 2 clicks from the URL you were given).
- timr 14y ago
  If you want to debug the metrics they're using, you're more than welcome to do it. I've got plenty of direct experience to question the results shown by a random webpage on the internet, and not much incentive to figure out why this particular set of benchmarks looks wrong. A quick inspection of the tests suggests a high enough bogon count that it already begins to confirm my suspicions: there's a "fasta-redux" test for Perl which dramatically outperforms the "fasta" test that's implemented cross-language. Also, many of these tests are written in least-common-denominator style, which doesn't reflect the way the languages are actually used.

igouy 14y ago

Not even the slowest of all language implementations shown on the web page you reference.

draegtun 14y ago

Also see: Which programs are best? - http://benchmarksgame.alioth.debian.org/u32/which-programs-are-best.php http://benchmarksgame.alioth.debian.org/u32/which-programs-a... One useful metric change is to add "memory (usage)" weight - http://benchmarksgame.alioth.debian.org/u32/which-programs-are-best.php?calc=chart&gpp=on&ifc=on&java=on&sbcl=on&ghc=on&csharp=on&dart=on&hipe=on&php=on&python3=on&perl=on&jruby=on&yarv=on&xfullcpu=1&xmem=1&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&fastaredux=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytreesredux=0&binarytrees=1 http://benchmarksgame.alioth.debian.org/u32/which-programs-a... Based on this we should all be using Pascal ;-)

igouy 14y ago
Free Pascal statically links programs by default, avoiding libc.

Mithaldu 14y ago

That page shows Perl as being roughly 5% slower than Ruby, however when comparing Ruby and Perl directly, things look significantly different: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... So i have to say i am quite suspicious of the chart on the page you linked.

igouy 14y ago
Are you suspicious that you may not have understood what is shown? Do both show the same thing?
- Mithaldu 14y ago
  In fact, i know i do not understand how the table on this page is generated: http://benchmarksgame.alioth.debian.org/u32/which-programs-are-fastest.php?gcc=on&gpp=on&ifc=on&java=on&v8=on&hipe=on&jruby=on&php=on&python3=on&yarv=on&perl=on&calc=chart http://benchmarksgame.alioth.debian.org/u32/which-programs-a... That is precisely why i am suspicious. I cannot say for a fact that it is deceptive, but it certainly seems deceptive. On that page Ruby is being shown as 10% faster than Perl. Yet on the direct comparison page things look quite different: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=perl&lang2=yarv http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... On that page, for all benchmarks that can be compared, Perl has used an overall time of 9255 seconds, while Ruby has used an overall time of 10662 seconds. As such Ruby is actually 10% slower than Perl. Where does this difference come from?
  - igouy 14y ago
    >> but it certainly seems deceptive << You go too far -- your lack of understanding is simply your lack of understanding ;) What are you told the table shows? >> Where does this difference come from? << Check the same thing for 2 other language implementations were the arithmetic should be easy. For example, Java median 2.04 and Smalltalk median 21.22 -- the direct comparison shows 11x as the rounded median of the Smalltalk/Java program times.