From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Subject: Re: [9fans] blanks in file names In-reply-to: <61fc59076e43ac52fe96127834dadbe8@collyer.net> To: 9fans@cse.psu.edu Message-id: <200207211947.g6LJlvv14281@dave2.dave.tj> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Date: Sun, 21 Jul 2002 15:47:57 -0400 Topicbox-Message-UUID: d34a75bc-eaca-11e9-9e20-41e7f4b1d025 I just noticed that there were a few more messages in this thread that got lost in my email (and I can't really blame elm this time, either) :-( I know we'd all like to kill this thread, but I can't look at this post without replying; it's just too misguided to ignore. The reason I want a new open is _not_ that the current open isn't efficient enough for my tastes. The reason I want a new open is that the current one was lifted straight out of the old UNIX design, and miserably fails to accomodate the modular approach that UNIX no longer provides, but Plan 9 has found some brilliant ways of recreating (which is why I got my original Plan9 installation in the first place). The fact that the new open happens to be more efficient than the old one for many applications is merely a neat side effect, one that I only brought up when I was accused of making open _less_ efficient (and I didn't see you pipe up then to complain that cost doesn't matter). In UNIX, paths never became real objects in the sense that Plan 9 has promoted them to, because UNIX has very primitive filesystem serving. In Plan 9, it becomes a lot more interesting to have commands simply create temporary filesystems and populate them with the results (e.g., ls creating a directory with each file being one of the entries requested, and the contents of each of those files being information about the entry). UNIX tried to make everything a file, but it got bogged down with plain-text IO. Plan 9 aligned itself squarely with the file philosophy, and I see no reason to stop short when filenames are concerned. - Dave BTW - I don't know if it's worth noting that while strlen (sequential memory accesses) is an order of magnitude faster than DES (repeated computations + sequential memory accesses), simply getting the length from a structure (direct memory access) is an order of magnitude faster than strlen. Geoff Collyer wrote: > > My apologies for dragging this out, but I think this gets to the heart > of the matter. > > The cost of strlen doesn't matter, it really doesn't matter. I can't > recall seeing a real-life program where the cost of strlen was more > than trivia. > > A quick comparison on Plan 9 shows that strlen runs at 19 times the > speed of DES, using the same 64-byte string as input each time, which > is almost certainly longer than the average string. DES is really > slow, by design; it's not just a question of a few more memory > accesses; it's just hard to do the bit-swizzling quickly in software > (though it can be done relatively quickly in hardware). > > One of the big achievements of Unix was to get people to stop worrying > about the microseconds and look at the slightly larger picture of what > could be done if your first concern were not microseconds, and that > was a quarter-century ago! With processor cycles being so cheap and > available now, it's generally not worth worrying about expenses until > they cause a real (measurable, reproducible) problem. Proposals based > on supposedly greater efficiency for a new open(2) interface are not > worth considering, particularly when open's efficiency isn't currently > a problem, and the new interface is ugly, incompatible with the > existing clean and simple one, and purports to solve non-problems like > allowing NUL and slash in file name components. > > > One downside of APE is that it's made some people think of Plan 9 as > Just Another Goddamned Unix Implementation. If you're not interested > in exploring what's new in Plan 9, and are offended that realloc isn't > provably optimal or that GNU configure doesn't just run out the box, > why are you using Plan 9? FreeBSD, OpenBSD, NetBSD and Linux are all > available at no monetary cost. >