Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bbs.studygolang.com

Post reply on HN
Print view View original

91–100 of 168 posts

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

#91

Post by thrownaway2424 »

spullara wrote: post #86
thrownaway2424 wrote: post #73

Earlier quoted context omitted.

What do you think the difference is between a "real core" and a "hyperthread core"?

There is a huge difference between the two. Hyperthreaded cores only give you a speed up in specific situations where additional work can be squeezed into the pipeline. http://en.wikipedia.org/wiki/Hyper-threading The speedup is very work dependent and in practice for things like web pages and api servers you generally only get another 20-40% of performance from them rather than a full 100%.

In other words, you have no idea what the difference is.

A hyperthreaded Intel CPU has M functional units and N decode/issue pipelines.

A non-hyperthreaded Intel CPU has M' functional units and N' decode/issue pipelines.

A hyperthreaded Intel CPU with hyperthreading disabled has M functional units and N/2 decode/issue pipelines.

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

#92

Post by daemon13 »

bhauer wrote: post #67
daemon13 wrote: post #64

Earlier quoted context omitted.

>> wrk > ab Can you please expand on why? I recently bumped on wrk and am in process of evaluating switch from ab, thank you

Sure. I just edited my message above.

Thank you!

You've got cool blog, esp. prior posts selection!!

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

#93

Post by thrownaway2424 »

aaronblohowiak wrote: post #89
thrownaway2424 wrote: post #73

Earlier quoted context omitted.

What do you think the difference is between a "real core" and a "hyperthread core"?

An HTT cpu can still only execute one instruction at a time; there are often instructions that cause the cpu to have idle time (stalled waiting for data) and hyperthreading allows for the cpu to spend that otherwise idle thread making progress on a separate task list. However, this still means that the two scheduled threads are contending for the same execution unit... The parent is suggesting that this contest may c…

No, not even close. Each thread on a Haswell CPU, just as an example, has 8 execution ports. Each Haswell core has ten execution units. The CPU can retire way more than one instruction per cycle.

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

#94

Post by voidlogic »

daemon13 wrote: post #64
bhauer wrote: post #44

Earlier quoted context omitted.

I agree with Voidlogic here. Perhaps his tone was a little confrontational, but his intentions were good. :) Go 1.1 > Go 1.0.2 wrk > ab In particular, ab should be avoided whenever possible. Apache Bench (ab) remains a single-threaded tool, meaning that for high-performance servers in particular, your exercise will run into the limits of Apache Bench before the limits of the server(s) being tested. The LigHTTP team h…

>> wrk > ab Can you please expand on why? I recently bumped on wrk and am in process of evaluating switch from ab, thank you

daemon13, you might also be interested in reading this thread: https://news.ycombinator.com/item?id=6114282

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

#95

Post by ciclista »

diminoten wrote: post #75
bsaul wrote: post #34

Earlier quoted context omitted.

I'm really uncertain about node being judged more "mature". Being developed by Thompson and Pike makes you gain something like 30 years of "maturity". Plus, running in production in the Google infrastructure is far more of a proof of maturity than running the chat service of every hackathon project for 2 years.

So do I just email all my questions directly to Thompson and Pike, then? In this case, language maturity means the quantity of reference material available to help troubleshoot problems as the arise.

The golang nuts mailing list is extremely active, you'd have no issues finding answers there.

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

#96

Post by AsymetricCom »

thrownaway2424 wrote: post #93
aaronblohowiak wrote: post #89

Earlier quoted context omitted.

An HTT cpu can still only execute one instruction at a time; there are often instructions that cause the cpu to have idle time (stalled waiting for data) and hyperthreading allows for the cpu to spend that otherwise idle thread making progress on a separate task list. However, this still means that the two scheduled threads are contending for the same execution unit... The parent is suggesting that this contest may c…

No, not even close. Each thread on a Haswell CPU, just as an example, has 8 execution ports. Each Haswell core has ten execution units. The CPU can retire way more than one instruction per cycle.

In theory

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

#97

Post by diminoten »

ciclista wrote: post #95
diminoten wrote: post #75

Earlier quoted context omitted.

So do I just email all my questions directly to Thompson and Pike, then? In this case, language maturity means the quantity of reference material available to help troubleshoot problems as the arise.

The golang nuts mailing list is extremely active, you'd have no issues finding answers there.

Yeah I don't doubt you'd be able to find answers to any Go question, the point though is that you'll have to work a little harder than with a "more mature" "language" like Node.js.

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

#98

Post by tensor »

swah wrote: post #54

Go doesn't mean just fast for me; in that space there is also the JVM. To me, it fits the fast and lean and easy to deploy space.

The headline of this article bothered me in this regard. Node.js is decidedly middle of the pack in terms of performance:

http://www.techempower.com/benchmarks/

In addition to various JVM technologies, there are faster technologies in C++, PHP, and Lua.

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

#99

Post by ilaksh »

markuskobler wrote: post #55

Are these trivial micro benchmarks, (simply respond with an empty 200) not totally misleading to focus on? Especially when you start to factor in many real workloads that involve disk or network io.

Its not empty because its 1mb but it is misleading because in the original article someone's comment showed Node going much faster than Go. If it were empty then Node would be faster because you can get 4000 req per sec if its empty. I think something weird is going on though because it should be more than 300 per sec with the new Node version even if its 1mb.

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

#100

Post by sandGorgon »

Did you compare with a JVM toolkit with similar concurrency libraries like Akka/Scala?

Am curious to find out the results. There was a recent, don't remember which, comparison that put Scala way ahead of Go possibly because of a superior GC.

Wonder if the results correlate

Post reply on HN