inotify

Posted Jul 22, 2006 9:51 UTC (Sat) by drag (subscriber, #31333) [Link]

I am sure that it's worth complaining about... but it's a lot better then the 'famd' it replaced!

For instance with famd if I had mount point or something like that in my home directory then it would crap out if I tried to go more then 2 directories deep. And basicly cause anything to do with gnome that concernes files (nautilus mostly)

With gamin there is no problem.

I think that a huge part of the problem we have with performance on Linux desktop nowadays is that everybody was scrambling to get just the basics in place and everything more or less working.

Hal/Dbus/X.org/inotify(and it's userspace helpers)/desktop search stuff/udev.. etc etc. All of it is thrown together and made to 'make it just work'.

Now it seems that the push is going towards making 'make it work well'. Filling out the blanks, improving performance. That sort of thing.

Posted Jul 21, 2006 16:45 UTC (Fri) by cventers (subscriber, #31465) [Link]

Ah, good point. Well, at the very least, having build-time inotify
support would assist some of us (crazy Gentoo users that spend half our
lives watching a compiler) immediately and others later ;)

But yes, just attempt inotify at startup. -ENOSYS? Ok, we'll try this
another way.

Posted Jul 23, 2006 17:51 UTC (Sun) by NAR (subscriber, #1313) [Link]

in practice you must build something which tests for inotify at runtime and falls back to dnotify or even polling.[...]However, this is perfectly doable.

Yes, but I'm afraid this is way above the avarage application programmer's level.

Bye,NAR

Posted Jul 21, 2006 16:42 UTC (Fri) by cventers (subscriber, #31465) [Link]

There is a difference between a vendor choosing to make i386 releases and
programmers refusing to use the features of any more modern chip simply
because a few i386 boxes are still out there clocking their ops. One of
the great things about having open source code is that you can download
and build your own packages optimized just how you choose (indeed,
distributions like Gentoo even make it easy). You're doing well if your
code will build for old hardware but otherwise make use of new features.

The problem with the least common denominator argument isn't really the
suckiness of the reality that the argument represents, it's the fact that
it ever gets used as an excuse to write code in which "sub-optimal" is a
gross understatement.

Furthermore, the fact that different systems require different code to be
optimal is a fact of life. It's why we have abstraction layers at all. If
every system was the same, operating systems either wouldn't exist or
they'd be a hell of a lot more simple, and that goes for everything from
the bottom of the stack up. It's very much a reality, as you put it.

When you choose to support multiple systems, you should be ready to write
multiple implementations of the same function. Writing to the least
common denominator -- and not ever specializing -- is a cop-out.

> "Optimization without insturmentation is just mental masturbation"

I've never much been a fan of that argument either, because it's often
used to justify incredibly sloppy / inefficient code. The quote as it
stands is simply imprecise. There are /some/ optimizations which are
questionable enough that you very much want insturmentation before you
write large chunks of code, but the world just isn't black and white.

Put another way: I would like to think that any reasonably talented
systems programmer would know that polling files several times a second
for something like menu entries, or assembling entire HTTP queries and
responses several times a second to communicate with a system tray icon,
is a bad idea -- something that could be optimized. No need for
insturmentation at all.

These arguments (the least common denominator and the no optimization
without insturmentation) really irritate me, because I started on a 386
and many common operations take more wall-clock time today than they did
back then. I'm now on a Pentium 4, for chrissakes, with a gigabyte of DDR
RAM. What has happened is that as the generations go on, some of us seem
to be trading in programmer time for CPU time (read: being lazy).

It seems like a perfectly acceptable bargain, and on some level it is. (I
don't think any sane person expects you to write desktop apps in
assembler, even though if you somehow had the dedication and
concentration required you'd make something at least slightly faster).
The problem is that programmers are _being lazy_ and choosing points on
the "diminishing returns" curve that are well before returns start to
diminish.

I'm sure not all of Dave's identified misbehaviors were even apparent to
the programmers in question. Many of them are probably 'bugs'. But when I
hear about applications hammering the filesystem many times per second,
or using HTTP as an IPC mechanism between a system tray icon and another
program, I worry that we've all gone just a little bit crazy.

So I propose a new quote:

"Sensible optimizations give pleasure by default"

Posted Jul 21, 2006 17:42 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

The userland is normally compiled for i386 instructions only, but scheduled (instruction selection and ordering) for i686. The code where full i686 (or whatever) does make a real difference is far in between (and there you do get i686 packages).

Distributions (and their users!) do pay a hefty price if there are zillions of package versions by CPU type.

Posted Jul 22, 2006 6:07 UTC (Sat) by dvdeug (subscriber, #10998) [Link]

As far as I know, none of the modern distros build for a stock i386. You can't; the C++ libraries depend on i486 opcodes to properly implement threading, and while there are i386 alternatives, they're slow and unreliable.