How the JVM compares strings on x86 using pcmpestri • Hacker News Board

Re: How the JVM compares strings on x86 using pcmpestri

#71

Post by lvh » Mon, Jan 08, 2018, 3:35 PM UTC

quotemstr wrote: post #59

bdonlan wrote: post #56

Earlier quoted context omitted.

To be fair, when you're writing the C side of your JNI bindings, it'll also let you call any random pointer as if it were a C function of any type. You'll have non-type-safe code _somewhere_, it's just a choice of where.

Ah, not true! You'll have as much type-checking as C allows for, which is actually quite substantial. Moreso in C++. The opportunities for accidental type mismatch are much reduced: basically, to the JNI->function bindings (eliminated if you codegen the glue).

I see what you’re saying, but that piece of code doesn’t exist at all in JNR (so it can’t have bugs) and you can codegen JNR/FFI too to eliminate the same hole, right?

I feel like saying “don’t mess up this signature” is not only plausible but it’s a lot better than having to deal with writing and compiling the stub for every platform.

This is why pycparser exists, for example. https://github.com/eliben/pycparser

Re: How the JVM compares strings on x86 using pcmpestri

#72

Post by pcwalton » Mon, Jan 08, 2018, 5:26 PM UTC

eddyb wrote: post #65

pcwalton wrote: post #46

Earlier quoted context omitted.

pcmpxstrx is a lot more powerful than rep cmps. I'm lukewarm on pcmpxstrx too, but for a different reason: I'd prefer the effort to go into more general purpose, highly flexible SIMD instructions (which is thankfully happening now with AVX 512).

What do you think about Cray-style vectors, which are coming back in the form of ARM SVE and the RISC-V V extension? At least the latter claims code compiled once is compatible with all possible hardware configurations, from the start (by way of giving the CPU a "remaining iterations count" and having it reply with how many it can do for the chosen vector lane shapes). IMO, if it does end up working that well in prac…

Sounds like a good idea to me. Seems similar to how GPUs work, which is generally a good path to follow.

Re: How the JVM compares strings on x86 using pcmpestri

#73

Post by needusername » Mon, Jan 08, 2018, 8:46 PM UTC

lvh wrote: post #40

The JVM has a number of cool features that enable you to efficiently drop down into C (FFI) yourself: these tricks aren't just for built-ins. A quick overview: - First there was JNI. JNI means that you write method stubs with the "native" keyword. Then you run javah, which gives you some C glue code that you eventually need to compile. This is very fast, but it's annoying because now you need a tool chain everywhere.…

> Then you run javah, which gives you some C glue code that you eventually need to compile.

That's deprecated and no longer supported in Java 10. The recommend way is to use javac -h.

> This is very fast

There is a certain call overhead for JNI that JNA and JNR necessarily share as well. As a normal Java application you don't really have a way to get around this.

See https://stackoverflow.com/questions/36298111/is-it-possible-...

> but it's annoying because now you need a tool chain everywhere.

You only need a toolchain for building, you can just ship the .so. These days you get pretty far with Linux 64bit, macOS 64bit and Windows 64bit.