|
From: | Juergen Sauermann |
Subject: | Re: [Bug-apl] About the reduction of clone() calls |
Date: | Mon, 28 Apr 2014 16:24:15 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 |
Hi,
generally speaking unnecessary clone() of values should of course be avoided. In GNU APL 1.0 and 1.1 there was a flag-based system of value ownership where the last owner would delete the value when giving up its interest in the value. This system began like the tmp flag, but then caused stale values on one hand and segfaults for values released too early on the other hand all over the place. I then changed to Value_P which is pretty much a shared pointer with reference counting. Initially I tried the standard shared_ptr<> class of C++ but that caused some compiler/portability issues. That change has brought a lot of stability into GNU APL, As you have noticed yourself, going through the code and changing is all over the place is bad and error-prone, and it would kind of undo the change from the flag-system to Value_P (which was also a huge effort as you may figure from SVN). So the only solution remaining is rewriting the Value (or. more likely, the Value_P) class. Now, the Value class knows how many owners it has (the share_count below already exists, it is called owner_count). But it does not know who they are. If someone does X[Y]←Z then symbol X would need to clone its current value when Value::index(Z) os performed, but Value::index(Z) does not know anything about Symbol X and other owners of the value, I will send you the 170+ GNU APL testcases so that you can quickly check if some change you make is breaking something else. Having several Values pointing to the same ravel is also a bit obscure because the Cells of the ravel need to be released (sub values and complex numbers need to be deleted) which is almost impossible if you have nested ravels or ravels of of different sizes. I also doubt that you can gain 3-4 orders of magnitude because a value is normally only cloned very few times. That does not mean that you can't prove otherwise, I can speed up +/⍳N by 6 orders of magnitude but that does not prove that this is a valuable optimization, /// Jürgen On 04/28/2014 02:57 PM, Elias Mårtenson wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |