• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            天地之靈

            LuaJIT之callback大坑繞路記

            近期在做node.jsLuaJIT portLuaJIT是當前已知最快的腳本JIT編譯器,拿來做服務器再好不過。
            發現node.js底層所用的庫libuv簡直是個神器,包含了網絡、文件系統、計時器等等一堆堆的有用功能,windows、linux、MacOS等均支持,而且是純C的API,和LuaJIT結合會比較友好,理論上不用任何額外的C代碼,依靠ffi庫就可以搞定,經過試驗也確實如此,于此同時發現LuaJIT也真神器也,居然可以直接把Lua函數當做C函數指針傳進去當回調!正當我躊躇滿志的準備跑下性能測試就開始做上層封裝的時候,結果楞了:

            1、Lua版的idle示例,等待一個idle事件被調用1e7(一千萬)次,在C下只需要區區0.1秒,在lua下需要足足30秒多!并且內存在這個過程里猛漲猛漲再猛漲,最后的gc過程耗費了更久的時間!
                原版的在這里,Lua版的在這里
            2、嘗試添加1000次idle事件,LuaJIT直接報錯:too many callbacks
            3、其他不同的嘗試均體現,性能嚴重不過關。

            然后在ffi的說明里發現了這個,提到了幾個問題:
            1、callback占用某些總量有限的系統資源,所以用過的callback需要釋放,并且同時存在的callback只能有500-1000個。
            2、callback函數不會被自動gc,需要用一些麻煩的辦法手動來釋放
            3、callback會很慢。文中提到了類似于lua_call的消耗及argument marshalling的消耗。這點會在下面詳細講述。

            總的來說,luajit里的callback,是在內存里生成了一小段代碼,這小段代碼的功能是把參數轉換好,然后再調用對應的lua函數。(還有一些奇奇怪怪的開銷,我個人認為這才是主要開銷,后面會詳細講述),因此有同時存在的總量上限(雖然我也不明白為什么就因此了,但大致就是那么回事吧),并且很慢,很慢,很,慢,很……慢……

            基本上,解決方法就那么幾種:
            1、做一些特定的封裝,用C額外編寫一個函數做一些處理,在這個函數里用其他方式(lua_pcall等)去調用,這樣調用參數的類型會受限一些。經測試這個只能提升50%左右(距離之前的300倍差距還差得遠……),主要是還有一些關鍵的開銷(在下面詳細講述)無法避免。
            2、改寫被使用的C庫,拒絕回調,用其他辦法實現。這是LuaJIT官方所推薦的,原文如下:
            For new designs avoid push-style APIs: a C function repeatedly calling a callback for each result. Instead use pull-style APIs: call a C function repeatedly to get a new result. Calls from Lua to C via the FFI are much faster than the other way round. Most well-designed libraries already use pull-style APIs (read/write, get/put).
            但像libuv這樣的庫,改寫難度有些大……關鍵在于重新設計整個結構為pull-style很困難,同時會導致相關文檔廢棄,增加了額外的工作量。
            3、小幅度改寫使用的C庫,公開一些必須的內容,然后把其中的一部分在lua里實現,確保所有callback調用的時機均在lua中,廢棄掉原始的C API。這樣相對來說不用改變任何的接口,但是工作量也不小,取決于庫的復雜程度。

            最終我在node.lua中選擇了方案3。事實證明效果確實很好,在還有一些會帶來額外開銷的功能沒加進去的情況下,之前的test優化到了0.08s左右,預計全部完成后開銷在0.15s之內,很接近純C實現的性能。

            然后我又做了若干實驗,并且在freelist里和LuaJIT的創始人Mike請教了一會,得到了一些結論:

            1、回調的argument marshalling是重大瓶頸之一。雖然不知道為什么,Lua對C的調用,返回值的marshalling性能很高,我推測是由于原因3。
            2、把Lua-function cast成C function pointer是另一重大瓶頸,如果存在反復的類型轉換,這里會很要命。這里包含了之前所說的生成指令序列的開銷,但cast本身也會具有巨大的開銷,我嘗試將一個C function cast成 C function pointer,都帶來了極大的開銷。據Mike說,這個開銷也是原因3導致的
            3、導致程序運行很慢的原因,歸根結底:某些行為會導致JIT失效!在沒有JIT的情況下,本身運行性能差不多就有幾十倍的損失,再加上一些額外開銷會因此被放大,最后就得到了不可接受的性能損失……

            最后總結,目前應該在LuaJIT的ffi庫中避免使用函數指針,使用Lua本身來封裝回調函數(如果接口需要),方可獲得LuaJIT提供的卓越性能。

            posted on 2013-02-24 14:36 天地之靈 閱讀(19632) 評論(7)  編輯 收藏 引用

            評論

            # re: LuaJIT之callback大坑繞路記 2013-02-25 09:42 emptyhua

            和這個項目比做了哪些改進呢?https://github.com/luvit/luvit  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2013-02-25 10:08 天地之靈

            @emptyhua

            原本的目的是多用ffi,少對libuv庫進行修改,避免對lua C API的調用,看能否取得更好的擴展性和性能提升。
            在之前的項目里采用C API去封裝回調,遇到了一些有關coroutine的坑,譬如在coroutine里開始一個主循環,在另一個coroutine里再注冊一些回調,使用C API有時候很難完美解決。

            所以這個項目的思路是,盡可能直接使用第三方的C庫,使用ffi來訪問API,而非去實現一個Lua C Module,這也是LuaJIT官方所推薦的,這會讓luaJIT的優化達到極致(C API訪問,以及對Lua-C Module里函數訪問時的傳參,會有不能被LuaJIT編譯優化的開銷,雖然這個開銷對于非頻繁調用的內容并不大)
            另外一個原本預期中的好處是,希望這個項目最終能只有Lua代碼,以及luajit主程序、編譯好的其他庫的動態鏈接版本,便于去修改、發布及調試。只是目前來看完全這么做還是有點困難,因為現在已經對libuv做了一些修改。但是使用其他callback不那么常見的庫可能會相對輕松。我可能再進行一些嘗試后再決定如何折衷,或者放棄這個,去fork和參與luvit。

            另外luvit與我這邊的實驗均證明,使用LuaJIT會取得比V8好數倍的性能~所以這個方向應該是沒錯的。  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2013-03-01 06:04 essayforce

            最終能只有Lua代碼,以及l\主  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2013-05-14 14:42 imjj

            我測試的結果跟你有所不同,參看
            https://bitbucket.org/lijia/pieceofcode/src/d02e87d97ab38226f44549b9f5ea0a4d408482a5/lua-uv-test?at=master  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2013-08-22 13:26 天地之靈

            @imjj
            原因不明。我這里的性能明顯下降應該有gc的影響。  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2014-10-01 00:31 jiakai1000@gmail.com

            你好,我想請問:
            3、小幅度改寫使用的C庫,公開一些必須的內容,然后把其中的一部分在lua里實現,確保所有callback調用的時機均在lua中,廢棄掉原始的C API。這樣相對來說不用改變任何的接口,但是工作量也不小,取決于庫的復雜程度。
            "確保所有callback調用的時機均在lua中",能說一下具體是怎么做的嗎?這樣的話就不需要從lua調用c了嗎?
            謝謝。  回復  更多評論   

            # re: LuaJIT之callback大坑繞路記 2015-09-10 23:08 se

            sb,沒事找事,秀技能?  回復  更多評論   

            <2014年11月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            30123456

            導航

            統計

            常用鏈接

            留言簿(3)

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品中文字幕有码| 色偷偷偷久久伊人大杳蕉| 亚洲va久久久噜噜噜久久天堂| 久久亚洲国产精品一区二区| 人妻无码αv中文字幕久久琪琪布 人妻无码久久一区二区三区免费 人妻无码中文久久久久专区 | 77777亚洲午夜久久多喷| 久久久久亚洲AV综合波多野结衣 | 久久er国产精品免费观看2| 亚洲va久久久噜噜噜久久狠狠| 国产99久久久国产精品小说| 久久综合偷偷噜噜噜色| 久久笫一福利免费导航| 狠狠色婷婷久久综合频道日韩| 久久久免费观成人影院| 国产精品一区二区久久精品无码| 国产午夜福利精品久久| 色综合久久综精品| 国产AⅤ精品一区二区三区久久 | a高清免费毛片久久| 久久99国产精品一区二区| 99久久国产热无码精品免费久久久久 | 久久人妻少妇嫩草AV蜜桃| 久久高潮一级毛片免费| 一本色道久久88综合日韩精品| 伊人精品久久久久7777| 少妇久久久久久被弄高潮| 久久精品国产亚洲AV电影| 99久久成人18免费网站| 国产精品久久久久久久久软件| 久久精品国产亚洲AV香蕉| 精品综合久久久久久888蜜芽| 亚洲国产成人久久综合碰碰动漫3d| 久久国产福利免费| 色综合久久无码中文字幕| 麻豆精品久久久一区二区| 久久强奷乱码老熟女| 色欲综合久久中文字幕网| 亚洲午夜久久影院| 免费无码国产欧美久久18| 久久精品国产秦先生| 久久久久国产精品嫩草影院|