ext_ffi.html 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
  2. <html>
  3. <head>
  4. <title>FFI Library</title>
  5. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  6. <meta name="Author" content="Mike Pall">
  7. <meta name="Copyright" content="Copyright (C) 2005-2012, Mike Pall">
  8. <meta name="Language" content="en">
  9. <link rel="stylesheet" type="text/css" href="bluequad.css" media="screen">
  10. <link rel="stylesheet" type="text/css" href="bluequad-print.css" media="print">
  11. </head>
  12. <body>
  13. <div id="site">
  14. <a href="http://luajit.org"><span>Lua<span id="logo">JIT</span></span></a>
  15. </div>
  16. <div id="head">
  17. <h1>FFI Library</h1>
  18. </div>
  19. <div id="nav">
  20. <ul><li>
  21. <a href="luajit.html">LuaJIT</a>
  22. <ul><li>
  23. <a href="http://luajit.org/download.html">Download <span class="ext">&raquo;</span></a>
  24. </li><li>
  25. <a href="install.html">Installation</a>
  26. </li><li>
  27. <a href="running.html">Running</a>
  28. </li></ul>
  29. </li><li>
  30. <a href="extensions.html">Extensions</a>
  31. <ul><li>
  32. <a class="current" href="ext_ffi.html">FFI Library</a>
  33. <ul><li>
  34. <a href="ext_ffi_tutorial.html">FFI Tutorial</a>
  35. </li><li>
  36. <a href="ext_ffi_api.html">ffi.* API</a>
  37. </li><li>
  38. <a href="ext_ffi_semantics.html">FFI Semantics</a>
  39. </li></ul>
  40. </li><li>
  41. <a href="ext_jit.html">jit.* Library</a>
  42. </li><li>
  43. <a href="ext_c_api.html">Lua/C API</a>
  44. </li></ul>
  45. </li><li>
  46. <a href="status.html">Status</a>
  47. <ul><li>
  48. <a href="changes.html">Changes</a>
  49. </li></ul>
  50. </li><li>
  51. <a href="faq.html">FAQ</a>
  52. </li><li>
  53. <a href="http://luajit.org/performance.html">Performance <span class="ext">&raquo;</span></a>
  54. </li><li>
  55. <a href="http://wiki.luajit.org/">Wiki <span class="ext">&raquo;</span></a>
  56. </li><li>
  57. <a href="http://luajit.org/list.html">Mailing List <span class="ext">&raquo;</span></a>
  58. </li></ul>
  59. </div>
  60. <div id="main">
  61. <p>
  62. The FFI library allows <b>calling external C&nbsp;functions</b> and
  63. <b>using C&nbsp;data structures</b> from pure Lua code.
  64. </p>
  65. <p>
  66. The FFI library largely obviates the need to write tedious manual
  67. Lua/C bindings in C. No need to learn a separate binding language
  68. &mdash; <b>it parses plain C&nbsp;declarations!</b> These can be
  69. cut-n-pasted from C&nbsp;header files or reference manuals. It's up to
  70. the task of binding large libraries without the need for dealing with
  71. fragile binding generators.
  72. </p>
  73. <p>
  74. The FFI library is tightly integrated into LuaJIT (it's not available
  75. as a separate module). The code generated by the JIT-compiler for
  76. accesses to C&nbsp;data structures from Lua code is on par with the
  77. code a C&nbsp;compiler would generate. Calls to C&nbsp;functions can
  78. be inlined in JIT-compiled code, unlike calls to functions bound via
  79. the classic Lua/C API.
  80. </p>
  81. <p>
  82. This page gives a short introduction to the usage of the FFI library.
  83. <em>Please use the FFI sub-topics in the navigation bar to learn more.</em>
  84. </p>
  85. <h2 id="call">Motivating Example: Calling External C Functions</h2>
  86. <p>
  87. It's really easy to call an external C&nbsp;library function:
  88. </p>
  89. <pre class="code mark">
  90. <span class="codemark">&#9312;
  91. &#9313;
  92. &#9314;</span>local ffi = require("ffi")
  93. ffi.cdef[[
  94. <span style="color:#00a000;">int printf(const char *fmt, ...);</span>
  95. ]]
  96. ffi.C.printf("Hello %s!", "world")
  97. </pre>
  98. <p>
  99. So, let's pick that apart:
  100. </p>
  101. <p>
  102. <span class="mark">&#9312;</span> Load the FFI library.
  103. </p>
  104. <p>
  105. <span class="mark">&#9313;</span> Add a C&nbsp;declaration
  106. for the function. The part inside the double-brackets (in green) is
  107. just standard C&nbsp;syntax.
  108. </p>
  109. <p>
  110. <span class="mark">&#9314;</span> Call the named
  111. C&nbsp;function &mdash; Yes, it's that simple!
  112. </p>
  113. <p style="font-size: 8pt;">
  114. Actually, what goes on behind the scenes is far from simple: <span
  115. style="color:#4040c0;">&#9314;</span> makes use of the standard
  116. C&nbsp;library namespace <tt>ffi.C</tt>. Indexing this namespace with
  117. a symbol name (<tt>"printf"</tt>) automatically binds it to the
  118. standard C&nbsp;library. The result is a special kind of object which,
  119. when called, runs the <tt>printf</tt> function. The arguments passed
  120. to this function are automatically converted from Lua objects to the
  121. corresponding C&nbsp;types.
  122. </p>
  123. <p>
  124. Ok, so maybe the use of <tt>printf()</tt> wasn't such a spectacular
  125. example. You could have done that with <tt>io.write()</tt> and
  126. <tt>string.format()</tt>, too. But you get the idea ...
  127. </p>
  128. <p>
  129. So here's something to pop up a message box on Windows:
  130. </p>
  131. <pre class="code">
  132. local ffi = require("ffi")
  133. ffi.cdef[[
  134. <span style="color:#00a000;">int MessageBoxA(void *w, const char *txt, const char *cap, int type);</span>
  135. ]]
  136. ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0)
  137. </pre>
  138. <p>
  139. Bing! Again, that was far too easy, no?
  140. </p>
  141. <p style="font-size: 8pt;">
  142. Compare this with the effort required to bind that function using the
  143. classic Lua/C API: create an extra C&nbsp;file, add a C&nbsp;function
  144. that retrieves and checks the argument types passed from Lua and calls
  145. the actual C&nbsp;function, add a list of module functions and their
  146. names, add a <tt>luaopen_*</tt> function and register all module
  147. functions, compile and link it into a shared library (DLL), move it to
  148. the proper path, add Lua code that loads the module aaaand ... finally
  149. call the binding function. Phew!
  150. </p>
  151. <h2 id="cdata">Motivating Example: Using C Data Structures</h2>
  152. <p>
  153. The FFI library allows you to create and access C&nbsp;data
  154. structures. Of course the main use for this is for interfacing with
  155. C&nbsp;functions. But they can be used stand-alone, too.
  156. </p>
  157. <p>
  158. Lua is built upon high-level data types. They are flexible, extensible
  159. and dynamic. That's why we all love Lua so much. Alas, this can be
  160. inefficient for certain tasks, where you'd really want a low-level
  161. data type. E.g. a large array of a fixed structure needs to be
  162. implemented with a big table holding lots of tiny tables. This imposes
  163. both a substantial memory overhead as well as a performance overhead.
  164. </p>
  165. <p>
  166. Here's a sketch of a library that operates on color images plus a
  167. simple benchmark. First, the plain Lua version:
  168. </p>
  169. <pre class="code">
  170. local floor = math.floor
  171. local function image_ramp_green(n)
  172. local img = {}
  173. local f = 255/(n-1)
  174. for i=1,n do
  175. img[i] = { red = 0, green = floor((i-1)*f), blue = 0, alpha = 255 }
  176. end
  177. return img
  178. end
  179. local function image_to_grey(img, n)
  180. for i=1,n do
  181. local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue)
  182. img[i].red = y; img[i].green = y; img[i].blue = y
  183. end
  184. end
  185. local N = 400*400
  186. local img = image_ramp_green(N)
  187. for i=1,1000 do
  188. image_to_grey(img, N)
  189. end
  190. </pre>
  191. <p>
  192. This creates a table with 160.000 pixels, each of which is a table
  193. holding four number values in the range of 0-255. First an image with
  194. a green ramp is created (1D for simplicity), then the image is
  195. converted to greyscale 1000 times. Yes, that's silly, but I was in
  196. need of a simple example ...
  197. </p>
  198. <p>
  199. And here's the FFI version. The modified parts have been marked in
  200. bold:
  201. </p>
  202. <pre class="code mark">
  203. <span class="codemark">&#9312;
  204. &#9313;
  205. &#9314;
  206. &#9315;
  207. &#9314;
  208. &#9316;</span><b>local ffi = require("ffi")
  209. ffi.cdef[[
  210. </b><span style="color:#00a000;">typedef struct { uint8_t red, green, blue, alpha; } rgba_pixel;</span><b>
  211. ]]</b>
  212. local function image_ramp_green(n)
  213. <b>local img = ffi.new("rgba_pixel[?]", n)</b>
  214. local f = 255/(n-1)
  215. for i=<b>0,n-1</b> do
  216. <b>img[i].green = i*f</b>
  217. <b>img[i].alpha = 255</b>
  218. end
  219. return img
  220. end
  221. local function image_to_grey(img, n)
  222. for i=<b>0,n-1</b> do
  223. local y = <b>0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue</b>
  224. img[i].red = y; img[i].green = y; img[i].blue = y
  225. end
  226. end
  227. local N = 400*400
  228. local img = image_ramp_green(N)
  229. for i=1,1000 do
  230. image_to_grey(img, N)
  231. end
  232. </pre>
  233. <p>
  234. Ok, so that wasn't too difficult:
  235. </p>
  236. <p>
  237. <span class="mark">&#9312;</span> First, load the FFI
  238. library and declare the low-level data type. Here we choose a
  239. <tt>struct</tt> which holds four byte fields, one for each component
  240. of a 4x8&nbsp;bit RGBA pixel.
  241. </p>
  242. <p>
  243. <span class="mark">&#9313;</span> Creating the data
  244. structure with <tt>ffi.new()</tt> is straightforward &mdash; the
  245. <tt>'?'</tt> is a placeholder for the number of elements of a
  246. variable-length array.
  247. </p>
  248. <p>
  249. <span class="mark">&#9314;</span> C&nbsp;arrays are
  250. zero-based, so the indexes have to run from <tt>0</tt> to
  251. <tt>n-1</tt>. One might want to allocate one more element instead to
  252. simplify converting legacy code.
  253. </p>
  254. <p>
  255. <span class="mark">&#9315;</span> Since <tt>ffi.new()</tt>
  256. zero-fills the array by default, we only need to set the green and the
  257. alpha fields.
  258. </p>
  259. <p>
  260. <span class="mark">&#9316;</span> The calls to
  261. <tt>math.floor()</tt> can be omitted here, because floating-point
  262. numbers are already truncated towards zero when converting them to an
  263. integer. This happens implicitly when the number is stored in the
  264. fields of each pixel.
  265. </p>
  266. <p>
  267. Now let's have a look at the impact of the changes: first, memory
  268. consumption for the image is down from 22&nbsp;Megabytes to
  269. 640&nbsp;Kilobytes (400*400*4 bytes). That's a factor of 35x less! So,
  270. yes, tables do have a noticeable overhead. BTW: The original program
  271. would consume 40&nbsp;Megabytes in plain Lua (on x64).
  272. </p>
  273. <p>
  274. Next, performance: the pure Lua version runs in 9.57 seconds (52.9
  275. seconds with the Lua interpreter) and the FFI version runs in 0.48
  276. seconds on my machine (YMMV). That's a factor of 20x faster (110x
  277. faster than the Lua interpreter).
  278. </p>
  279. <p style="font-size: 8pt;">
  280. The avid reader may notice that converting the pure Lua version over
  281. to use array indexes for the colors (<tt>[1]</tt> instead of
  282. <tt>.red</tt>, <tt>[2]</tt> instead of <tt>.green</tt> etc.) ought to
  283. be more compact and faster. This is certainly true (by a factor of
  284. ~1.7x). Switching to a struct-of-arrays would help, too.
  285. </p>
  286. <p style="font-size: 8pt;">
  287. However the resulting code would be less idiomatic and rather
  288. error-prone. And it still doesn't get even close to the performance of
  289. the FFI version of the code. Also, high-level data structures cannot
  290. be easily passed to other C&nbsp;functions, especially I/O functions,
  291. without undue conversion penalties.
  292. </p>
  293. <br class="flush">
  294. </div>
  295. <div id="foot">
  296. <hr class="hide">
  297. Copyright &copy; 2005-2012 Mike Pall
  298. <span class="noprint">
  299. &middot;
  300. <a href="contact.html">Contact</a>
  301. </span>
  302. </div>
  303. </body>
  304. </html>