***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<narispo>it's unfortunate that work on JIT backends is being duplicated across libjit, libgccjit, GNU Lightning and within GNU Guile itself - the result is poor platform support. <narispo>It's not about other non-GNU like DynAsm ***apteryx is now known as Guest54769
***apteryx_ is now known as apteryx
<narispo>ArneBab: I heard that in a conference from Andy that they werent happy with GNU Lightning <ArneBab>narispo: see the blog entry, it’s about that and the why <narispo>ArneBab: I see, well I need PowerPC 64-bit le and be support but I'm not well versed enough with PowerPC 64-bit assembly and ABIs to write things such as JITs. <narispo>ArneBab: Are GNU Lightning authors just gone? <narispo>Because if not, I am certain they could address Andy's concerns or at least help. <ArneBab>Looking at the blog post, that doesn’t seem likely, because they have a different technical vision. The best approach for something depends on your use-case and Andy's approach didn’t match where they wanted to go. <ArneBab>narispo: do you need PPC 64 support for Guile or for something else? <narispo>Visions are important but community work is important too <narispo>I am certain there is a common ground to find between Andy vision and GNU Lightning <ArneBab>yes, it is. And our limited free time often forces us to priorize. <narispo>After all, both Guile and Lightning are GNU projects, it's not like complete strangers. <narispo>I am porting GNU Guix to PowerPC 64-bits <ArneBab>I trust Andy that he tried to find common ground but found that we wouldn’t be able to do the work on Guile with that. <narispo>It is very sad. The goal of GNU Lightning is to be useful and it's not. I thought RMS was especially careful to try not to duplicate work but it seems there's 3-4 JIT libraries within the GNU eco-system. <narispo>JIT is a big problem for portability. Around the eco-system, it seems everyone is using specialized JIT engines. There is no go-to library that everyone can use and be happy with it's design to feel like they can contribute to adapt it to themselves. <narispo>LLVM and GCC have made AOT compilers more portable but JIT compilers which have different needs do not benefit from this at all right now. <narispo>WebKit, Firefox and Chromium are also all using their own JIT engines. <narispo>Porting a JIT requires advanced expertise that isnt easy to find. <narispo>It's one of the worse areas of computer engineering to do duplication in when it comes to portability. <ArneBab>While I think that your analysis, that this is a problem, is correct, the reason is most likely that we’re already happy to have some people at all who invest into JIT-work. <ArneBab>(sidenote: Java and pypy also have their own JIT — possibly the decisions in a JIT-engine are more closely tied to the exact needs of the language than an AOT compiler) <ArneBab>(replace "language" with execution environment — virtual machine) <ArneBab>(execution environment, because there are now many languages on the JVM and on pypy — but for all the speed of the JVM, kawa, which is a scheme on the JVM, is on the slower end of the Scheme implementations. See https://ecraven.github.io/r7rs-benchmarks/ ) <dftxbs3e>ArneBab, It is definitely a problem eco-system wide that needs solutions. There has to be a common denominator that allows both portability and writing performant JITs. It could be as simple as a portable macro assembler that makes best use of the CPU features as it detects them and then you are free to do whatever you want on top. If there was a single place where everyone put work into, then the problem of finding people to write JITs would be <dftxbs3e>solved. The designers of GNU libjit argue the contrary: "However, there is a problem with current JIT approaches. In almost every case, the JIT is specific to the object model, runtime support library, garbage collector, or bytecode peculiarities of a particular system. This inevitably leads to duplication of effort, where all of the good JIT work that has gone into one virtual machine cannot be reused in another." - https://www.gnu.org/software/ <dftxbs3e>libjit/doc/libjit.html - but I don't think they are right. <dftxbs3e>Oops, more relevant: "Most of the work on a JIT is concerned with arithmetic, numeric type conversion, memory loads/stores, looping, performing data flow analysis, assigning registers, and generating the executable machine code. Only a very small proportion of the work is concerned with language specifics." <dftxbs3e>I don't mean to quote the first one but the second. <dftxbs3e>There's also GraalVM that tries to support many languages at high speed by Oracle, not sure if it can succeed. <catonano>It does the same work of Haunt bu it's a distinct project <alextee[m]>is there a way to pass NULL via guile to my C side? <alextee[m]>passing 0 tells me Wrong type argument in position 1 (expecting POINTER_P): 0 <stis>alextee[m]: (address->pointer 0) <roelj>alextee[m]: There's also %null-pointer