uschindler edited a comment on pull request #177: URL: https://github.com/apache/lucene/pull/177#issuecomment-866087762
Hi @mikemccand, > > I have no idea why the facetting stuff at the beginning of the bench output is so badly behaving with MMapDirectory#v2 on top of project panama, I'll ignore this for now. Maybe @mikemccand has an idea! The rest looks perfectly fine to me from the performance (19 runs). > > Yeah that is strange. The impact is sizable. These tasks effectively run a `MatchAllDocsQuery`, and for each hit (doc) decodes the packed delta-coded int ordinals from a `BinaryDocValues` field, incrementing counters in a big `int[]`. To the `MMapDirectory` it should look like it's doing a big sequential scan of that `BinaryDocValues` field for each segment. Surely this should be easy for `mmap` ;) Maybe we should run profiler ... maybe something silly is happening, like we are randomly seeking on every hit unnecessarily ... This is already understood. The problem is the combination of bad JVM defaults and a problem in bulk copy from off-heap to heap! What you see is garbage collector driving crazy (see my flight control heap dumps). The disabled tiered compilation made hotspot optimizations and escape analysis only kick in after 6 seconds benchmark runtime (of total 60s on my machine). In this time it produced 3 java objects per copy operation (`readBytes(), readLongs(), readFloats()`). With tiered compilation this went down, but still 1 second producing tons of garbage. With JDK 18 this will be solved in https://github.com/openjdk/panama-foreign/pull/555, where we get a new class `MemoryCopy` that allows to copy data off-heap to on-heap without allocating useless wrapper classes. In this pull request this line is producing 3 temporary objects: https://github.com/apache/lucene/blob/bacfa11940ecf505299ec8a2d43a94d64a106182/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L167 ```java MemorySegment.ofArray(b).asSlice(offset, len).copyFrom(curSegment.asSlice(curPosition, len)); ``` From JDK 18 on, it will look like this: ``` MemoryCopy.copyToArray(curSegment, curPosition, b, offset, len); ``` This was negotiated today 👍 In general, we should avoid to copy bytes/longs/floats from mmap to on-heap. With the new vector API coming soon, there's no need for that. Just tell vector API to calculate something (e.g. PFOR or cosine) and give it a MemorySegment slice :-) So we should really really avoid all those stupid copy operations in bulks!!! To read the whole story check here: https://github.com/openjdk/panama-foreign/pull/555#issuecomment-865672909 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
