主题：Lua 语言？ -- GUNXU
家园 Lua 语言？ 这是对zllwy GO 的介绍的回帖。再一想，可能重开行新贴更好
最近在考虑一个包含数据库的系统框架，所以非常关注系统内部应用层的编程语言。希望一定是一个脚本语言，以得到好的开发效率，以及在今后的应用中 real time deploy。因为系统时常有大量运算(文本及数值负载都很重）所以计算速度也很重要。又考虑系统的构成有很多部件，开发资源，维护资源（人力，财力）有限，希望尽量采用开源软件.python本是一个不错的选择，可是在速度上有短板，特别是GIL限制了多线程，现在看不出来在重新写过cPython的垃圾处理机制前有什魔希望解决，最近Google限制内部使用python的谣言让我但心JIT项目不会太顺利。
Lua在速度(JIT)，内存效率，多线程上有巨大的优势。可是有如下缺点
1) 社区没有python发达，库资源的丰富程度及文档支持远没有python丰富。
2）语言没有Python丰富，对我来说特别是缺乏OOP的原生支持和缺乏装饰模式的原生支持最恼火。（我们希望用装饰模式实现对原语言特色进行非侵入扩展，本来改Lua及LuaJIT的内核也可以加入额外的语言特色，但这样就可能在用其他Lua库时有风险，并且不能自动支持Lua升级）
希望得到熟悉Lua的河友指教。特别在如下方面：
1) Lua在构建大型系统时有何缺点。
2）介绍一下成功的Lua开源库，如:数值运算，网络支持，web应用，图形界面，2D-3D绘图,分布远程运算，日期时间时区。
3）LuaJIT在运行实际大型系统时的效率如何
4）Lua的程序量比相应的python差多少，比C好多少（代码的表达效率：如python可以用C 1/6.5的代码量实现同样功能）。
如果能像zllwy河友一样，系统介绍一下就更好了。
谢谢
关键词(Tags): #计算机语言，
本帖一共被 1 帖 引用 (帖内工具实现)- 复 Lua 语言？
家园 数值运算的语言 --- Lua 前几天，还在担心 LuaJIT 的更新速度，今天浏览项目网站时却仅惊喜地发现 LuaJIT 又出了2.0.0beta6版本。新版本除了增加了对PowerPC e500v2 内核的支持外，最大的亮点就是增加了FFI函数库。利用这个函数库,LuaJIT可以在Lua程序内流畅的调用外部C/C++函数库的函数以及直接定义并利用C/C++数据结构。直接的好处是方便了扩展库的开发，使得Lua程序员可以更少的依赖C/C++语言环境。间接的好处是开发者在纯Lua环境里有更多的手段提高运行效率和内存使用效率。因为C/C++的数据结构是静态类型，这给JIT引擎足够信息以使其采用更好的优化策略，另外内存表示没有Lua额外的开销，数据更紧凑，占用空间更少，运行时缓存击中率更大，速度相应更快。
FFI＋的优点清除了纯粹利用Lua作数值计算在原理上的障碍．因为在数值运算单元里我们可以直接作用在C/C++数据结构上．JIT可以帮助我们以C速度甚至以超C速度运行（因为JIT的动态优化）．当然，在LuaJIT里的效果究竟如何还要看LuaJIT本身的实现，有时间会做个测试．
这个进步也去处了我的系统里@Accelerator{} （http://www.ccthere.com/article/3282394）的必要性和紧迫性，虽然我们的＠Accelerator模式构想更高效，更安全，更容易维护（这是在更加限制支持的数据结构和数据操作方式的代价上的取舍）。
本帖一共被 1 帖 引用 (帖内工具实现)家园 luajit+ffi 数值运算快过gcc o2 优化一倍 还没有来得急自己测试，已经有人测试了LuaJit用纯Lua代码实现常微分方程数值解，并且比较了与gcc编译的c代码的运行速度。不出意外结果很好，意外的是居然是在window环境下是c速度的两倍。
http://lua-users.org/lists/lua-l/2011-02/msg00668.html
关注数值运算的朋友们，咱们还等什么呢，换语言吧！
当然lua比python，matlab还有不足，数值函数库不发达，可是numlua已勉强可用，http://numlua.luaforge.net/
gsl-luabinding 也已存在，http://savannah.nongnu.org/projects/gsl-shell/
实在不济，先用lua-python调用numpy，scipy对付着，等以后lua赶上再换。http://niemeyer.net/lunatic-python
lua里调用numpy的例程
http://stackoverflow.com/questions/388172/scientific-libraries-for-lua
我们再来看看换语言的好处
1。比c强的是语言是动态的，不用自己管理内存，代码量少，开发，改错，应用容易。一句话，好学好用好折腾。
２。比python好的地方是，语言效率高，接近c语言速度，比python快10，20倍。完全可以胜任绝大多数科学计算，数据处理的要求，语言痕迹小，需要的硬件少，是手持设备，电力设备，通信设备，机器人，工业控制，实时系统应用的利器！
3。比matlab的好处是，免费，是一个一般应用语言，可以写大系统，复杂应用，在计算外的支持广泛得多，特别的界面支持，网路支持，matlab简直是悲剧。免费跨平台支持。对多系统分布运算，matlab恐怕不是一个选择。
４。对喜欢自己折腾的个人企业，它是一个开发适于自己需要的语言的绝佳平台。
不足：
现阶段社区还小，库不多。但如果大家一起关注，参与，我们的日子会越来越好
1。
本帖一共被 1 帖 引用 (帖内工具实现)
- 复 Lua 语言？
家园 作为数值运算的语言 --- Lua, LuaJIT FF - 复 Lua 语言？
家园 文本及数值负载都很重? 处理文本是PERL和python的强项，数值负载是matlab和python的强项，那还有什么可说的？
两大短板？
速度上有短板——怕什么，核心算法用C编写，反正python不是号称胶水语言吗
特别是GIL限制了多线程——怕什么，修改python源代码就是了。不过我对GIL也不是很了解，需要多线程到什么程度，项目有什么特点，还得具体分析。但是一般来说，不会苛刻到某种程度，否则还有什么好选的？所以应该还是没问题。
家园 去除GIL比较困难 Python的作者Guido van Rossum 在2007年9月写过一篇Blog: It isn't Easy to Remove the GIL
GIL一方面使得GC(引用计数)容易实现，一方面限制了多线程只能同时使用一个核。
在Python早期，尚未会有现在这么广泛严肃的应用需求，当时个人电脑使用多CPU也还罕见，因此问题尚不严重，后来在1999年Greg Stein 等人进行了尝试去除GIL，虽然实现了GIL去除，但是性能反而下降了(至少对于单线程的应用来说是下降的)。
现在新的GIL实现相对旧的性能有所改进，另外Python的C扩展、磁盘IO、网络IO也会释放GIL，因此主要影响计算密集型应用，这类应用Python本来相对C、C++、Fortran速度也差很多，可以考虑密集运算部分写为C扩展，即提高了速度，也不受GIL限制。Cython也是提高性能相关的工具。
另外，还可以通过多进程来利用多核/CPU。
家园 python不错，Lua也很好 文本恐怕Perl最强，可是不是一个可以写大系统的语言。python的数值功能由scipy，numpy提供，事实上是胶水功能，其他的脚本语言很容易复制。我希望的是直接用脚本语言写数值算法的能力，这样开发，和使用时才会方便。这也适用于核心算法，我希望只有有限的代码由C开发，其余全由脚本实现。这个应用中，开发与使用结合得很紧，可以说开发就是使用，使用既是开发。除了系统本身的消息机制和数据库组织机制外没有固定的应用层的定制要求，许多应用可能是一次性地，系统的应用层组织机构都可能随时间变化所以快速开发，快速推入正式运用版本十分重要。一天中十几个几十个的更新是常有的事，所以静态编译语言很难赶上应用需求的变化，非得脚本语言不可。这也可以看出，越多的脚本语言的成分，系统就越灵活反应就越快。
python的代码量太多，原生结构复杂，改核心而不损失性能，和第三方资源的兼容性可不简单。于此对应，Lua核心（编译，动态库，解释器)源代码只有17000行C程序，又有再入式编译器，可以非侵入性的扩展原语言，简单性带来的好处可不少。还有，Lua也有Gil，与我的想像不同，但是多CPU的支持可以由扩展库实现，python也可以，这点两边没有高下。
家园 请教什么是再入式编译器和非侵入性的扩展原语言？ 被你说的勾起了兴趣，有空打算看看LUA源代码。不过你说的再入式编译器和非侵入性的扩展原语言概念不是很懂，能否讲讲呢。谢谢先。
家园 再入式编译器和非侵入性扩展 就是编译器充份模块化在编译的个阶段都可以插入自己的代码对编译中间结果进行变换。并再次调用编译器，或持续编译过程，这样就可以加入自己的语言结构，只要保证接口匹配，还可以保证原语言环境的正确，这样第三方库在扩展的语言环境下也可以运行无碍。以达到非侵犯原语言特色的效果。
Lua有一个开源库MetaLua，就是为此准备的。
家园 能不能具体介绍一下 具体在什么情况下要这么作呢?这么作有什么优势呢?
家园 比如说 语言里没有原生OOP支持,我们可以自定义OOP的语法元素,在编译器里扫描这个特征的字符串,再插入相应原生语言的代码实现OOP内部的机制.再比如应用中有许多一定设计模式的要求,设计模式的实现往往要很多写很多语句,用到一定的额外数据结构的支持,编程时费事费力,还要纠错.可是概念上,这些工作都是重复劳动,完全可以让编译器自动生成相应的代码,从而让编程者只专注于算法,核心逻辑,而不用考虑其他.这样一来,应用会简单得多.为了维持一个好的系统,我们可以把设计思想印在语言里,而引导(甚至强制)后来的编程者自觉不自觉地贯彻原始设计思想.这个哲学对我们系统的成功很有关系.因为,系统的应用变化量太大,适用性,灵活性,快速反应性,时效性要求很高,不可能用软件工程的管理模式来控制质量.只有靠"代码文化"或是同伴的互相监督制度来保证,这样一来,一个印入设计思想的语言不仅可以加速开发,还是这个"代码文化"的宪法和保障.
说上面说的可能有点玄,在举个实际一点的例子.如果我希望一段用脚本语言写的数值运算的代码有C的速度,我可以创造一个标识代码如@Accelerator(){ }, 把这段代码包含起来，在运行时把它直接编译成汇编程序（当然要有合适的接口以适应上下文），而在纠错时只是把标识代码去掉，这样可做到无缝的纠错，无缝的高效运行。在这个系统里，脚本语言的“胶水特性”恐怕就剩不下多少了。同样在利用GPU高速运算时，一个瓶颈是写Cuda代码，我们也可以用类似的技术简化应用的门槛。(这里也许有人会记起Python里的CType.但是这个构想更接近于JIT，因为我们还是在写脚本语言的语句，而不是在脚本程序中加入C语句。和JIT不同的地方是我们严格限制在@Accelerator里的原生语法只是作用在数值类型和数组类型，所以实现简单，也比JIT快）
一句话，脚本语言，编译技术已经把编程的技术门槛降的很低。在IT技术中，也许是离开关注编程，编程语言和设计模式的时候，而是把注意力转到具体的应用和问题上。经常和朋友笑说“珍视生命，远离C++"，大家姑妄听之。
本帖一共被 1 帖 引用 (帖内工具实现)
- 复 Lua 语言？
家园 Lua 语言强过很多静态编译语言 作了更多搜索，发现原帖的两个问题都不太大。Lua用多态表和默认机制支持OOP，虽然不如原生支持好看，可也没问题，好看不好看多半是习惯问题，用多了就好了。语言的扩展问题可以用再入式语言解析器解决。Lua51已经支持。
这样看来，Lua真是不错的语言。具http://shootout.alioth.debian.org/的结果如果用LuaJIT，速度上可以达到C程序1\2的水准，与Java，Go相当。程序量是C的1\4，Java，Go的1\2或少。又是动态解释语言，开发检错快得就不止两倍。在内存效率上与Java，Go相当。又有非常方便的的C接口（比Python简单因为不需要管理垃圾处理器的计数，比python更有效率因为函数调用的额外损失小）。宁外，Lua语言的实现对可移植性的要求达到了苛刻的程度，实现只用Ansi C与C++85标准的交集（可惜，LuaJIT在理论上没法达到这个要求，LuaLlvm可移植性好一点，可是由于LLVM中间层的加入，效率差了一些）如果开源库足够发达的话，好像正好是C语言与Python的中间选择。
愿大家关注Lua语言，多参与Lua开源运动。
那吗，为什么要Java和Go呢？