IRC channel logs


back to list of logs

***jonsger1 is now known as jonsger
***catonano_ is now known as catonano
<Wojciech_K_mkr>Thanks, sp1ff
<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>All are GNU projects, by the way.
<narispo>It's not about other non-GNU like DynAsm
<narispo>Or Cranelift
***apteryx is now known as Guest54769
***apteryx_ is now known as apteryx
<leoprikler>Sounds like NIH on drugs.
<tohoyn>sneek. botsnack
<ArneBab>narispo: they are different enough, that it isn’t easy to just merge them together. There are different approaches that get tried. GNU Guile is using a fork of GNU Lightning, by the way. For the reasoning, see
<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.
<jonsger>I tried once, but didn't get far
<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.
<narispo>jonsger: cool!
<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>ArneBab: It is for GNU Guile
<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>It is a total mess.
<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 )
<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." -
<dftxbs3e>libjit/doc/libjit.html - but I don't think they are right.
<dftxbs3e> - full link
<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>hendursaga: there's also Spook
<catonano>It does the same work of Haunt bu it's a distinct project
<stis>hej hopp guilers!
<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
<alextee[m]>and passing nil tells me unbound variable
<stis>alextee[m]: (address->pointer 0)
<stis>or such
<alextee[m]>stis: thanks!
<roelj>alextee[m]: There's also %null-pointer