On Tuesday 26 October 2010 19:36, Rob Landley wrote: > > The only piece of software of the 1024 CPU machine which > > _has to be_ threaded is the kernel, everything else is easier to > > parallelize on a task basis: don't waste time degeloping, say, 1024-CPU > > parallelized gzip - instead, run thousands of gzip copies! > > Which then wind up talking to each other through pipes or fifos or sockets, > and > you have a scalability bottleneck in a select statement sending the data > back. > Less so now with the new pipe infrastructure, but still, you have to copy > data > between process contexts because fiddling with page tables for non-persistent > shared memory is _more_ expensive than copying, and it's a cache flush either > way...
No, not _those_ tasks. Bigger tasks. When you run gzip, you run it as a part of a larger "task to accomplish something". E.g. maybe you are processing Mars Reconnaissance Orbiter photos, and archiving step in pipeline compresses them. Then, do not bother creating insanely parallelized gzip (and insanely parallelized image analysis software, and insanely parallelized database...); instead, process in parallel *insane number of photos* using run of the mill, simple, *single-threaded* tools. This may even be faster, since you do not need to bother with locks, cacheline bouncing and such. But more importantly, you have so much less complexity and fewer bugs to fix! (If you do not have insanely many photos to process, but just a few, in most cases today's CPUs are fast enough to not optimize for this case.) > Threads are a tool, just like object orientation. There are times when it's > appropriate and very helpful, and times when shoehorning it onto a problem > makes things worse. Right. Use them only when you must. > > Readability. !strcmp() reads as "not strcmp" - ? > > In the shell, 0 is success and nonzero is failure. In C, 0 is failure and > nonzero is success. In strcmp() there's greater than, less than, and zero. > Anybody who can't keep all these straight is going to have to be very good at > writing test suites. > > > strcmp() != 0 reads as "not equal" - much closer to what it actually do. > > The linux kernel style guys actually edit out those kind of useless > appendanges as part of their style checking during code review. So you're > adding stuff to make the code look less like the kernel does. > > Do you similar bloat if (x) to say "if (x != FALSE)"? I see that kind of > thing in people who are new to C, but not much in people who've been doing it > for a while. I think that even though we do understand what "if (strcmp(...))" mean, it doesn't follow that this is the best style. With a style which encourages use of == 0 or != 0 with strcmp, I started making less bugs with inverted logic in string compares... if ([!]x) is definitely ok for bool and pointers. For ints, it is sometimes good to write if (x != 0), especially if the code aroud that place is complex-ish and it's hard to figure out the type of x. Not a hard rule. > There are some studies out there that say there's an optimal module size, > above which defect density increases because you can't keep all the code in > your head at once, Of cource, no one can keep infinite amount of structure in the head. Readability simply moves that limit a bit farther, by making every individual sub-fragment of code less taxing on the brain. > Even comments need to pull their own weight, there are times when > deleting unnecessary comments Yes. Good comments are an art (and quite distinct from "verbose comments"). > I vaguely wonder if there should be a place we list busybox features that > other immplementations don't have. For example, busybox mount never needs to > say "-o loop", because you can trivially autodetect when you're being asked > to > mount a file on a directory. (And directory on directory or file on file are > bind mounts, although I don't remember if I made it autodetect that. IIRC no, "file on file" bind mounts aren't working. > > Wondered "how the hell Rod managed to squeeze sha1 into that few lines" :D > > Read the darn algorithm, understood what it was doing (if not why) long > enough > to implement it. Done, shrank, sped up & pushed to bbox. Faster than old bbox one on 32 bits, sadly, slower on 64. With better gcc, 32 bit code can get a bit faster still. (Stupid robot did not free a register parameter to use it inside the loop.) Thanks! > > > Busybox has three or four different implementations of each piece of > > > infrastructure in the sha1sum/md5sum stuff, depending on the "size vs > > > speed" knob. I focused on doing it once in a way that was easiest to > > > read and to understand. > > > > > > I.E. my implementation was simple first, worrying about small and fast > > > second. The code you were referring to (current as of October 19th, git > > > says) has a size vs speed config entry leading to a heavily redundant > > > implementation, at the expense of simplicity, with rather a lot of what > > > it's doing hidden in various macros. > > > > This "size vs speed" thing im md5 is not mine. busybox-1.00 has it too. > > As you can see, sha256/512 which I added don't have them. > > I need to sit down and read through busybox's implementation, figure out what > bits of it are md5 and what are shaXXX and what benefit it gets from > sharing... Everything except sha512 uses common 64-byte stuffing machine and finalization code (that' what I referred to when I said that it was recently improved). sha512 uses widened copies of the same algorithms. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
