Date: Sat, 7 Jun 2014 21:15:29 +0100 From: Igor Mozolevsky <igor@hybrid-lab.co.uk> To: Adrian Chadd <adrian@freebsd.org> Cc: Hackers freeBSD <freebsd-hackers@freebsd.org>, Daniel Janzon <janzon@gmail.com>, Dirk Engling <erdgeist@erdgeist.org>, Ian Lepore <ian@freebsd.org> Subject: Re: Best practice for accepting TCP connections on multicore? Message-ID: <CADWvR2iyXQ6SkA4Dhy_A3QxsN5sutbC2wS3UpkptBz48Fp8=ZA@mail.gmail.com> In-Reply-To: <CAJ-Vmo=qo5gGmD6PAeoGLTRpS=wk0=Bm%2Bc49NHLM2BBhVHuphQ@mail.gmail.com> References: <CAAGHsvDhaqQbwir5P%2BoaH_Qa8VZ0aj9A2SGrn%2B2shJMQ21B6Jw@mail.gmail.com> <alpine.BSF.2.00.1406070252270.21531@erdgeist.org> <CADWvR2gkeNaeVPizq_VubWhEHy3ywURJOdv9C=6PNybwYyFqRg@mail.gmail.com> <CAJ-Vmonm3aZr=kP293x90Am7VzWQQ65cTE8fiTZ6KAECegoZGQ@mail.gmail.com> <1402159374.20883.160.camel@revolution.hippie.lan> <CADWvR2guSYMKEm2HkzXNVuO%2BVS6=_a9jFBmKcSE2BzjYfiaUrQ@mail.gmail.com> <CAJ-Vmom=QOZtn1jQADPZfV10TXD4aoNQT7jhip_sp_=zQ04jog@mail.gmail.com> <CADWvR2getzzd8we%2BYSQS6vq-7kJn2j-3WhQxWQAP9O8GNLWZOQ@mail.gmail.com> <CAJ-Vmo=qo5gGmD6PAeoGLTRpS=wk0=Bm%2Bc49NHLM2BBhVHuphQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 June 2014 20:38, Adrian Chadd <adrian@freebsd.org> wrote: > On 7 June 2014 15:26, Igor Mozolevsky <igor@hybrid-lab.co.uk> wrote: > > > I did say it was in Java, but so what? By 2008 Sun were going out of > their > > way to make Java both scalable and zero-cost. The point I was making was > > that we set off with the assumption that kevent-based sockets are faster, > > therefore server (as a whole) was assumed to have a higher performance; > and > > never bothered to actually measure it. On coding complexity front, from > > slide 36: > > > > The story of Rob Van Behren > > (as remembered by me from a lunch with Rob) > > > > Set out to write a high-performance asynchronous server system > > > > Found that when switching between clients, the code for saving and > restoring > > values/state was difficult > > > > Took a step back and wrote a finely-tuned, organized system for saving > and > > restoring state between clients > > > > When he was done, he sat back and realized he had written the foundation > for > > a threading package > > Right, and he implemented a _userland_ threading package. He tried > writing a generic framework for doing this stuff, likely with > coroutines, and yes he ended up with a userland threading library. > This doesn't surprise me. > Not quite - the gist (and the point) of that slide with Rob's story was that by the time Rob wrote something that could comprehensively deal with states in an even-driven server, he ended up essentially re-inventing the wheel. The undeniable truth of the current state of CPU architecture is that while the GHz remains the same (and in a lot of cases is actually going down), the number of cores is on the increase, so it makes little sense to have a server that doesn't take full advantage of all available resources. Paul Tyma's presentation posted earlier did conclude with various models for different types of daemons, which the OP might find at least interesting. We can do better. <snip> Quite likely- but the OP was asking what the current state is, and not what could happen X years down the line. -- Igor M.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADWvR2iyXQ6SkA4Dhy_A3QxsN5sutbC2wS3UpkptBz48Fp8=ZA>