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

Frameworks Round 6

techempower.com

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Frameworks Round 6

#61

Post by ElongatedTowel »

camus wrote: post #35
RyanZAG wrote: post #25

Earlier quoted context omitted.

Three reasons as to the hierarchy: 1) Most popular frameworks you would encounter run on higher level dynamic languages such as PHP, Ruby or Python. These languages are a decent bit slower than performance optimized languages. The languages towards the top are all C, Java, Go, etc. 2) The frameworks towards the top are generally lower level - they do less automatic 'magic' than the more popular frameworks that handle…

> Basically, the relevance of speed is directly related to your margin. True though the average PHP developper is usually cheaper than the Go or Java one. Paying people is usually more expensive than buying server instances on Amazon. High end PHP dev is as hard as Java .. The problem is that the high end PHP frameworks are at the bottom of the list... > The frameworks towards the top are generally lower level - they…

What do you suggest one should keep an eye on to stay relevant in the future?

Re: Frameworks Round 6

#62

Post by Peaker »

YcombRegBroken wrote: post #59
Peaker wrote: post #58

Earlier quoted context omitted.

What do you mean by "mental cost" here? Cost of initial learning? Then I agree... But learning a language is an O(1) cost that takes a few weeks to a few months. We program with the language for many years. I never said the Go runtime will crash, but your programs will, because of unsafe nullability, mutability in the concurrently shared state, and various other problems in Go. Better concurrency in Haskell: In addit…

Haskell (and most of the other languages mentioned) is exceptionally clever. This, above all else, is it's downfall. For me, especially when tasked with building a high productivity development team, clever code is a ticking time bomb. It's easy to write, but hard to maintain and modify. It requires more mental ram to analyze any given piece of code, and is much more difficult for multiple programmers to contribute t…

I disagree that Haskell is "clever". I think Haskell is "smart".

Using "Maybe a" when you have a nullable value is smart, not "clever". It aids maintenance and readability, not hampers it.

Using pattern matching is the same.

Haskell builds on mathematicaly simplicity, which makes things hard to grasp at first. This may be mistaken for cleverness.

Unless I'm misunderstanding you -- can you give an example of something clever in Haskell?

Re: Frameworks Round 6

#63

Post by Avalaxy »

columbo wrote: post #4

I'm really surprised at the performance of C#... honest no-flame question: how is possible it that Python is beating C#? I've been out of the .NET world for several years, almost a decade, but I always assumed they would be at Java level performance. edit add: This is really fantastic work

I was shocked too that ASP.NET MVC performs so poor in all these tests. C# is/can be a very fast language and both C# and ASP.NET support some awesome features that seriously increase the performance of the web app. The whole async/parallellization for example.

Re: Frameworks Round 6

#64

Post by TylerE »

Peaker wrote: post #58
TylerE wrote: post #46

Earlier quoted context omitted.

With respect, and I say this having experimented with Haskell, OCaml, any many other functional languages as well, just, no. Those languages come at a MUCH higher mental cost than go. Go is wonderful because writing it doesn't feel like I'm attempting a CompSci doctoral thesis. I can also say I have yet to see the Go runtime crash, and I am using in production. I also challenge your "better concurrency" claim.

What do you mean by "mental cost" here? Cost of initial learning? Then I agree... But learning a language is an O(1) cost that takes a few weeks to a few months. We program with the language for many years. I never said the Go runtime will crash, but your programs will, because of unsafe nullability, mutability in the concurrently shared state, and various other problems in Go. Better concurrency in Haskell: In addit…

I think you are vastly under-estimating the learning cost. We're talking about teams of developers, not a hobby project. A few months * multiple programmers adds up to man-years really quick.

Go is much simpler. We deployed our first production (admittedly a fairly minor piece) Go service under a week after we made the decision to start using Go.

PS: State is only shared when you make it so. Go concepts like channels make it very easy to write, _and debug_ clear, decoupled non-trivial parallel code.

Re: Frameworks Round 6

#65

Post by joeblau »

continuations wrote: post #43

cpoll-cppsp made huge performance gains from round 5 to 6. For example multiple queries went from 1,872 rps in round 5 to 7,252 in round 6. What caused that? Also what happened to cpoll-cppsp in the plaintext test? Its performance there took a deep dive.

Is there any reason why it is so slow on plain text?

Re: Frameworks Round 6

#66

Post by columbo »

gog wrote: post #60
krg wrote: post #54

Earlier quoted context omitted.

Hi gog, I'm sorry you spent time trying to get started with Gemini, because it's our internal framework that isn't released yet. That would have been frustrating for you! From our "Motivations" section: http://www.techempower.com/benchmarks/#section=motivation "Why include this Gemini framework I've never heard of?" We have included our in-house Java web framework, Gemini, in our tests. We've done so because it's of…

Thank you, now I understand why I couldn't find anything useful on this page http://www.eclipse.org/gemini/web/ :) Nevertheless I am still looking for good resources on getting started with Java (ecosystem wise, not the language itself).

Have you considered starting with Grails? It's a much easier jump into the "java-ish" world. The main benefit is you can choose to run a grails application and rely on java jars for when you need performance boosts.

Re: Frameworks Round 6

#67

Post by MetaCosm »

dom96 wrote: post #40
bhauer wrote: post #30

Earlier quoted context omitted.

Finally indeed! In future rounds, I hope that we can spend less time trying to resolve problems--if there are problems, we'll just post the results and move on to the next round. Better to keep iterating, and allow the experts who work with each framework resolve issues as they come up. Thanks very much for contributing Jester to the test! I really appreciate your spirit and hope to see it improve in Round 7 as well.…

Indeed, although people may be disappointed if their framework fails and they have to wait another month for another round of results, but then I suppose the next round will come a lot quicker if you have less issues to fix. No problem at all. Thank you for merging my process spawning silliness. You will definitely see a lot more improvements from me :) EDIT: A little issue I just noticed: the jester "Front-end serve…

I think they would be less disappointed if it meant a consistent schedule. These benchmarks are really a lot of fun, not sure if they change hearts and minds, but they are beautiful and fun.

I think being time-boxed rather than implementation-boxed make sense. If you miss a month, you got 30 days to fix it.

Also, they could only "update" the test rules quarterly or every 6 months, give the authors a bit of time to respond.

Re: Frameworks Round 6

#68

Post by MetaCosm »

Peaker wrote: post #62
YcombRegBroken wrote: post #59

Earlier quoted context omitted.

Haskell (and most of the other languages mentioned) is exceptionally clever. This, above all else, is it's downfall. For me, especially when tasked with building a high productivity development team, clever code is a ticking time bomb. It's easy to write, but hard to maintain and modify. It requires more mental ram to analyze any given piece of code, and is much more difficult for multiple programmers to contribute t…

I disagree that Haskell is "clever". I think Haskell is "smart". Using "Maybe a" when you have a nullable value is smart, not "clever". It aids maintenance and readability, not hampers it. Using pattern matching is the same. Haskell builds on mathematicaly simplicity, which makes things hard to grasp at first. This may be mistaken for cleverness. Unless I'm misunderstanding you -- can you give an example of something…

I would go so far as to say Haskell is better.

But, then you gotta remember, "worse is better" (New Jersey style), and Go is worse. New Jersey style: (1) be simple in both implementation and interface (2) correct, be correct as long as it doesn't make it more complicated, simple is more important than correct (3) consistent, when you can be consistent, do be, but simplicity is more important and (4) completeness, be as complete as you can, but realize completeness can be sacrificed for any other objective.

I think C and Go share a lot of New Jersey style -- Go is great in simplicity (remember simple isn't easy). I think Go will continue to go quickly because of these attributes.

Re: Frameworks Round 6

#69

Post by MetaCosm »

bhauer wrote: post #47
continuations wrote: post #43

cpoll-cppsp made huge performance gains from round 5 to 6. For example multiple queries went from 1,872 rps in round 5 to 7,252 in round 6. What caused that? Also what happened to cpoll-cppsp in the plaintext test? Its performance there took a deep dive.

I know that the contributor of those tests made several changes. We weren't able to identify why it fails dramatically on the plaintext test, but I suspect it's a combination of the two unique characteristics of that test: the use of HTTP pipelining and higher client-side concurrency. My guess is that the pipelining in particular is causing problems.

I really hope you guys start doing more in-depth high-concurrency testing. This is a huge risk / problem with many frameworks and kits. It seems to be a blackhole in your tests for some reason, which is a shame because the are so well done in other regards.

Having a framework which falls down horribly at high concurrency is something people need to know about -- in how they structure and design applications and how they structure deploys. It can also help them pick frameworks that fit them better (some frameworks will do great at high concurrency, some won't).

Can't wait till you start adding high concurrency (which should NOT require any code changes from the implementation providers, you add a zeroes to the concurrency.. 100, 1000, 10000 tests).

Re: Frameworks Round 6

#70

Post by matdrewin »

iaskwhy wrote: post #6
columbo wrote: post #4

I'm really surprised at the performance of C#... honest no-flame question: how is possible it that Python is beating C#? I've been out of the .NET world for several years, almost a decade, but I always assumed they would be at Java level performance. edit add: This is really fantastic work

I guess you need to change the Hardware to "Win" to see it shining.

Java still beats it on Windows.
Post reply on HN