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

161–168 of 168 posts

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

#161

Post by corresation »

thrownaway2424 wrote: post #150
corresation wrote: post #149

Earlier quoted context omitted.

The operating system schedules threads across cores, and the processor has zero say in the matter (further, the execution units are primarily to facilitate branch to essentially execute future scenarios). Both Linux and Windows are hyperthread aware, and will schedule threads to physical processors first, then to hyperthread virtual processors (given that it shares resources with the physical core and can sabotage pe…

No, the power-aware scheduler in Linux does not work as you describe. On a turbo-capable Intel CPU, if there are N program threads that will fit on M cores where M is less than the total cores on a socket, and the CPU will enter P0 state, then the threads will run on as few cores as possible and the remaining cores will be shut down.

Two threads, each running at 100%, will be assigned to two physical cores. This is reality, and is obvious given that assigning it to a physical core and a hyperthread core at most will give you about 130% instead of the 200% two physical cores will provide.

Unless, of course, you've set a power profile to prioritize power efficiency, but that would be an absolutely ridiculous assumption given that we're talking about benchmarks.

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

#162

Post by corresation »

chad_oliver wrote: post #119
thrownaway2424 wrote: post #93

Earlier quoted context omitted.

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.

You are absolutely correct, but you could also afford to be a bit more polite. Sentences like "In other words, you have no idea what the difference is" might be true but they're also a bit rude.

They aren't absolutely correct at all, and aaron was actually close to the money. Thrownaway is fundamentally misrepresenting (or misunderstanding) how threads -- in an operating system sense, and what we are talking to here -- relate to microcode and execution units in a core.

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

#163

Post by rartichoke »

drsintoma wrote: post #156
rartichoke wrote: post #144

Earlier quoted context omitted.

I'll believe it when I see it. Almost nothing has changed since I went through my Go adventure which was like 9 months ago I think. 9 months to me is a huge amount of time. I don't want to have to wait years to be super productive. I want to be super productive right now and by using other platforms I can be. For a new viable web platform to be accepted it needs to really explode in popularity. It has to offer MASSIV…

> but I think you would at least agree with me that node's popularity and growth has been unmatched. Of course I agree. But node is an unique case, since javascript is not exactly new, and had a trillion people using it when node appeared. You can not expect that to happen again any time soon, unless all main browsers start supporting client-side PHP or something crazy like that. Go is not 'there' yet, sure, and mayb…

My point was that even with node's mind boggling growth it still hasn't really overtaken rails when it comes to developer productivity.

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

#164

Post by romaniv »

thezilch wrote: post #138
romaniv wrote: post #118

Earlier quoted context omitted.

I solved the cognitive overhead problem by developing everything via progressive enhancement. This way JavaScript has a clearly defined role and place in the process and I don't have to think in multiple languages. Of course, a lot of developers these days don't want to do progressive enhancement and dismiss it as "impossible".

Not impossible as much as not worth the effort on the dollar. Reddit is fairly simple -- just a threaded-comment engine, if you will. You want the up/down rave to be progressive? So now every up/down is a form; already, drastically increasing the page's weight but I digress. You hook the body for form submits and reduce out your up/down forms; we are done, despite having a bunch of forms marking up the page. Don't fo…

What you're describing is not progressive enhancement. It's a mental exercise in re-implementing a website with workflows designed for heavy JavaScript usage without using JavaScripts. Which is silly.

For example, if you ever tried PE for real you would know that there is no point in implementing collapsible comments in pure HTML. That's exactly the kind of functionality you "enhance" via JavaScript. Of course, like most modern developers you've never really tried the practice, so you don't have any experience with such things.

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

#165

Post by chc »

wtf_is_up wrote: post #145
chc wrote: post #142

Earlier quoted context omitted.

Doesn't this require your development machine to use the same architecture and OS as your server?

No. It's simple to build Go toolchains for whatever your deploy os/arch target is. Then you just cross-compile. * Download Go source * Extract, cd go/src/ * GOOS=linux GOARCH=386 ./make.bash #this will build the linux_386 toolchain * GOOS=linux GOARCH=amd64 ./make.bash #linux_amd64 * GOOS=linux GOARCH=arm ./make.bash #you get the picture GOOS can be windows, darwin, freebsd, netbsd, plan9. Then when you want to cross…

Thanks for that. It's been a while since I used Go. That is quite nice.

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

#166

Post by romaniv »

ebiester wrote: post #136
romaniv wrote: post #118

Earlier quoted context omitted.

I solved the cognitive overhead problem by developing everything via progressive enhancement. This way JavaScript has a clearly defined role and place in the process and I don't have to think in multiple languages. Of course, a lot of developers these days don't want to do progressive enhancement and dismiss it as "impossible".

So, with progressive enhancement... I have a main screen with a query whose processing takes over a minute to perform it on all of the data, but seconds for incremental changes after that. Each row returned has a detail screen associated with it, and the users have a requirement to be able to move to a detail screen, update a record, and return to the main screen without continually incurring the heavy query penalty…

No one stops you from doing polling as an enhancement to a working HTML-only version. However, "single-page" has absolutely nothing to do with this, and neither do client-side MVC frameworks. I mean, there are not a prerequisite to do polling, merely your choice.

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

#167

Post by ebiester »

romaniv wrote: post #166
ebiester wrote: post #136

Earlier quoted context omitted.

So, with progressive enhancement... I have a main screen with a query whose processing takes over a minute to perform it on all of the data, but seconds for incremental changes after that. Each row returned has a detail screen associated with it, and the users have a requirement to be able to move to a detail screen, update a record, and return to the main screen without continually incurring the heavy query penalty…

No one stops you from doing polling as an enhancement to a working HTML-only version. However, "single-page" has absolutely nothing to do with this, and neither do client-side MVC frameworks. I mean, there are not a prerequisite to do polling, merely your choice.

Perhaps I misunderstand you. How would you implement the requirements above? How would you move to a detail screen and back in an HTML only solution that, most importantly, does not require rerunning the query each time?

And most importantly, you've now created two code paths, both of which need testing, both of which require maintenance, and one of which (in a web application) will never be used. What's the ROI?

Now, for some domains (say, e-commerce), progressive enhancement is the right way to go. I've done it. For web applications, which are the extension of client-server applications designed for a limited captive audience (employees), I don't see the ROI.

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

#168

Post by [deleted] »

romaniv wrote: post #164
thezilch wrote: post #138

Earlier quoted context omitted.

Not impossible as much as not worth the effort on the dollar. Reddit is fairly simple -- just a threaded-comment engine, if you will. You want the up/down rave to be progressive? So now every up/down is a form; already, drastically increasing the page's weight but I digress. You hook the body for form submits and reduce out your up/down forms; we are done, despite having a bunch of forms marking up the page. Don't fo…

What you're describing is not progressive enhancement. It's a mental exercise in re-implementing a website with workflows designed for heavy JavaScript usage without using JavaScripts. Which is silly. For example, if you ever tried PE for real you would know that there is no point in implementing collapsible comments in pure HTML. That's exactly the kind of functionality you "enhance" via JavaScript. Of course, like…

[deleted]
Post reply on HN