Hello,
I have the problem, that my FFI routines are allocating lots of
memory. My suspection is that it is related to the notes SBCL gives
during compilation:
| unable to
| optimize
| because:
| could not optimize away %SAP-ALIEN: forced to do runtime
| allocation of alien-value structure
A code snippet which produces this, is the following (using UFFI):
(def-function "RSA_generate_key"
((num :int)
(e :unsigned-long)
(cb :pointer-void)
(cb-arg :pointer-void))
:returning rsa)
rsa is declared as :pointer-void.
Is there anything I can do to optimize this function?
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
On Sat, 27 Mar 2004 16:39:43 +0100, Julian Stecklina <··········@web.de> wrote:
> I have the problem, that my [SBCL] FFI routines are allocating lots
> of memory.
>
> [snip]
>
> Is there anything I can do to optimize this function?
See this thread:
<http://groups.google.com/groups?threadm=dvv5c.18787%241p.341330%40attbi_s54>
Edi.
Edi Weitz wrote:
> On Sat, 27 Mar 2004 16:39:43 +0100, Julian Stecklina <··········@web.de>
> wrote:
>
>> I have the problem, that my [SBCL] FFI routines are allocating lots
>> of memory.
>>
>> [snip]
>>
>> Is there anything I can do to optimize this function?
>
> See this thread:
>
>
<http://groups.google.com/groups?threadm=dvv5c.18787%241p.341330%40attbi_s54>
>
> Edi.
I was the OP in that other thread. Kevin Rosenberg finally helped me out
with this posting:
·····························································@attbi_s54
The summary is, I don't think the problem is with the declaration (at least
I have never found a way to silence SBCL's complaints with my UFFI
definitions). It seems like the big problem is making sure you DECLARE the
data type in the functions where you access the alien object. I have no
idea why SBCL has this behavior, though. My knowledge level isn't yet
sufficient to determine whether this must be so intrinsically, or whether a
simple addition to SBCL would make the behavior a lot better. The scary
thing is that the default behavior is so poor.
On the bright side, I got an accelerated course on Lisp type declarations...
;-)
-- Dave
--
Dave Roberts
·············@re-move.droberts.com
Dave Roberts <·············@re-move.droberts.com> writes:
> The summary is, I don't think the problem is with the declaration (at least
> I have never found a way to silence SBCL's complaints with my UFFI
> definitions). It seems like the big problem is making sure you DECLARE the
> data type in the functions where you access the alien object. I have no
> idea why SBCL has this behavior, though. My knowledge level isn't yet
> sufficient to determine whether this must be so intrinsically, or whether a
> simple addition to SBCL would make the behavior a lot better. The scary
> thing is that the default behavior is so poor.
"So poor" does not even describe it. :) I discovered this behaviour
this morning. I improved my code from taking about 30s and consing
70MB to taking 0.1s and zero consing, just by adding declarations at
all places where I access foreign arrays.
A nice thing would be a note saying something like:
Oh my god... you used deref and did not declare the type of its
argument. This *will* result in *massive* consing and a *major*
performance hit.
Regards,
--
Julian Stecklina
Signed and encrypted mail welcome.
Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5
FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5
Any sufficiently complicated C or Fortran program
contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
- Greenspun's Tenth Rule of Programming
Julian Stecklina wrote:
> "So poor" does not even describe it. :) I discovered this behaviour
> this morning. I improved my code from taking about 30s and consing
> 70MB to taking 0.1s and zero consing, just by adding declarations at
> all places where I access foreign arrays.
Exactly. The same thing happened with me. Amazing.
> A nice thing would be a note saying something like:
>
> Oh my god... you used deref and did not declare the type of its
> argument. This *will* result in *massive* consing and a *major*
> performance hit.
Agreed! In a private note to Kevin, we were discussing it and I said that I
couldn't imagine writing a program without those declarations!
--
Dave Roberts
·············@re-move.droberts.com
Hello,
Julian Stecklina <··········@web.de> writes:
> I have the problem, that my FFI routines are allocating lots of
> memory. My suspection is that it is related to the notes SBCL gives
> during compilation:
>
> | unable to
> | optimize
> | because:
> | could not optimize away %SAP-ALIEN: forced to do runtime
> | allocation of alien-value structure
>
> A code snippet which produces this, is the following (using UFFI):
>
> (def-function "RSA_generate_key"
> ((num :int)
> (e :unsigned-long)
> (cb :pointer-void)
> (cb-arg :pointer-void))
> :returning rsa)
>
> rsa is declared as :pointer-void.
>
> Is there anything I can do to optimize this function?
SBCL needs to make an alien object from a pointer in order to return
it from a global function or to pass it as an argument to a global
function. You can try to declare some functions INLINE in order to
make the whole lifetime of an alien visible to the compiler at
once. Or write a wrapper around RSA-GENERATE-KEY, translating the
result to SAP (with SB-ALIEN:ALIEN-SAP), which is cheaper [and
inline-expand the foreign RSA-GENERATE-KEY into the wrapper].
--
Regards,
Alexey Dejneka