Today, Andreas Fuchs <asf@...> wrote:
> Today, Carlos Ungil <ungil@...> wrote:
>> Dear SBCL developers,
>>
>> there is a change in the latest (0.8.11) release that makes
>> sb-posix terribly slow.
[...]
> Perhaps I can cut a compromise between these two extremes (fast but
> icky interface, slow but lispy interface) by sticking a finalizer on
> a lisp object with a pointer to the alien.
This seems to work, and it is reasonably fast:
0.025 seconds of real time
0.005963 seconds of user run time
0.008231 seconds of system run time
0 page faults and
200,552 bytes consed.
significantly better than the 20 second timing that I posted about
before. Also, I don't feel ashamed of the code in interface.lisp any
more, so that's a bonus. Please try this patch and tell me if the
timings improved:

Today, Carlos Ungil <ungil@...> wrote:
> Dear SBCL developers,
>
> there is a change in the latest (0.8.11) release that makes sb-posix
> terribly slow.
Indeed. The change to make sb-grovel use alien structures caused that.
The *STAT functions handle alien structures now (which need to be
manually managed), and we decided to not change the interface, so it
now creates an object in lisp space and copies the alien stat's
elements there.
I just tried the code you posted below, and by using the alien
structure (for stat) directly, I could reduce run time for (tree
"contrib/") to 0.044 seconds (from 20 seconds, on this machine). That
might not be as fast as with the old code (haven't measured yet), but
it might be satisfying. OTOH, it forces you to manually manage the
objects that the stat call returns, which is pretty suboptimal.
Perhaps I can cut a compromise between these two extremes (fast but
icky interface, slow but lispy interface) by sticking a finalizer on a
lisp object with a pointer to the alien.
I'll keep you informed. Thanks for the report,
--
Andreas Fuchs, <asf@...>, asf@..., antifuchs

Today, Andreas Fuchs <asf@...> wrote:
> Today, Carlos Ungil <ungil@...> wrote:
>> Dear SBCL developers,
>>
>> there is a change in the latest (0.8.11) release that makes
>> sb-posix terribly slow.
[...]
> Perhaps I can cut a compromise between these two extremes (fast but
> icky interface, slow but lispy interface) by sticking a finalizer on
> a lisp object with a pointer to the alien.
This seems to work, and it is reasonably fast:
0.025 seconds of real time
0.005963 seconds of user run time
0.008231 seconds of system run time
0 page faults and
200,552 bytes consed.
significantly better than the 20 second timing that I posted about
before. Also, I don't feel ashamed of the code in interface.lisp any
more, so that's a bonus. Please try this patch and tell me if the
timings improved:

Andreas Fuchs <asf@...> writes:
> +;;; XXX: We are automatically freeing foreign memory. This breaks if
> +;;; there are pointers to the alien object held by C code.
> +;;;
> +;;; XXX: We must never create two objects that point to the same
> +;;; alien. When we do, and one loses all references, the alien
> +;;; will be FREEd.
XXX: (as Dan Barlow pointed out when I suggested this implementation
to him one time) We must ensure that we cons enough in Lisp code
that we do enough GCs to free up foreign memory: if calls to
stat() are in otherwise consing-free code, the foreign memory
will never be freed.
What happens if you provide an automatically-generated specialized
converter from alien to class (or indeed struct, if the CLOS
fully-generalized class indirection is costing too much)? I'd guess
that the excessive consing comes from generic alien code rather than
from constructing one lisp-land object, no matter how many layers of
indirection it has.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)

Andreas Fuchs wrote:
> This seems to work, and it is reasonably fast:
>
> 0.025 seconds of real time
> 0.005963 seconds of user run time
> 0.008231 seconds of system run time
> 0 page faults and
> 200,552 bytes consed.
>
> significantly better than the 20 second timing that I posted about
> before. Also, I don't feel ashamed of the code in interface.lisp any
> more, so that's a bonus. Please try this patch and tell me if the
> timings improved:
Thanks a lot for the patch. It works, and while it's a bit slower than
in 0.8.10 this is not a problem, at least not for me (it's slower by
less than a factor of two).
Regards,
Carlos
>