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 <joeish80...@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
><wouds...@xs4all.nl> wrote:
>
>Joeish W <joeish80...@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@common-lisp.net
>>http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>>
>>
>>
>
>_______________________________________________
Cffi-devel mailing list
Cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
