Thanks for your replies to my question, I was planning to go the trivial-garbage route and someone from CFFI-DEVEL kindly gave me this code to do GC automatically using my mat and del-mat functions
(defstruct (cvmatrix (:constructor %make-cvmatrix)) (sap (mat) :type sb-sys:system-area-pointer :read-only t))
(defun make-cvmatrix () (let* ((matrix (%make-cvmatrix)) (sap (cvmatrix-sap matrix))) (tg:finalize matrix (lambda (x) (del-mat sap))) matrix))
When I run the make-cvmatrix function to create a matrix it outputs a struct instead of a pointer like i needed. I changed the last line of the make-cvmatrix function to be "sap" as below:
(tg:finalize matrix (lambda (x) (del-mat sap))) sap))
...and it appears to run poorly with only major variations in my ram levels which i suppose is just a result of lisps GC in process. Since I'm new to GC w/ trivial-garbage, I was hoping someone can verify first that the change to sap was an ok move.
I was hoping someone could edit my code so I have a good example of Lisp GC with TG to work from and if I write a defcfun for this C wrapper :
Mat* cv_create_Mat_typed(int rows, int cols, int type) { return new Mat(rows, cols, type); }
eg:
(defcfun ("cv_create_Mat_typed" mat-typed) (:pointer mat) "MAT constructor with a row, column and type parameter." (rows :int) (cols :int) (type :int))
show me where the rows cols type params get placed in an edited finalizer/constructor above..I would definately appreciate greatly:), concrete examples using the code I posted.
Joeish W joeish80829@yahoo.com writes:
Thanks for your replies to my question, I was planning to go the trivial-garbage route and someone from CFFI-DEVEL kindly gave me this code to do GC automatically using my mat and del-mat functions
(defstruct (cvmatrix (:constructor %make-cvmatrix)) (sap (mat) :type sb-sys:system-area-pointer :read-only t))
(defun make-cvmatrix () (let* ((matrix (%make-cvmatrix)) (sap (cvmatrix-sap matrix))) (tg:finalize matrix (lambda (x) (del-mat sap))) matrix))
When I run the make-cvmatrix function to create a matrix it outputs a struct instead of a pointer like i needed. ...
You really do not want to return a pointer. For (at least) two reasons:
1 - It will make it much harder to use the functions in lisp because you do need to remember what they point to.
2 - It prevents automatic garbage collection of the underlying C objects.
However, if you really want to use direct C-pointers, the code is not ok, see below:
... I changed the last line of the make-cvmatrix function to be "sap" as below:
(tg:finalize matrix (lambda (x) (del-mat sap))) sap))
...and it appears to run poorly with only major variations in my ram levels which i suppose is just a result of lisps GC in process. Since I'm new to GC w/ trivial-garbage, I was hoping someone can verify first that the change to sap was an ok move.
No this change is NOT ok. Remember the tg:finalize will make sure that the code
(del-mat sap)
is called when 'matrix' is garbage collector.
In the first version, the function returned matrix and as long as matrix is alive, the del-mat is not callled.
In the second version, you do not return 'matrix' and as soon as the sap is returned, the 'matrix' is eligible for garbage collection and therefore you will get random crashes because the '(del-mat sap)' will be called while you are still using the returned SAP.
NOTE: The original code is WRONG, the lambda in 'tg:finalize' should NOT take any arguments so the original line should read
(tg:finalize matrix (lambda () (del-mat-sap)))
I was hoping someone could edit my code so I have a good example of Lisp GC with TG to work from and if I write a defcfun for this C wrapper :
Ok, here is some code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Tell CFFI of the existence of the 'Mat' C-type. ;;; ;;; This can be used as: ;;; ;;; - %cv-mat -- Which will not enable garbage collection of the C-mat. ;;; - (%cv-mat :garbage-collect t) -- Which will enable garbage collection.
(define-foreign-type cv-mat () ((garbage-collect :reader garbage-collect :initform nil :initarg :garbage-collect)) (:actual-type :pointer) (:simple-parser %cv-mat))
;;; Define the Lisp object corresponding to the 'Mat' C-Type
(defclass cv-matrix () ((c-pointer :reader c-pointer :initarg :c-pointer)))
;;; Translation between C pointers to the lisp cv-matrix
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
(defmethod translate-from-foreign (c-pointer (c-type cv-mat)) (let ((matrix (make-instance 'cv-matrix :c-pointer c-pointer))) (when (garbage-collect c-type) (tg:finalize matrix (lambda () (del-mat c-pointer)))) matrix))
;;; C functions
(defcfun ("cv_delete_Mat" del-mat) :void (ptr %cv-mat))
(defcfun ("cv_create_Mat" create-mat) (%cv-mat :garbage-collect t))
(defcfun ("cv_create_Mat_typed" create-mat-typed) (%cv-mat :garbage-collect t) (rows :int) (cols :int) (type :int)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defcfun ("cv_create_Mat_typed" mat-typed) (:pointer mat) "MAT constructor with a row, column and type parameter." (rows :int) (cols :int) (type :int))
show me where the rows cols type params get placed in an edited finalizer/constructor above..I would definately appreciate greatly:), concrete examples using the code I posted.
I do no understand what you mean here.
Wim Oudshoorn
I very much appreciate all the time you took to help me with this...It is an awesome system..and I learned alot. Quick ?...I noticed when I ran this:
(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. 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.
On Sunday, April 20, 2014 8:14 AM, Willem Rein Oudshoorn woudshoo@xs4all.nl wrote:
Joeish W joeish80829@yahoo.com writes:
Thanks for your replies to my question, I was planning to go the trivial-garbage route and someone from CFFI-DEVEL kindly gave me this code to do GC automatically using my mat and del-mat functions
(defstruct (cvmatrix (:constructor %make-cvmatrix)) (sap (mat) :type sb-sys:system-area-pointer :read-only t))
(defun make-cvmatrix () (let* ((matrix (%make-cvmatrix)) (sap (cvmatrix-sap matrix))) (tg:finalize matrix (lambda (x) (del-mat sap))) matrix))
When I run the make-cvmatrix function to create a matrix it outputs a struct instead of a pointer like i needed. ...
You really do not want to return a pointer. For (at least) two reasons:
1 - It will make it much harder to use the functions in lisp because you do need to remember what they point to.
2 - It prevents automatic garbage collection of the underlying C objects.
However, if you really want to use direct C-pointers, the code is not ok, see below:
... I changed the last line of the make-cvmatrix function to be "sap" as below:
(tg:finalize matrix (lambda (x) (del-mat sap))) sap))
...and it appears to run poorly with only major variations in my ram levels which i suppose is just a result of lisps GC in process. Since I'm new to GC w/ trivial-garbage, I was hoping someone can verify first that the change to sap was an ok move.
No this change is NOT ok. Remember the tg:finalize will make sure that the code
(del-mat sap)
is called when 'matrix' is garbage collector.
In the first version, the function returned matrix and as long as matrix is alive, the del-mat is not callled.
In the second version, you do not return 'matrix' and as soon as the sap is returned, the 'matrix' is eligible for garbage collection and therefore you will get random crashes because the '(del-mat sap)' will be called while you are still using the returned SAP.
NOTE: The original code is WRONG, the lambda in 'tg:finalize' should NOT take any arguments so the original line should read
(tg:finalize matrix (lambda () (del-mat-sap)))
I was hoping someone could edit my code so I have a good example of Lisp GC with TG to work from and if I write a defcfun for this C wrapper :
Ok, here is some code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Tell CFFI of the existence of the 'Mat' C-type. ;;; ;;; This can be used as: ;;; ;;; - %cv-mat -- Which will not enable garbage collection of the C-mat. ;;; - (%cv-mat :garbage-collect t) -- Which will enable garbage collection.
(define-foreign-type cv-mat () ((garbage-collect :reader garbage-collect :initform nil :initarg :garbage-collect)) (:actual-type :pointer) (:simple-parser %cv-mat))
;;; Define the Lisp object corresponding to the 'Mat' C-Type
(defclass cv-matrix () ((c-pointer :reader c-pointer :initarg :c-pointer)))
;;; Translation between C pointers to the lisp cv-matrix
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
(defmethod translate-from-foreign (c-pointer (c-type cv-mat)) (let ((matrix (make-instance 'cv-matrix :c-pointer c-pointer))) (when (garbage-collect c-type) (tg:finalize matrix (lambda () (del-mat c-pointer)))) matrix))
;;; C functions
(defcfun ("cv_delete_Mat" del-mat) :void (ptr %cv-mat))
(defcfun ("cv_create_Mat" create-mat) (%cv-mat :garbage-collect t))
(defcfun ("cv_create_Mat_typed" create-mat-typed) (%cv-mat :garbage-collect t) (rows :int) (cols :int) (type :int)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defcfun ("cv_create_Mat_typed" mat-typed) (:pointer mat) "MAT constructor with a row, column and type parameter." (rows :int) (cols :int) (type :int))
show me where the rows cols type params get placed in an edited finalizer/constructor above..I would definately appreciate greatly:), concrete examples using the code I posted.
I do no understand what you mean here.
Wim Oudshoorn
Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Joeish W joeish80829@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
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@xs4all.nl wrote:
Joeish W joeish80829@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:
- CLOS classes are instantatied to wrap the pointer
- The trivial garbage needs to keep track of the objects
- 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
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@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@xs4all.nl wrote:
Joeish W joeish80829@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:
- CLOS classes are instantatied to wrap the pointer
- The trivial garbage needs to keep track of the objects
- 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
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@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:
- 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
- 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@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@xs4all.nl wrote:
Joeish W joeish80829@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:
- CLOS classes are instantatied to wrap the pointer
- The trivial garbage needs to keep track of the objects
- 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
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
My example includes this function, the types are written exactly how you taught me
;; Point_() <--C++ ;; Point2##t * cv_create_Point2##t ( tn x, tn y) <--C (defcfun ("cv_create_Point2i" point0) point "Point constructor")
The output of (point0) is from my best research a metaobject, how do I mem-aref it.
LCV> (point0) #<CV-POINT {1006CDD5B3}>
On Saturday, April 26, 2014 9:38 PM, Joeish W joeish80829@yahoo.com wrote:
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@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:
- 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
- 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@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@xs4all.nl wrote:
Joeish W joeish80829@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:
- CLOS classes are instantatied to wrap the pointer
- The trivial garbage needs to keep track of the objects
- 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
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
When time frees up I might look at your other questions.
Wim Oudshoorn
P.S.: The thank you text looks fine to me. No need to include an URL.
On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
__Martin
Martin Simmons martin@lispworks.com writes:
On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
Kind regards, Wim Oudshoorn.
I noticed a parentheses was missing is this right
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value))
On Monday, April 28, 2014 10:20 PM, Willem Rein Oudshoorn woudshoo@xs4all.nl wrote:
Martin Simmons martin@lispworks.com writes:
> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
Kind regards, Wim Oudshoorn.
Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
I noticed a parentheses was missing is this right
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value))
On Monday, April 28, 2014 10:20 PM, Willem Rein Oudshoorn woudshoo@xs4all.nl wrote:
Martin Simmons martin@lispworks.com writes:
> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
Kind regards, Wim Oudshoorn.
Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
On Tue, 29 Apr 2014 07:20:08 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:p0/p2S+buMdADzjMLfHl6LN5m6k=
Martin Simmons martin@lispworks.com writes:
> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
IMHO, it needs to come with a huge security warning, otherwise there will be endless use-after-free bugs when users lose the wrapper object after storing the pointer somewhere.
__Martin
I just understood what you meant by this:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
Ok, so great!...I can now mem-aref without adding the c-pointer..so thank you very much for that, but is there a way I can do the same type of thing to let me foreign-alloc it without adding c-pointer.
On Wednesday, April 30, 2014 9:15 AM, Martin Simmons martin@lispworks.com wrote:
On Tue, 29 Apr 2014 07:20:08 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:p0/p2S+buMdADzjMLfHl6LN5m6k=
Martin Simmons martin@lispworks.com writes:
>> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
IMHO, it needs to come with a huge security warning, otherwise there will be endless use-after-free bugs when users lose the wrapper object after storing the pointer somewhere.
__Martin
Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
I just understood what you meant by this:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
Ok, so great!...I can now mem-aref without adding the c-pointer..so thank you very much for that, but is there a way I can do the same type of thing to let me foreign-alloc it without adding c-pointer.
On Wednesday, April 30, 2014 9:15 AM, Martin Simmons martin@lispworks.com wrote:
On Tue, 29 Apr 2014 07:20:08 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:p0/p2S+buMdADzjMLfHl6LN5m6k=
Martin Simmons martin@lispworks.com writes:
>> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
Joeish W joeish80829@yahoo.com writes:
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
Sorry for the short answer, but at the moment I am extremely busy. If you followed the example
(mem-aref (c-pointer YOUR-POINT) ...)
should work.
It might be interesting (or scary depending on your point of view) to consider what happens if the variable YOUR-POINT is the last reference to the CLOS object here...the finalizer might free the foreign object before mem-aref is entered if the compiler no longer keeps a pointer to the variable.
No this is not safe. In general you should never do `(c-pointer ...)` outside the low level parts of the bindings, and use it very carefully.
Personally I would try to never use the `c-pointer` method outside the `translate-to-foreign` code. And I naively expected that this would be safe. But as you point out:
Or more specifically, can this ever be safe?
(mem-aref (c-pointer (point0)) ...)
This is never safe.
I think the easiest fix is to change the
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (c-pointer lisp-value))
code to [UNTESTED CODE]:
(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat)) (values (c-pointer lisp-value) lisp-value)
This should keep the lisp-value around until we are done using the `(c-pointer ...)` value. Provided of course you are not mucking around with the `c-pointer` method yourself.
In general, I would advocate to hide all the nasty c-pointer business in the translate methods and never deal with it outside that limited scope.
Thank you for bringing this to my attention. I do think we need a paper or section in the manual on how to deal with combing GC in Lisp and manual memory management on the C side.
When my time frees up (hopefully in a month or two) I might take a stab at a first draft.
IMHO, it needs to come with a huge security warning, otherwise there will be endless use-after-free bugs when users lose the wrapper object after storing the pointer somewhere.
__Martin
Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
How do I work with the metaobjects(is that what they are called) output by the code you gave me...If you can show me how to mem-aref one I would really appreciate it
My example includes this function, the types are written exactly how you taught me
;; Point_() <--C++ ;; Point2##t * cv_create_Point2##t ( tn x, tn y) <--C (defcfun ("cv_create_Point2i" point0) point "Point constructor")
The output of (point0) is from my best research a metaobject, how do I mem-aref it.
LCV> (point0) #<CV-POINT {1006CDD5B3}>
On Saturday, April 26, 2014 9:38 PM, Joeish W joeish80829@yahoo.com wrote:
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@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:
- 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
- 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@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@xs4all.nl wrote:
Joeish W joeish80829@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:
- CLOS classes are instantatied to wrap the pointer
- The trivial garbage needs to keep track of the objects
- 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
-
Joeish W -
Martin Simmons -
Willem Rein Oudshoorn