I am struggling to find a way to implement an asynchronous evolutionary process in MATLAB.
I've already implemented a "standard" GA that evaluates the fitness of individuals in parallel using MATLAB's parfor routine. However, this also means that the different workers in my parallel pool have to wait for the last worker to finish his assesment before I can create a new generation and continue with my parallel fitness evaluation. But when the fitness assessment time is very heterogeneous, such an approach can involve significant idle times.
The suggested solution in the literature is what is sometimes called asynchronous evolution. It means that there are no generations anymore, instead every time a worker becomes idle we immediately let him breed a new individual and evalute its fitness. As such there is hardly any idle time as no worker has to wait for others to complete their fitness assessment. The only problem is that those parallel threads/workers need to work on the same population, i.e. they need to communicate to each other whenever they want to breed a new individual (because they need to select parents out of a population that is constantly altered by the workers).
Now ideally you would control each worker separately, letting him access the joint population to select parents, evaluate the offspring's fitness and then replace a parent in the joint population. That involves an ongoing iterative process where parallel workers need to exchange and alter joint information and doing independent fitness evaluation.
My big question is: How can this be achieved in MATLAB?
Things I've already tried:
MATLAB's 'spmd'-functionality using the labSend and labReceive functions but this also seems to involve waiting for other workers.
creating jobs and assigning them tasks. Does not seem to work as multiple jobs are processed sequentially on the cluster. Only tasks within a job use multiple workers but that fails since you can't assign tasks dynamically (you always have to submit the whole job anew to the queue.
parfeval in a recursive while statement. I do not see how this would reduce waiting time.
So does anyone know a way how to implement something like this in MATLAB?
Related
I have a problem, which is similar to Assignment Problem, described as follows:
The problem instance has a number of workers and a number of tasks. Any task can only be assigned to a subset of the workers. A task should be assigned to exactly one worker. Each task has different difficulty, therefore, workers will spend different time to finish each task. It is required to assign tasks as uniformly as possible: all of the workers spent almost same time to finish assigned tasks.
I can translate this problem to Integer Linear Programming problem: the cost function is to minimize the variance of each worker.
Is the problem well studied? Are there any algorithm to solve it more efficiently? (Approximation is acceptable)
Thanks in advance!
The classical assignment problem deals with assigning N agents to M jobs while minimising the time spent on each job. The problem has a solution in polynomial time, called the Hungarian algorithm, which has a cost matrix C as an input and returns the optimal list of assignments.
In my case, I got the same problem, but with one difference. Each job requires a pair of two works to be assigned to it. The number of agents are chosen such that N is an even number in order for this to be possible.
I am fairly new to assignment problem related questions, so I am not sure how to tackle this problem.
How would one solve this problem?
Edit: Note that a agent can be assigned to at most one task, it can not be assigned to multiple tasks. One can assume M(jobs) = 2N(agents) and otherwise introduce dummy agent or tasks.
Since there are twice as many tasks as workers, you need to double the number of tasks. Since each task requires two workers, you can double the number of tasks by duplicating each of them (ex. Task 1 becomes Task 1a and Task 1b). You would then have an equal number of workers and tasks, and after running the Hungarian Algorithm you can find your pairs of workers by looking at who was assigned to each split of each task.
I want to know the differences between
1. labs
2. workers
3. cores
4. processes
Is it just the semantics or they are all different?
labs and workers are MathWorks terminologies, and they mean roughly the same thing.
A lab or a worker is essentially an instance of MATLAB (without a front-end). You run several of them, and you can run them either on your own machine (requires only Parallel Computing Toolbox) or remotely on a cluster (requires Distributed Computing Server). When you execute parallel code (such as a parfor loop, an spmd block, or a parfeval command), the code is executed in parallel by the workers, rather than by your main MATLAB.
Parallel Computing Toolbox has changed and developed its functionality quite a lot over recent releases, and has also changed and developed the terminologies it uses to describe the way it works. At some point it was convenient to refer to them as labs when running an spmd block, but workers when running a parfor loop, or working on jobs and tasks. I believe they are moving now toward always calling them workers (although there's a legacy in the commands labSend, labReceive, labBroadcast, labindex and numlabs).
cores and processes are different, and are not themselves anything to do with MATLAB.
A core is a physical part of your processor - you might have a dual-core or quad-core processor in your desktop computer, or you might have access to a really big computer with many more than that. By having multiple cores, your processor can do multiple things at once.
A process is (roughly) a program that your operating system is running. Although the OS runs multiple programs simultaneously, it typically does this by interleaving operations from each process. But if you have access to a multiple-core machine, those operations can be done in parallel.
So you would typically want to tell MATLAB to start one worker for each of the cores you have on your machine. Each of those workers will be run as a process by the OS, and will end up being run one worker per core in parallel.
The above is quite simplified, but I hope gives a roughly accurate picture.
Edit: moved description of threads from a comment to the answer.
Threads are something different again. Threads are also not in themselves anything to do with MATLAB.
Let's go back to processes for a moment. One thing I didn't mention above is that the OS allocates each process a specific block of memory which other processes shouldn't be able to touch, so that it's difficult for them to interact with each other and mess things up.
A thread is like a process within a process - it's a stream of operations that the process runs. Typically, operations from each thread would be interleaved, but if you have multiple cores, they can also be parallelized across the cores.
However, unlike processes, they all share a memory block, which is OK because they're all managed by the same program so it should matter less if they're allowed to interact.
Regular MATLAB automatically uses multiple threads to parallelize many built-in operations (such as matrix multiplication, svd, eig, linear algebra etc) - that's without you doing anything, and whether or not you have Parallel Computing Toolbox.
However, MATLAB workers are each run as a single process with a single thread, so you have full control over how to parallelize.
I think workers are synonyms for processes. The term "cores" is related to the hardware. Labs is a mechanism which allows workers to communicate with each other. Each worker has at least one lab but can own more.
This piece of a discussion may be useful
http://www.mathworks.com/matlabcentral/answers/5529-mysterious-behavior-in-parfor-i-know-sounds-basic-but
I hope someone here will deliver more information in a more rigorous way
I often have to run calculation intensive simulations using Matlab. These simulations often take a long time and I expect my computer to use all its ressources in order for these simulations to be completed in as little time as possible.
However, when I open the Activity Monitor on my computer, processor usage is never above 55% and there is often about 1GB of unused RAM.
My question is: why is the processor not used to its full potential, and is there a safe and easy way to change this? Indeed, it would be great if I could get my simulations to be completed in half the time they currently take!
Its probably because you have a processer with multiple cores and that the code you are executing isn't written to run in multiple threads/processes. Unless you specifically write your code to take advantage of multiple cores it will only be able to use a single core at a single time.
A relatively easy way to enable parallel computing is to use the Parallel Computing Toolbox.
Additionally you might consider reading this: http://www.mathworks.com/company/newsletters/articles/parallel-matlab-multiple-processors-and-multiple-cores.html
I have an application that takes voltages and temperatures as analog inputs and does some processing using an algorithm which involves signal processing such as low-pass filtering,
exponential smoothing, and other steps which might typically be done in a high-level programming language such as C or C++.
I'm curious how I could perform these same steps using a PLC, and in particular, the Allen-Bradley Control-Logix system? It seems to me that the instruction set with ladder logic is too limited for this. Could I perform this using structured text?
Ladder logic can do the computation just fine, although it isn't the nicest programming language in the world. It has a full complement of conditionals, arithmetic, arrays, etc.
Your real problem is fitting your computation into the cyclic execution model that most ladder logic engines (and Control Logix) run: a repeated execution of the program in the control from top to bottom, with each rung or computation being executed just once per scan.
If you need to loop over a set of values repeatedly before producing a result, you will likely have difficulty resolving the ladder engines' desire to execute everything "just once" per scan, and your need to execute a loop to produce a result. I believe in fact that there are FOR loop operators that can repeat a block of ladder code just as conventional loop; you need to ensure that the amount of time spent in your loops/algorithm don't materially affect the scan rate.
What may work well is for you to let the the scan rate act as one of your loops; typically you compute a filter by accepting a new value into an array and then computing a result over that array. Since you basically can't accept values faster than one-per-scan-cycle anyway, you can compute at-most-one-filter-result per scan cycle without losing any precision. If your array is of modest size (e.g., 10 values), you can in effect simply code a polynomial over the array as an equation to produce your filter result, and then code that polynomial (klunkily but straightforwardly) as ladder logic.
Control Logix PLCs do not have to execute on a cyclic sweep. I don't have RSLogix 5000 in front of me right now, but when defining the project, you are required to create one Program that executes on a cyclic sweep. But you can create other programs that do not. You can also run them off a trigger (not useful for regular input scanning) or off a fixed timer (very useful for input scanning). Keep in mind that there is no point in setting the input scan timer faster than your instrumentation updates-modern PLCs can frequently execute a scan much faster than a meter can update the data.
One good technique I have used for this is to create a program called one-second or something similar. This program will scan all your inputs, and perform all your signal processing, and then write to buffered memory locations. The rest of your program looks at those buffered memory locations, and never monitors the inputs directly. You can set the input-buffering program to execute as fast as needed for your process, up to whatever the PLC can handle before it faults.
It would also be a good idea to write your signal processing functions them selves as Add On Instructions, and then call them, with whatever parameters you need.
So you could have an AOI with a call interface like this:
input-1_buffered := input_smooth (low_pass, input-1);
This would call your input_smooth function, using input-1 as the value and input-1_buffered as the final location. low_pass would be used within the input_smooth function to jump to the appropriate logic.
Then you can write your actual smoothing logic in structured text, without anyone needing to understand it, because it will only exist in that one AOI.