On Mon, Jun 10, 2019 at 7:50 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > > 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.
I think you should at least try to apologize for your rude behavior, but again you are ignoring all others' valid reasoning and concluding your make sense while others don't. That's a very good point to end the discussion. I'll not be responding to your trolls. >> > 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/CAMmz1OcZYi9jewmewAB-JSQCF-c3ctaUKO%3Ds1Stf9HBXG%3Dhcbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
