递归展开是VC的弱势,VC2010使用/MD /O2编译,运行结果是100.8s,体积是3KB

回复：15楼
参数不一致吧，我记得4.6的Ofast是默认开启fastmath的，4.5没这个开关，得手动加入
-O3 -ffast-math

后来也测了4.6的-O3,结果几乎没变,因为没有浮点运算,-ffast-math应该不起作用.
f()生成代码的大小对比是:
TDM-4.5.2:    1B6h
PCXPRJ-4.6.0: 242h
VC2010:        2Ch

我还是使用自己编译的4.5.3，tdm的测试太长时间了，后来4.5.2解决的bug也都没补上

CPU: AMD Phenon II @ 3.1G
qpgcc 4.4.5: -O4 -s -ffast-math -march=k8
8.5k, 26s
vc2010 sp1: /Ox /Ob2 /Oi /Ot /Oy /GL /Gm- /MT /GS- /Gy /arch:SSE /fp:fast
29k, 35s
vc是差得比较多，但绝对到不了100秒啊

用了20楼的参数(除了/MT改成/MD),结果仍然是101秒
CPU: Intel E8400 @ 3.0G

这是VC2010(SP1)的f()编译结果:
00401000  /$>push    edi
00401001  |.>mov     edi,[esp+8]
00401005  |.>cmp     edi,2
00401008  |.>jge     short 00401011
0040100A  |.>mov     eax,1
0040100F  |.>pop     edi
00401010  |.>retn
00401011  |>>lea     eax,[edi-2]
00401014  |.>push    esi
00401015  |.>push    eax
00401016  |.>call    00401000
0040101B  |.>dec     edi
0040101C  |.>push    edi
0040101D  |.>mov     esi,eax
0040101F  |.>call    00401000
00401024  |.>add     esp,8
00401027  |.>add     eax,esi
00401029  |.>pop     esi
0040102A  |.>pop     edi
0040102B  \.>retn

酷睿双核笔记本 lenovo-Y450
测试结果是
gcc优化开关为-O3 -fivopts -ftree-loop-linear -ftree-vectorize -fforce-addr -fomit-frame-pointer -fno-bounds-check -funroll-loops -ffast-math -march=native -mfpmath=s****x -msse -msse2 -msse3 -ftree-parallelize-loops=2
4.5.3为35.444s
4.6为31.438s
vc2010优化开关为/O2 /Ob2 /Og /Oi /Ot /Oy /fp:fast /arch:SSE2 /GL /MT
148.275s
vc2010优化开关为/Ox /Ob2 /Og /Oi /Ot /Oy /fp:fast /arch:SSE2 /GL /MT
147.833s
intel12优化开关为/fast /O3 /Ot /Og /Oi /Qipo /QxHost /arch:SSE3 /Qunroll /Qvec /Quse-intel-optimized-headers /Qparallel /fp:fast=2 /Ob2 /GT /GA
103.309s

测试了PCXPRJ的gcc-4.6.1编译的lua性能,已经超越VC2010,快了5%.

不过编译的有问题,运行有错误的lua程序不会报告错误提示,而是崩溃了.
而TDM的4.5.2版没有此问题.
用4.6.x编译时,会有一些这样的警告,不知道是否有关:
ldo.c: In function 'luaD_pcall':
ldo.c:592:13: warning: variable 'old_ci' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
In file included from lauxlib.c:600:0,
                 from llex.h:64,
                 from :85:

回复：26楼
恩，这是有可能的，4.6及以上现在在windows下表现还不稳定，你可以试试我编译的4.5.3版本，如果还是发生崩溃的话，那么就可以确定是mingw64 crt的问题，可以向mingw64项目组报告

回复：27楼
测试了 MinGW_gcc4.5.3.20110317_static_win32.7z 编译的lua, 虽然编译时也有那些类似的警告,但没出现崩溃.

回复：27楼
PCXPRJ的gcc-4.6.x又发现一个很严重的问题, 编译成dll后, 如果加载时需要重定位, 会导致不正确, 跟踪发现是这里(DLL初始化代码):
10001410  /$>push    ebp
10001411  |.>mov     ebp,esp
10001413  |.>push    ebx
10001414  |.>sub     esp,14
10001417  |.>mov     ebx,[<&KERNEL32.GetModuleHandleA>]   ; |kernel32.GetModuleHandleA
1000141D  |.>mov     dword ptr [esp],1010A000             ; |ASCII "libgcc_s_dw2-1.dll"
10001424  |.>call    ebx                                  ; \GetModuleHandleA
10001426  |.>mov     edx,0 ; 这里的0是会重定位的值,如果重定位就不是0,导致下面call edx不正常
1000142B  |.>sub     esp,4
1000142E  |.>test    eax,eax                              ; |
10001430  |.>je      short 10001448 ; 这里会跳转          ; |
10001432  |.>mov     dword ptr [esp+4],1010A013           ; |ASCII "__register_frame_info"
1000143A  |.>mov     [esp],eax                            ; |
1000143D  |.>call    [<&KERNEL32.GetProcAddress>]         ; \GetProcAddress
10001443  |.>sub     esp,8
10001446  |.>mov     edx,eax
10001448  |>>test    edx,edx
1000144A  |.>je      short 1000145D ; 重定位时edx不是0
1000144C  |.>mov     dword ptr [esp+4],1012E004
10001454  |.>mov     dword ptr [esp],1011A000
1000145B  |.>call    edx

用TDM-MingW-GCC 4.5.2的crtbegin.o和crtend.o覆盖4.6版的, 貌似没有问题了.

回复：29楼
dwing你能测试我的4.5.3么？我前段时间编译gotoblas2的dll（需要重定位）时似乎也遇到了该问题，我当时不是很肯定，后来就没深究原因。
crtbegin.o和crtend.o属于CRT的东西，如果测试还是有问题，那么我会抽时间diff下mingw32和mingw64的相关代码。
ps：另外，你的重定位是使用dllwrap么？