Earlier quoted context omitted.
>that it would be tragic if it just slowly fades into obsolescence. Not going to happen. Too many people have sworn to keep improving it.
For the LuaJIT family to die all that's necessary is for people to stop selecting it for new projects. Time takes care of the rest.
RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)
11–14 of 14 posts
Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)
#12Author here with a little update from experience. Generally I am quite happy with this approach, but I am not wild about the cost/benefit of writing tools in Smalltalk. I've spent a lot of energy on treading water and trying to keep things working while the environment is being rewritten underneath my feet. I have also found that Smalltalk works best when data is imported into the Smalltalk heap, and represented by a…
In your opinion, should LuaJIT 2.1 users switch to RaptorJIT? I ask because the LuaJIT stewardship plan never materialized and it's been...too long.
Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)
#13Earlier quoted context omitted.
For the LuaJIT family to die all that's necessary is for people to stop selecting it for new projects. Time takes care of the rest.
Sure. But when my fork with 10% more speed is released, some fairly large companies are going to choose it and it will continue.
For the project to have a healthy future you really need a community of user-developers who are supported by multiple organizations and cooperating and coordinating with each other. LuaJIT doesn't currently have such a community and bootstrapping one is a doosey.
Re: RaptorJIT + Studio: Analyzing the evolving C heap of a JIT compiler (2017)
#14Earlier quoted context omitted.
Sure. But when my fork with 10% more speed is released, some fairly large companies are going to choose it and it will continue.
Sure. But if your plan is to do all the work by yourself, for the benefit of companies who aren't contributing much beyond occasional bug fixes, then you will eventually burn out like Mike Pall did. There won't necessarily be another sucker to take your place. For the project to have a healthy future you really need a community of user-developers who are supported by multiple organizations and cooperating and coordin…