[Mono-devel-list] plans for a native AES wrapper.
Allan Hsu
allan at counterpop.net
Thu Jul 21 15:32:11 EDT 2005
On Jul 21, 2005, at 10:04 AM, Paolo Molaro wrote:
> As explained a few days ago in another mail: internal calls have
> nothing to do with speed. They only belong inside the general
> purpouse mono if they are generally useful or in your specialized
> embedding app. So they are not appropriate as a substitute for
> pinvoking into an unmanaged lib.
>
> lupus
I think I may have misread the part of the wiki that talks about
embedding mono (http://mono-project.com/Embedding_Mono):
"The Mono runtime provides two mechanisms to expose C code to the CIL
universe: internal calls and native C code. Internal calls are
tightly integrated with the runtime, and have the least overhead, as
they use the same data types that the runtime uses.
The other option is to use the Platform Invoke (P/Invoke) to call C
code from the CIL universe, using the standard P/Invoke mechanisms."
Does that text actually list *three* options, not two? It also seems
to suggest that internal calls are faster than *something*. I had
previously thought that it was comparing native calls to p/invoke.
Was I wrong?
We've written both a p/invoke and an internal call Rijndael wrapper.
There is a negligible performance difference between the two. We may
still ship the internal call implementation for reasons unrelated to
performance; it reduces our library dependencies and makes it harder
to do something malicious via library substitution.
-Allan
--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300 1457 AC37 CBBB 0E92 C779
More information about the Mono-devel-list
mailing list