• <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,沒事找事,秀技能?  回復  更多評論   

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            常用鏈接

            留言簿(3)

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            国产精品99精品久久免费| 久久黄色视频| 久久精品国产亚洲AV无码娇色| 久久精品一本到99热免费| 99久久精品久久久久久清纯| 久久久久久久综合日本| 亚洲愉拍99热成人精品热久久| 国产精品久久久亚洲| 久久婷婷五月综合97色直播| 久久亚洲欧美国产精品| 看全色黄大色大片免费久久久| 久久亚洲精品成人av无码网站| 国产成人无码精品久久久免费| 久久综合亚洲色一区二区三区| 久久er国产精品免费观看2| 精品国产乱码久久久久软件| 97久久精品人人澡人人爽| 久久精品国产亚洲αv忘忧草 | 老司机午夜网站国内精品久久久久久久久 | 国产亚洲色婷婷久久99精品91| 99久久香蕉国产线看观香| 国内精品伊人久久久久影院对白 | 嫩草影院久久99| 蜜臀av性久久久久蜜臀aⅴ麻豆| 午夜精品久久久久成人| 国产午夜精品久久久久九九电影| 久久久精品国产sm调教网站 | 精品久久人人妻人人做精品| 久久精品aⅴ无码中文字字幕不卡| 亚洲一区精品伊人久久伊人| 欧美国产精品久久高清| 久久九色综合九色99伊人| 97超级碰碰碰碰久久久久| 亚洲精品国产成人99久久| 999久久久免费精品国产| 久久精品www人人爽人人| 九九久久自然熟的香蕉图片| 久久久无码人妻精品无码| 人妻丰满AV无码久久不卡| 国产偷久久久精品专区| 亚洲熟妇无码另类久久久|