Matlab parfor saves and loads temporary variables during execution!
Show older comments
The parallel pool implementation appears to save and load variables using effectively the normal "save" and "load" channels when making copies to be passed to the workers. This is really bad because if someone has a saveobj() implemented in a class object the state of the variable could be modified during execution and depending on the circumstances could lead to "unexplained" crashes.
Lets say I have a class object that needs a large amount of temporary data during execution. When saved I would naturally want to get rid of this temporary data. A convenient way to do this is to write a saveobj that clears the temporary data within the class. If, however, the object is saved and reloaded during execution as with parfor, there are problems.
Why is the copy not made internally?
1 Comment
Accepted Answer
I don't know why authoritatively, but it seems to me that this is only a danger if you are unaware of this behavior on the part of parfor. If you are aware of it, you would surely write a loadobj() method to restore the temporary data when reloaded. And, this would be better than broadcasting copies of the temporary data to all the workers. The latter is done serially and would take a lot more time.
Incidentally, have you verified that saveobj() is triggered in this scenario just as in an ordinary call to save()?
7 Comments
I wonder if you should really be using a more specialized save_gutted() class method instead of using the regular save(). It isn't a natural design to overload saveobj() in such a way as to make the object's essential state unrecoverable. That is almost the opposite of "saving".
In any case also, you do not want to be constructing large temporary data on the host, because of the communication overhead that I mentioned. You want to use parallel.pool.Constant(FH) to have it constructed on the workers.
suppose that the state of an object needs to be recomputed when loading. I wouldn't consider that unnatural
No, let's be clear. You've been saying that your object can't be recomputed upon load - that gutting the object makes its state unrecoverable by loadobj. That is what Edric and I have been saying is unnatural.
Even then, however, we are only saying that it is unnatural for the save() command to do this, not other variations of save() that you might write. When you overload builtin methods that other users or other MATLAB mechanisms might call (e.g., the parallel pool), it is best not to stray too far from the purpose of the original method, and the purpose of save() is to store the object in a fully recoverable form. The same goes for things like numel() or isa(). The documentation advises you not to overload those at all.
If you are now saying that loadobj could restore your object, but that it is simply time-consuming, and you don't always want to do it, that is fine. I'm just not sure, when using the parallel pool, whether rebuilding the object would hurt you more than broadcasting the large data from the client to all the workers.
Using a save gutted means that any function that saves this object would have to know about save_gutted(), so I would prefer to use a flag as described in my post.
But in your current code, any function that saves this object has to know about save(). Why you prefer one name or another for the function that sends your code to disk is not obvious.
I don't think throwing away temporary information is straying too far from the original purpose of the save() method, as long as it is documented in the class.
Except that you want your class to work with parallel pools. Parallel pools, and maybe various other things in Matlab, expect load() to be the 1-to-1 inverse of save(). The burden is on you to meet those interface requirements. They will not conform to your class documentation.
In some types of class design, save() throws away state information and it can't be recovered. Actually that type of design is forced by the Matlab ClassificationXXX classes and if one wants to wrap them there is no alternative to throwing away unrecoverable state information from the class object.
Well, no, the alternative is to not call compact() in your saveobj method and to endure the additional consumption of disk space that this will bring about. Then you will have no conflict with parallel pool or other Matlab toolboxes.
I can appreciate, however, that storing multiple copies of the same data to disk is unappealing. But there are still options if you want to avoid that, and which don't involve breaking the 1-1 correspondence of save/load. One way is to store objects sharing common data together in arrays. Then your saveobj/loadobj pair can do things like this,
classdef myclass
methods
function s=saveobj(objArray)
s.shareddata=objArray(1).data;
[objArray.data]=deal([]);
s.objArray=objArray;
end
end
methods (Static)
function objArray=loadobj(s)
objArray=s.objArray;
[objArray.data]=deal(s.shareddata);
end
end
end
Unfortunately, it doesn't look like ClassificationXXX classes let you do this, but that might be what ClassificationEnsemble classes are intended for.
SK
on 29 Jul 2018
More Answers (1)
Edric Ellis
on 23 Jul 2018
2 votes
The workers executing the body of any parfor loop are separate MATLAB processes, so the only reliable way that variables existing on the client can be sent to those workers is by doing something equivalent to calling save on the client, and then load on the workers. (The same procedure is used, but no files are created on disk).
I must admit, it's not clear to me what the benefit is of writing a saveobj that cannot be reversed by a loadobj. (Also, have you considered using Transient fields in your class?)
1 Comment
Categories
Find more on Whos in Help Center and File Exchange
