Koromix

For some reason I completely missed that show, it looks great. Thanks!

Programming is about making a piece of hardware do what you want to do. Many people seem to forget that, or treat it as an afterthought. "Oh yeah, it's slow. Hopefully the compiler will do its magic!". Except it does not, because it cannot rewrite your code to match what the hardware wants.

This is why we now live in a world where many programmers don't think there is a problem with running web servers on programming languages that slow down computation by orders of magnitude, in addition to being very cache and memory inefficient. We can scale! Yeah sure, use 50 servers where one could have done it. We would also use Saturn V to launch small individual LEO satellites, you know. Why not? It works!

Taking a functional approach is fine for a lot of tasks, and when you can do it without cryptic or inefficient code, you should do it. But when imperative is easier, use that instead.

The reader scans all queues, without locking. If one is non-empty, then you lock it and pop an item. Only if are all queues are empty then you hit the slow path and wait on a synchronization primitive (condition variable).

Of course if you can assume that the queue will always be very busy, you can ditch that too and poll instead. Polling is often bad, but not always. When things go very fast, it can be more efficient.

A good example of that occurs with the new storage NVM Express storage technologies and Linux, where the traditional I/O completion interrupt used until now is starting to bottleneck: https://lwn.net/Articles/663879/

Neil Brown published an interesting series about Unix design mistakes a few years ago: https://lwn.net/Articles/414618/

The first part of the "Unfixable designs" article is about Unix signals.

mmap() tricks you into thinking you can directly access the disk. What really happens when you access the mapped data is that the CPU generates a page fault, the OS takes control, copies the data from disk to physical memory and maps the page in your address space. So essentially it is a convient way to do read().

The mmap() model is good. The current page fault mechanism, not so much.

Consumer OS I/O software stacks are completely unable to deal with this. It was fine for spinning drive latency, it's okay(ish) for high-performance SSD but the open/read/write model just cannot work that fast. It's several orders of magnitude off.

Assuming we keep the file system model, I'm guessing some kind of direct memory mapping is in order? Anyone knows what's ahead of us on the software side, to take advantage of this kind of latency?

> is an ability to push asynchronous messages/events there (usually from different threads), and to get them back (usually from one single thread) – in FIFO order, of course.

It is worth noting that FIFO only holds for messages coming from a single thread. If you have one thread posting keyboard events and another mouse events it is very possible that the reader will get them in the "wrong" order, even with tens of milliseconds separating them from the user's POV.

Now it seems obvious when I say it, but it is easy to forget that when you develop the reader side, especially since most of the times the ordering will hold. This leads to intermittent and non-obvious bugs down the line.

On the other hands, if you fully acknowledge the lack of ordering guarantee, you can use that to make a more efficient queue by using one-buffer-and-lock-per-thread. Each producer fills its own lock-protected queue, and the reader just needs to find a non-empty queue, lock it and pop an item, without any penalty for the other threads.

Of course, the inter-thread ordering will be even worse but you keep the ordering of events from one producer, which was the only actual guarantee you had to begin with in the naive version.

Indeed it behaves much better on a demo I found elsewhere, sorry for the inaccurate comment.

The overhead for a simple textarea seems significant. On Firefox there are stalls (up to 500 ms) if I type "fast". I've tested the form on http://redux-form.com/5.2.5/#/examples/simple?_k=8ukhm8 (specifically the textarea).

Here is the CPU time graph during my tests: http://imgur.com/we9uGQ7

EDIT: OK apparently it's not accurate, see comment below.

They are not plenty fast. You know you don't have a fast platform when the best you can do is scroll + a couple animations at the same time.

And even then, HTML+JS apps often cannot do that without lag. Not saying that native apps are necessarily better (especially on Android), I die a little inside each time I unlock my phone and the unlock screen fails to keep up with my finger.

We had smooth scrolling in the late eighties on the Amiga 2000 (7 Mhz and 1MB of RAM) with CygnusEd: https://www.youtube.com/watch?v=L41oIvre9K0

The fact that we barely manage to do that with HTML+JS on what amounts to supercomputers (relative to the time) should not make anyone proud.

"Does every single screen need to have 60 fps animations, with activities that launch from the exact x/y coordinate where my finger touches the screen?"

This makes it sound like smoothly animating a few rectangles is hard. The only reason it is true is because the web stack is, for lack of a better word, complete crap. It was fine for rendering static text and a couple images with no graphics acceleration, I guess.

Today, AAA games can redraw complete frames of 3D worlds inside of 16.66ms (along with processing physics / gameplay / networking / input) and I'm supposed to accept slow and janky GUIs on my desktop?

I just can't. I tried Atom, and even though it's usable, it's not exactly snappy. The complete waste of my hardware's resources makes me too sad to enjoy any good feature it might have. The web is stuck with this, that's "fine" but could we keep the desktop out of it?

People are used to the POSIX readiness model, that's all. And you can kind of make it work on Windows, even though the performance is not great. OTOH, porting an IOCP-oriented application to Linux will give you catastrophic performance because you need to use many threads to replicate the async model on top of the synchronous Linux I/O calls.

And for some reason, people get very defensive when you point out some of the advantages the NT kernel has over Linux. I mean, I use Linux, I don't like to use Windows but I have no problem admitting the IOCP model is better and async I/O on Linux is a sad broken mess. Denying it only serves to keep it that way.

I only have superficial experience with it, but from what I can tell there is a huge mismatch between IOCP and the UNIX readiness/poll model, and from my experience most server programs are written primarily for the latter.

You need to design your server code somewhat differently to take advantage of IOCP. What many UNIX-like softwares do instead is bend IOCP or WaitForMultipleObjects() to behave like Linux. It works, but the performance is not there.

Note that I haven't checked the code for any of the softwares in your chart so I could be wrong.

And then you go to the Features page, with a box on the right clearly listing "GNU/Linux and Unix / Windows / Mac OS X" as supported plartforms :) With "Native look and feel" in the box just below.

I disagree with the current GTK direction, but it's not my project and I accept that. If the focus of the project has changed, update the website(s) and documentation.

Also the HTTPS stuff pointed out by distances.

I understand this, even though the constant breaking of GTK apps after each update annoys me to no end.

But you might want to discuss updating https://www.gtk.org/ and other sites for that matter. Quoting the first lines of the home page: "GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces".