On Mon, Jun 10, 2019 at 11:28 PM Tong Sun <suntong...@gmail.com> wrote:
> There is a second test well before your this post, which is a direct > translation of Perl code, that is now reading and writing directly to > a socket. Hanging on to the first test method and not referring to the > second test is not a very constructive way of discussion, let alone > using words like "ridiculously ...". > The updated test only changes *both* not to implement a web server. My point was, that this is not a realistic test case.e > Over 90% of the code are NOT doing regular expression matching. > Focusing *only* on regular expression, not >90% of the rest, is not > very convincing but miss the elephant in the room, at least seems to > me. The amount of SLOC is not important, however, but where time is spent. When adding some basic CPU profiling to the Go code, it spent ~10% of its time RE-matching, ~10% in various allocation-related activities, ~75% blocking in syscalls and the rest in other various network related runtime code. That's pretty much what I meant - in terms of actual CPU time used, RE-matching (and some allocation) is pretty much all that's happening. Now, I don't know how to profile Perl code and I'll admit that the netpoller etc. are part of the language and as such matter for the comparison. But the more direct the translation becomes, the less these code-paths will differ in performance and the more realistic your scenario gets (in terms of concurrency used and required), the more I'd expect Go to be favored by it. Please don't get personal and emotional over technical discussions, > and please refrain from using terms like "ridiculously simple" or > "reading in tea-leafs" in future discussions. It is inappropriately > condescending, thus not the correct attitude of communication. It > does not align with the code of conduct of this mlist, and neither of > google's, I believe. > > If you have test results that contradict with mine, please show me > yours -- Let's talk the data, and not let the emotion get in the way > of technical discussion, and fact the fact, whatever it is. > I am not contradicting your data, I'm contradicting your conclusions. That's why I said "reading tea-leafs": You seem to look at the same data and come to conclusions that just don't connect for me. For example, your original post says that the mean response time for your Perl code is 110.875ms resp. 0.222ms and for your Go code it's 83.229ms resp. 0.166ms - and yet you claim that your test shows that the mean response time is 8x higher for your Go code than your Perl code. And in your second post, you use `hey`, but then just… throw the results out, because you don't understand them (AIUI). I just don't know how I'm supposed to handle that discrepancy. All of this just looks like really bad science to me. ISTM that defining the criteria beforehand and designing the test to measure exactly those criteria is the most reasonable way to reconcile that. If we use "mean response time over X", it seems that so far your Go code is coming out ahead. And note that *I* didn't make any claims about the relative strengths of programming languages here. IMO the onus is clearly on you to show your work when making these claims. I don't actually care. > Anyway, all of that being said: While I don't think the test you devised > allows the broad generalizations you are making, ultimately I don't have > any stakes in this (which is why I haven't responded further on the blog > post). If you like Perl and think it performs good enough or better for > your use case - then go ahead and use Perl. No one here will begrudge you > for it. > > As I've comment in the blog many times, I'm not trying to prove Perl > performs better than Go. On the contrary, I was trying to improve Perl > performs with Go, that's why the whole thing get started, as I have > replied to your comment in the blog:"that's why I was rewriting the > Perl code to Go". > > It is still the case, and I want to try out everyone's suggestion to > see how things can improve. > > Moreover, if you have taken a look at my second test, you will > understand my other goal is to make it clear "who and what to trust". > Because if you have taken a look at the httperf test result I posted > to this mlist before you reply, you may have realized that, of all the > performance testing tools I've used so far, all are suggesting Perl > performs better than Go, except for httperf. So maybe the performance > testing tools are biased toward Go, and I made it clear in my second > blog that I want to get to the bottom of it. > > > All of that being said > > > > IMO this is just not a meaningful test. Or its results are totally > unsurprising. > > Again, I was trying to improve Perl performs with Go. That > "ridiculously simple" Perl code is the foundation of the Debian dbab > package, and I was trying to improve it. > > It might be meaningless to you but it is perfectly meaningful to me. > Please don't be so judgmental. > > > On Sun, Jun 9, 2019 at 4:54 AM Justin Israel <justinisr...@gmail.com> > wrote: > >> > >> I'm wondering about a couple factors in this comparison that seem to > make a difference in my local test: > >> > >> I think perl sockets are write buffered. So would the equivalent be to > wrap the net.Conn in bufio.NewWriter(c) and flush before the Close? > >> Since this is a straigh-line test where both servers are not using > concurrent handling of connections (uncommon for a Go server even on 1 > core), would it not make sense to run the Go server with GOMAXPROCS=1? > >> > >> - Justin > >> > >> On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote: > >>> > >>> I had always believed that the web projects build with Go should be > much faster than Perl, since Go is a compiled language. > >>> > >>> However that belief was crushed brutally last night, when I did a > comparison -- the Go implementation is 8 times worse than the Perl! -- the > mean response time jumped from 6ms to 48ms. > >>> > >>> I know this is the simplest possible web server, but still, when it > comes to simple web servers like this, I have to say that Perl performs > much better than Go. > >>> > >>> I don't think there is much I can twist on the Go side, since it can't > be more simpler than that. However, I also believe it won't hurt to ask and > confirm. So, > >>> > >>> Have I missed anything? Is it possible for me to make my Go > implementation anywhere near the Perl's performance? > >>> > >>> Thanks > >>> > >>> > >> -- > >> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com > . > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF62D5v%2BRiGtAtzuH0wAHzCLqcwNUidC1Oe2KN9DfRv6Q%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAMmz1OcefkrZN3_5R7%2BbjuwHjRx%2BLzttaiXmer0ytwmXUjxN_A%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHBnaipwLtUi4eq%3D8Xx33qGrNN6hq5yMM52G_6bV464jA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
