ext_ffi.html 10 KB

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