Shell Programming and Scripting

I wrote a very simple script that matches combinations of alphabetic characters (1-5). I want to use it to test CPU speeds of different hardware/platforms. The problem is that on multi-core/processor systems, only one CPU is being utilized to execute the script. Is there a way to change that? Shouldn't the OS automatically start using the second, third, (etc..) CPU once the first one becomes overloaded?

The script:

Code:

#!/bin/bash
for a in {a..z}
do
 for b in {a..z}
 do
  for c in {a..z}
  do
        x="$a$b$c"
     done
    done
   done
echo $x
exit

Thank you!

J.

If you want to benchmark a system, use a language with less run-time overhead like C, especially if you're just burning CPU.

As for your question: no, shells don't do multi-thread by themselves (I'm assuming you mean "shells" not "OS", since most OS use all cores anyways). Why should they. A shell is designed to interact with a user who (more or less) knows what he/she does. That they're scriptable is a nice value-adding feature.

Besides, how should the shell divine what parts of your program can run in parallel and which can't? What variables should be shared across threads? How should it avoid deadlocks? That stuff has (as of yet) to be considered by a programmer, and those can usually handle backgrounded subshells and a wait call or two.

P.S.: There is no such thing as an "overloaded CPU". A CPU can be in (almost) any state between "idle" and "completely utilized", but that's it.

I agree quite with pludi. But the thought sounds very interesting. What is more interesting is that all the commands that are run in the shell script have the same parent process id, so those commands would run in the same core (i could be wrong here). But if I am right, then it means that if you can detach your commands in your shell script from the parent then each of those commands could potentially execute in a different core. And now I wonder, if there could be a way to share states or variables across them. clearly "No", unless you implement shared memory in shell, that brings back the point 'Why use shell scripting for this task?'

The answer to the "why shell" question is simple: I don't know the first thing about C. Another reason is portability. It's easier to test different systems if the program doesn't have to be compiled for a specific architecture. But since there is no way to make this work in bash, I guess C is the way to go. I know this is not the right forum but I would really appreciate if any of you could convert my script to C.

Thank you!

J.

Converting it to C won't make it multithreaded either. You need to learn what multiprocessing and multithreading is.

By the way, proper ANSI C is as portable as any shell script. And proper ANSI C with POSIX threads will run threaded on any POSIX platform.

I have a pretty good idea of what they are. Coding is another story.