Karl Vogel wrote: > >> Stan Hoeppner said: > S> for k in $(ls *.JPG); do convert $k -resize 1024 $k; done > > Someone was ragging on you to let the shell do the file expansion. I > like your way better because most scripting shells aren't smart enough > to realize that when there aren't any .JPG files, I don't want the > script to echo '*.JPG' as if that's actually useful. :-) I thought about saying something about .JPG instead of .jpg. Unix is all about lower case after all. But I restrained myself. :-) :-) $ for i in *.doesnotexist; do echo $i; done *.doesnotexist As to your comment about shells passing the glob off when it doesn't match, that is a good comment. That wasn't really too much in my style of coding and so had missed it. Thanks for keeping me honest! Just to push on it a little bit more I could do this: set -- *.doesnotexist for i in "$@"; do echo $i done That avoids the problem and still avoids spawning another process. And depending upon what I was doing I might do something completely different. > First things first: are you absolutely certain that running two parallel > jobs will exercise both CPUs? I've seen SMP systems that don't exactly > live up to truth-in-advertising. If you stuff two "convert" jobs in the > background and then run "top" (or the moral equivalent) do you SEE both > CPUs being worked? When was that in terms of kernel versions? Was Intel hyperthreading also involved? Because your description matches very closely running a two core system with Intel hyperthreading on an older Linux kernel. Here is the problem I know about. On a dual cpu system with hyperthreading the Linux kernel saw four cores and numbered them 0, 1, 2, 3. But of course zero and one were on one core and two and three were on the other core. The first process would run on, say, zero. The second process would run on the next core, say, one. To Linux of that day it thought it had allocated those processes onto different cpus. But of course both were running on the same cpu, each getting half of it and taking twice as long to run, and the other cpu was idle. A big problem. I always disabled Intel hyperthreading to avoid that problem. It was more trouble than it was worth. Also my benchmarks showed that HT would slightly slow down single threaded simulation processes (mostly Spice and other simulations) that we were running. But as far as I know this has now been addressed and the Linux kernel now knows about hyperthreaded cpus. It seems that with recent kernels that the cpu allocation works okay even in the presence of fake cpus through hyperthreading. So I think the problem you describe is now behind us. Bob
Attachment:
signature.asc
Description: Digital signature