<div dir="ltr">Congratulations!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-02 17:27 GMT+04:00 Adam Chlipala <span dir="ltr"><<a href="mailto:adamc@csail.mit.edu" target="_blank">adamc@csail.mit.edu</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    They're out, and they include a serious Ur/Web configuration error
    for one of the platforms (and I hope this error is fixed in amended
    results), but there is already some good info here to support claims
    of high performance for Ur/Web.  Here's the text I added to the FAQ:<br>
    <br>
    <div>
      <h2>Can you be more specific about run-time performance?</h2>
      <p>The <a href="http://www.techempower.com/benchmarks/" target="_blank">TechEmpower Web
          Framework Benchmarks</a> provide a performance comparison
        managed by a third party. Ur/Web does pretty well, and you can
        check that site for details, but a few caveats are important.
        First, the Ur/Web programming model is unusually oriented toward
        security and concurrency simplicity. For instance, Ur/Web's
        standard random number generation function generates
        cryptographically secure numbers, which imposes an extra
        run-time cost in the several benchmarks based on random numbers;
        and Ur/Web's concurrency model allows the programmer to think of
        every piece of code as running inside a transaction, which
        imposes extra run-time cost in the several benchmarks that use
        databases, necessarily within a transaction per request, unlike
        in almost all other frameworks' entries in the benchmarks. Also,
        by the way, the current i7 numbers were captured under a serious
        configuration error and should be ignored.</p>
      <p>OK, having said all that, Ur/Web is still doing pretty darn
        well! Consider the results for the highest-capacity machine in
        the benchmarks, which provides 48 hardware threads. In rough
        numbers, here's how Ur/Web is doing.</p>
      <table border="1">
        <tbody>
          <tr>
            <th>Test</th>
            <th>Requests/sec.</th>
            <th>Latency</th>
          </tr>
          <tr>
            <td>Hello world in JSON</td>
            <td>400k</td>
            <td>0.6 ms</td>
          </tr>
          <tr>
            <td>1 SQL query</td>
            <td>100k</td>
            <td>2 ms</td>
          </tr>
          <tr>
            <td>20 SQL queries</td>
            <td>10k</td>
            <td>24 ms</td>
          </tr>
          <tr>
            <td>20 SQL query/update pairs</td>
            <td>500</td>
            <td>2 s</td>
          </tr>
        </tbody>
      </table>
      <p>Yeah, Ur/Web is really falling over in the many-updates test,
        with optimistic SQL concurrency thrashing to provide the
        transactional semantics that most benchmark entrants don't
        bother to shoot for. Still, very few web sites process as much
        as hundreds of requests per second!</p>
      <p>Despite Ur/Web's performance handicaps in service of a pleasant
        programming model, on the Fortunes test, which is closest to the
        scenario Ur/Web was designed for, Ur/Web has the best latency
        and 4th-best throughput, out of about 50 frameworks passing that
        test's basic sanity check. In the spirit of sibling rivalry,
        I'll also point out that the Haskell frameworks consistently
        achieve less than half the throughput of Ur/Web.</p>
    </div>
  </div>

<br>_______________________________________________<br>
Ur mailing list<br>
<a href="mailto:Ur@impredicative.com">Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" target="_blank">http://www.impredicative.com/cgi-bin/mailman/listinfo/ur</a><br>
<br></blockquote></div><br></div>