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

[Joeish W]

You have 
been so kind helping me with these issues, If you don't mind I would 
like to iclunde you in my contributions.lisp file with a Thank You.  Can 
you look over my suggested add on and let me know if the information is 
correct and if there is a URL I can include. I like to include URL's as 
an extra thank you. If you don't want to be included pls let me know. 
Trust me no harm done.


;;Thank you to Willem Rein Oudshoorn from CFFI-DEVEL who has made possible my inclusion of finalizers 
;;in this library. He has helped me to iron out a few bugs and has answered quite a few questions of 
;;mine. The knowledge I gained from those answers has really made this a much better library.


On , Joeish W <joeish80829 at yahoo.com> wrote:
 
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/4ad0ab6a/attachment.html>