On Tue, Sep 15, 2009 at 06:28:33PM +0200, frantisek holop wrote: > hmm, on Tue, Sep 15, 2009 at 08:41:22AM +0200, Claudio Jeker said that > > Hah. That's why he did not update his site since 2003. Do you realy think > > that OpenBSD 3.4 and 4.6 are the same? > > nobody is arguing 3.4 and 4.6 is the same. > or that that particular benchmark has any more than historic value..
It had no value because he didn't test OpenBSD at all like the other OS'. > > no matter how you put it, both a well done and an incompetent > benchmark succeeds on some level: some things were looked into because of it. And on the system level nothing really changed. We are not debating the net gain. > > > The reason for C has nothing to do with speed. > > "nothing" is a strong word. but be it. c and speed > shall never be used in the same sentence. > > > And here again comes this style of uninformed dumb rant. Why do you think > > a web server will not do that much without sendfile()? Honestly it is > > exactly the opposide, a web server that never touches the disk for content > > delivery will outperform all others and can server enough data to fill a > > can you show me the magic openbsd webserver that never touches the disk? Congratulations you figured it out. Those don't exist. > since you picked on sendfile(), let's turn it around. i dont see your > numbers to prove that sendfile() doesn't help. how is your statement > any better informed than mine? it's just easier to say: nah, it wouldn't > help that much at all, it's overrated anyway. And it wouldn't because of that disk access you figured out earlier. > having said all of this, i've been here for some years now. i know > speed is not the priority for this project -- and i am fine with that > otherwise i wouldn't be here. i am simply sick of all this downplaying > of any and all benchmarks (micro and macro), when everyone who writes > programs knows that there are important benchmarks for finding > bottlenecks and improving program/data structure. Of course speed is of concern to this project? WTF kind of ignorance is that? There are, generally speaking, no "go faster" buttons. The code is written in a way to not suck and is enabled of course. I'll downplay all dumb benchmarks. That is why the word dumb is in that sentence. There is no doubt that other OS' are faster (as in time elapsed) on certain things. This doesn't make the underlying algorithm any worse however your fancy benchmark will tell you just that. You don't need a degree in astrophysics to understand that biglock is sub-optimal. > i would be more than happy to see a "competent" benchmark by someone > who knows openbsd intimately. but exactly because of the prevailing > mindset no one ever bothers. so when it comes to openbsd performance > it's all just legends and hearsay, and if being low, hardware, software > and user gets blamed. And again you assume this never happens. I have seen plenty profiles from other developers. What makes you think that information is valuable to you? If you don't get why benchmarks are, generally speaking, badly run and even worse interpreted why would you understand a full profile of an OS? This is exactly the point you are missing. > the devs are sitting around smug saying nothing until someone comes > up with this theme again and then they send something like: > > i have a bgp machine forwarding 800MBit/s of real world generic > internet traffic. can handle at least twice that. > > what can i say? i am happy for you :] And the person who does that has some sort of vested interest to lie to you? And he also has the worst intentions for the community? You are such a victim, I truly feel for you.
