[Cffi-devel] Fw: Fw: Help perfecting my GC finalizer/constructor

[Joeish W]

I have 2 examples of how I was planning to call functions. 1 example is the function that just creates the mat. I changed the name to %mat instead of %cv-mat so it would match OpenCV's Mat class name better. The other example, add, I provide because it is an example of a function that would accept a mat as a parameter, I use add here as an example of all functions that would accept either my garbarge collected verion or my non garbage collected. 

I plan to provide both so, if you absolutely need to, you can get a speed increase. Also fnalizers seem to be twice as slow as manual memory management and 4 times slower than with-* macros, and I was advised by my tutor to include all 3 forms of MM.  All of the functions to create the %mat and %mat-expr type are written correctly for both. I was hoping you can give me a thumbs up on if the 2 examples are good, so I can go ahead and write all of my finalizers for all of my types. 


Example 1:

;; Mat::Mat()
;; Mat* cv_create_Mat()
(defcfun ("cv_create_Mat" %mat) %mat
  "MAT constructor")

;; Mat::Mat()
;; Mat* cv_create_Mat()
(defcfun ("cv_create_Mat" %%mat) (%mat :garbage-collect t))


(defun mat (&rest args)
  (cond ((eq (first args) nil) (%mat))
    ((eq :t (car args)) (%%mat))
    (t nil)))


Example 2:

;; MatExpr + operator
;; MatExpr* cv_Mat_add(Mat* m1, Mat* m2)
(defcfun ("cv_Mat_add" %add) (:pointer mat-expr)
  (m1 %mat)
  (m2 %mat))

;; MatExpr + operator
;; MatExpr* cv_Mat_add(Mat* m1, Mat* m2)
(defcfun ("cv_Mat_add" %%add) (%mat-expr :garbage-collect t)
  (m1 %mat)
  (m2 %mat))



(defun add (&rest args)
  (cond ((eq :t (last args)) (%%add (first args) (second args)))
           (t (%add (first args) (second args)))))



Btw you asked what my motivation for writing an OpenCV wrapper was and it's because of these 4 reasons:

1. The libraries that exist are wrappers for the deprecated C OpenCV interface,  mine is for the consistently updated C++ interface

2: They are incomplete, mine is 3 times bigger or more than the two that exist now , and it aims to be complete within 3 months max

3. Mine is aiming for inclusion in OpenCV proper, a generator is being built that will automatically generate all of my low-level functions/types/constants when OpenCV is built...so it will always be up to date

4: I'm helping the C wrappers for the C++ interface that this library binds to so I will be at the forefront of the knowledge needed to keep this library, supported and revolutionary as the first complete Lisp computer vision library





On Saturday, April 26, 2014 5:55 AM, Joeish W <joeish80829 at yahoo.com> wrote:
 
Some new exciting information...I ran the create-mat function a million times and my memory went up a slight bit,  I ran a million more and it went up a gain..I ran a million more and it actually leveled off. After running a million more times it actually started going down.  I was able to see the Lisp GC at work...It doesn't seem to kick in until memory becomes an issue, again sir ...it was an honor
>
>
>
>On Saturday, April 26, 2014 4:24 AM, Willem Rein Oudshoorn <woudshoo at xs4all.nl> wrote:
> 
>Joeish W <joeish80829 at yahoo.com> writes:
>>
>>
>>> (defcfun ("cv_create_Mat" create-mat) (%cv-mat :garbage-collect t))
>>>
>>> a million times to bench mark it it was actually 4 times slower than
>>> my original code....I really do need this all to be fast code, since
>>> computer vision  can benefit from the speed.  Also I noticed when I
>>> ran the (create-mat) function 1,000,000
 times my ram went up a tiny
>>> bit and didn't go down..Is that normal for finalizers.
>>
>>Well, that it is a bit slower is not really surprising because:
>>
>>1. CLOS classes are instantatied to wrap the pointer 
>>2. The trivial garbage needs to keep track of the objects
>>3. The conversion code is done by generic functions.
>>
>>However, this is solvable.  But I really would not focus on this right
>>now.  I cannot really imagine that creating the matrix is the
>>bottleneck.  
>>
>>With respect to the memory, as long as it does not grow indefinitely I
>>would not worry about it.  The trivial garbage package might introduce
>>some memory overhead which is not directly reclaimed by the garbage
>>collector.  
>>
>>
>>> When I use
>>> with-* macros or manual MM I don't get an increase in ram on my
>>> system.  I would like to include finalizers in my library but is there
>>> any way to
 overcome these obstacles to make that happen...Again the
>>> time you took to help me on this is much appreciated. :)You really
>>> helped me to understand.
>>
>>Using `with-*` macros is a good idea.  Inside these macros you can
>>do the manual garbage collection and avoid maybe the generic type
>>conversion.    But to make it robust the `with-*` macros will not (I
>>expect) be faster than the code you have now.  
>>
>>Making the code fast is certainly doable and not hard, but you should
>>first make it work and figure what needs to be fast and which
>>conveniences you are willing to give up for the speed improvement.
>>
>>Wim Oudshoorn
>>
>>
>>_______________________________________________
>>Cffi-devel mailing list
>>Cffi-devel at common-lisp.net
>>http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140426/88417cbe/attachment.html>