Go as an alternative to Node.js for very fast servers

Re:Go as an alternative to Node.js for very fast servers by payload on Wednesday August 14, 2013 @03:05PM (#6213537)

A haskell version with the Warp server performs just a little bit worse than the go version (6 secs vs 7 secs) with a little bigger minimal latency (68 ms vs 71 ms).

  go version go1.0.2
  runghc 7.6.2
  cabal packages of today

Runned with "runhaskell main.hs" on localhost over loopback :)

  import qualified Network.Wai as Wai
  import qualified Network.Wai.Handler.Warp as Warp
  import qualified Network.HTTP.Types as HTTP
  import qualified Data.ByteString as ByteString
  import Blaze.ByteString.Builder.ByteString (fromByteString)
  
  main = do
      let port = 8000
      Warp.run port app
  
  app req = do
      let n = 1024*1024
      let bytes = fromByteString $ ByteString.replicate n 100
      return $ Wai.ResponseBuilder HTTP.status200 [] bytes

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by cgag on Wednesday August 14, 2013 @04:26PM (#6213996)

Am I right in thinking that Haskell servers will likely be winning on these benchmarks after Mio is released in 7.8.1? https://news.ycombinator.com/item?id=6198068

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by Peaker on Wednesday August 14, 2013 @06:40PM (#6214847)

Since Warp seems to use many light-weight(green) threads behind the scenes, and Mio is mainly about improving multithreaded performance on actual multi-core set ups, the answer seems to be yes.

However, it would probably only help if you use -threaded (which you should, anyways).

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by strager on Wednesday August 14, 2013 @04:36PM (#6214060)

Have you tried precompiling with -O2? IIRC runhaskell runs code like GHCi: interpreted bytecode by default (for source .hs files).

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by payload on Wednesday August 14, 2013 @06:53PM (#6214925)

Yes I have and I invite you to do it also by yourself to check it. There is no significant difference in this benchmark between "ghc -O2" and "runhaskell". I didn't investigated why... but I would be very interested in the details :)

Also "-threaded" gives the usual penalty of bookkeeping and bad caching and stuff. You don't need threads in such a benchmark. Though I am mildly surprised that "node" runs faster with multiple processes :)

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by Peaker on Wednesday August 14, 2013 @06:42PM (#6214856)

Don't use "runhaskell", it's more of a "script mode".

Use: ghc -threaded -O2 main.hs && ./main

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by payload on Wednesday August 14, 2013 @06:53PM (#6214931)

There is no significant difference in this benchmark. Do you measure something different?

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by Peaker on Wednesday August 14, 2013 @07:54PM (#6215282)

I didn't measure, no.

I suppose maybe it uses the optimized compiled packages code, and the main code doesn't really do anything, so -O2 doesn't matter.

However, I would still expect "-threaded" to have an effect.

[ Parent | on HN ]

Re:Go as an alternative to Node.js for very fast servers by payload on Thursday August 15, 2013 @05:02AM (#6216804)

Yes, a negative one for this benchmark :)

[ Parent | on HN ]