mikemike

10 ms·

31.
by mikemike 14y ago
This is not about Linux. Every brittle OS on ARM uses the standard ABIs. But Apple can't? Gimme a break.
32.
by mikemike 14y ago
The initial LuaJIT ARM port was targeted at low- to middle-end ARM devices without an FPU. It took some time to find another sponsor for the VFP port. Work on VFP and hard-float EABI (armhf) is already in progress and will be available soon
33.
by mikemike 14y ago
No there's no reason to bring this up now. First, it has been worked around and second, VFP support for the LuaJIT ARM port is already in progress (parts are in the git repo, not enabled yet).
34.
by mikemike 14y ago
There's no explicit API to pin objects from the C side. Ok, so there's an implicit contract on which pointers to internal VM objects are still valid, once the C side has gotten them (const char *lua_tostring() is the biggest offender). But
35.
by mikemike 14y ago
Err, I think you mean "why DON'T you get ...". :-/ I guess this has to do with the way the gaming industry works. The smaller game companies have maybe two or three big hits until they go under and/or the talent is bought out. The bigger on
36.
by mikemike 14y ago
Yes, I thought about crowdfunding. But I fear that a) the Lua community is way too small to gather enough interest and b) it looks like the whole crowdfunding idea is rapidly deteriorating into an arms race of marketing experts. So many peo
37.
by mikemike 14y ago
Yes, this is the exact same situation as on iOS. But 1. the mobile app market was even more locked down before Apple entered it and 2. Apple is the media's darling.
38.
by mikemike 15y ago
[LuaJIT author here:] I'm not so sure the business model of LuaJIT can easily be applied to other open source projects. I mean, I've been running a business for more than 15 years. I basically downscaled consulting as I've acquired paid ope
39.
by mikemike 15y ago
Correction: LuaJIT is not yet supported on consoles. I'm confident the remaining legal issues can be resolved soon. Note this is referring to the high-speed interpreter written in PPC assembler which gives you a 2x-6x speedup over plain L
40.
by mikemike 15y ago
LuaJIT is written with security in mind. LuaJIT 2.x had permanent write-protection enabled for the generated machine code in the first release, i.e. before anyone else did so. I do not see how maintainability could somehow have an inverse
41.
by mikemike 15y ago
After some improvements to the code generator, LuaJIT git HEAD now wins on all SciMark sub-benchmarks: ARM11 SciMark SMALL | FFT SOR MC SPARSE LU -----------------------+---------------------------------------
42.
by mikemike 15y ago
IMHO Jazelle and ThumbEE are just marketing gimmicks. Jazelle was (is?) half-proprietary and is only useful for a really stupid Java bytecode interpreter. Nowadays, Java is JIT-compiled with much better performance. And ThumbEE came way too
43.
by mikemike 15y ago
Well, I don't have an estimate of the costs for this feature, yet. And I need to talk with the current sponsor of the ARM port first. Yes, LuaJIT uses its own memory allocator, which improves performance for workloads with lots of allocatio
44.
by mikemike 15y ago
Sorry, I have no quantitative comparison for that. It's baked into the design of the register allocator to schedule loads early and to rematerialize constants far ahead of their use. And I'm contemplating to add an extra scheduling pass for
45.
by mikemike 15y ago
LuaJIT/ARM uses the dual-number VM mode, where numbers can be either represented as 32 bit integers or as a double. It uses lazy normalization, so conversions happen as needed. This is invisible to the user, but internally there are two dif
46.
by mikemike 15y ago
LuaJIT/ARM runs fine on an Cortex-A8 or Cortex-A9. The instruction scheduling for the simpler in-order architectures is beneficial for the newer architectures or for out-of-order architectures, too. And even though it needs at minimum ARMv5
47.
by mikemike 15y ago
Ok, I made some quick benchmarks, comparing LuaJIT git HEAD and Dalvik 1.2.0 (Android 2.2.1) on the MSM 7201A (528 MHz ARM11 soft-fp). I don't have access to a newer Dalvik VM for this device. The Dalvik JIT compiler is definitely enabled,
48.
by mikemike 15y ago
That post is ancient ... here are newer SciMark results for LuaJIT: http://lua-users.org/lists/lua-l/2010-12/msg00924.html
49.
by mikemike 16y ago
So what? Look at the C, Ada or ATS submissions for even more 'crazy hackery'. My programs are quite straightforward in comparison.
50.
by mikemike 16y ago
If the submissions using low-level types would be included in the total score, LuaJIT would show at around 1.5x instead of 2.5x.
51.
by mikemike 16y ago
Same experience here with LuaJIT. My submissions using low-level types (byte arrays and such) were put into 'interesting alternative', too. Almost all other languages can use byte arrays, when they are the appropriate data structure for the
52.
by mikemike 16y ago
Alias analysis is a good example. A JIT compiler may speculatively add dynamic disambiguation guards (p1 != p2 ==> p1[i] cannot alias p2[i]). If the assumption turns out to be wrong, the JIT compiler dynamically attaches a side branch t
53.
by mikemike 16y ago
This is a common misinterpretation of the Dynamo paper: they compiled their C code at the _lowest_ optimization level and then ran the (suboptimal) machine code through Dynamo. So there was actually something left to optimize. Think about i
54.
by mikemike 16y ago
Well, here's Euler14 in Lua for a start: http://lua-users.org/lists/lua-l/2010-09/msg00568.html But obviously for a proper comparison of the runtimes the benchmarks need to be implemented the 'same way' and not simply yield the 'same resu
55.
by mikemike 16y ago
The performance problems originate in the design of your trace compiler, not in static vs. dynamic dispatch. Some suggestions: * The interpreter should have a fast profiling mode (hashed counting of loop backedges) and a slower recording mo
56.
by mikemike 16y ago
http://luajit.org/sponsors.html
57.
by mikemike 16y ago
Sigh, not that nonsense comparison again. Apart from using suboptimal Lua code (the author obviously doesn't know about the Lua keyword 'local'), LuaJIT beta2 didn't compile recursion at all. It runs more than 4x faster with the current ver
58.
by mikemike 17y ago
Actually reading the Lua mailing list post http://lua-users.org/lists/lua-l/2010-03/msg00305.html , referenced in the linked text might help: > For pidigits I'm comparing the pure JS and Lua programs, not the GMP bindings. I'm comparin
59.
by mikemike 17y ago
The result of the distance() function is unused and can be optimized away by the compiler. Runs in 0.04s with LuaJIT 2.0. No type declarations needed. :-) local radius = 6371 local function distance(latA, lngA, latB, lngB)
60.
by mikemike 17y ago
Most of the VM is written in C. Only the core of the interpreter is written in assembler (generates ~13K of machine code). And the port of the interpreter to x64 is already done, so it was certainly practical. Porting the rest of the VM and

More ›