https://github.com/apache/lucene/pull/12311 Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} apache / lucene Public * Notifications * Fork 728 * Star 1.7k * Code * Issues 2k * Pull requests 126 * Actions * Security * Insights More * Code * Issues * Pull requests * Actions * Security * Insights New issue Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub By clicking "Sign up for GitHub", you agree to our terms of service and privacy statement. We'll occasionally send you account related emails. Already on GitHub? Sign in to your account Jump to bottom Integrate the Incubating Panama Vector API #12311 Merged ChrisHegarty merged 59 commits into apache:main from ChrisHegarty: panama_vector May 25, 2023 Merged Integrate the Incubating Panama Vector API #12311 ChrisHegarty merged 59 commits into apache:main from ChrisHegarty: panama_vector May 25, 2023 +1,025 -179 Conversation 212 Commits 59 Checks 4 Files changed 16 Conversation This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters ChrisHegarty Copy link Contributor @ChrisHegarty ChrisHegarty commented May 18, 2023 * edited Leverage accelerated vector hardware instructions in Vector Search. Lucene already has a mechanism that enables the use of non-final JDK APIs, currently used for the Previewing Pamana Foreign API. This change expands this mechanism to include the Incubating Pamana Vector API. When the jdk.incubator.vector module is present at run time the Panamaized version of the low-level primitives used by Vector Search is enabled. If not present, the default scalar version of these low-level primitives is used (as it was previously). Currently, we're only targeting support for JDK 20. A subsequent PR should evaluate JDK 21, which is still in development. Sorry, something went wrong. 19 benwtrent, Xianzhan, tang-hi, uschindler, jdconrad, dnhatn, jasirkt, msokolov, ChrisHegarty, mayya-sharipova, and 9 more reacted with rocket emoji All reactions * 19 reactions @ChrisHegarty Include the Panama Vector API stubs in the generated 19/20 api jars a02161a @ChrisHegarty ChrisHegarty mentioned this pull request May 18, 2023 vector API integration, plan B #12302 Closed ChrisHegarty added 2 commits May 18, 2023 16:26 @ChrisHegarty first dotProduct implementation aad69f9 @ChrisHegarty fix dimensions check ab6300b rmuir rmuir reviewed May 18, 2023 View reviewed changes Copy link Member @rmuir rmuir left a comment * edited There was a problem hiding this comment. Choose a reason for hiding this comment The reason will be displayed to describe this comment to others. Learn more. [Choose a reason] Hide comment When i looked at this before, this was my impl: https://issues.apache.org/jira/secure/attachment/13022378/ LUCENE-9838_standalone.patch Did a lot of jmh benchmarking at varying vector sizes/hardware to make sure there isn't crazy regressions: here is my benchmark in case it is useful: DotProduct.java.txt basically I can explain a few differences: * lets avoid fma() completely. It can make the whole thing dog slow even in "normal"/"typical" environments. fma is frequently unavailable in production-type environments (e.g. VMS) and openjdk DOES NOT fall back gracefully, it falls back horribly slow. see Ban use of Math.fma across the entire codebase #12014 for more details. And its definitely not good to use fma() in the vector impl but then inconsistently use */+ in the tail. * we have to manually unroll at least a little for performance, java doesnt' do it. I recommend just doing it twice like my patch. edit: attached my old jmh benchmark as a text file here Sorry, something went wrong. 2 ChrisHegarty and uschindler reacted with thumbs up emoji All reactions * 2 reactions @ChrisHegarty merge Robert's dotProduct implementation d49100c @ChrisHegarty Copy link Contributor Author ChrisHegarty commented May 18, 2023 Thanks @rmuir - I just merged in your implementation. I think that it's a much much better starting (if not the final) place. This might be a reasonable minimal point to start from. Before digging too deeply into the performance and optimising the code, I guess I just want to understand if this is the right level to be plugging in at. All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 18, 2023 I'd prefer to have separate apijars, because the current code compiles with patching base module. I'd like to separate this. But as a start it is ok. All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 18, 2023 On the other hand: it just works! All reactions Sorry, something went wrong. uschindler uschindler reviewed May 18, 2023 View reviewed changes gradle/generation/panama-foreign.gradle Outdated Show resolved Hide resolved uschindler uschindler reviewed May 18, 2023 View reviewed changes lucene/core/src/java/org/apache/lucene/util/VectorUtil.java Outdated Show resolved Hide resolved uschindler uschindler reviewed May 18, 2023 View reviewed changes lucene/core/src/java20/org/apache/lucene/util/ JDKVectorUtilProvider.java Outdated Show resolved Hide resolved uschindler uschindler reviewed May 18, 2023 View reviewed changes lucene/core/src/java/org/apache/lucene/util/VectorUtil.java Outdated Show resolved Hide resolved @uschindler Copy link Contributor uschindler commented May 18, 2023 Is vector's FMA also always slow (does it use BigDecimal, too?). All reactions Sorry, something went wrong. ChrisHegarty added 3 commits May 18, 2023 20:41 @ChrisHegarty remove public a714486 @ChrisHegarty remove doPriv and restructure module lookup 39bbc4d @ChrisHegarty remove unnecessary jvmArgs 3edee15 @ChrisHegarty Copy link Contributor Author ChrisHegarty commented May 18, 2023 I'd prefer to have separate apijars, because the current code compiles with patching base module. On the other hand: it just works! Yeah, this is a bit of a hack!. It would be better to separate these out, but then what would we do, still patch it into java.base or build a slim module around it or something? It doesn't feel any better than just patching it all into java.base! 1 uschindler reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @ChrisHegarty Copy link Contributor Author ChrisHegarty commented May 18, 2023 Is vector's FMA also always slow (does it use BigDecimal, too?). I dunno what it does - I haven't looked - but I doubt it falls back to BD. I'll take a look and do some experiments. All reactions Sorry, something went wrong. @ChrisHegarty ChrisHegarty changed the title [DEL:Include the Panama Vector API stubs in the generated 19/20 api jars:DEL] [INS:Integrate the Incubating Panama Vector API :INS] May 18, 2023 @rmuir Copy link Member rmuir commented May 18, 2023 I really wish Math.fma fell back to sane behavior such as */+ and only StrictMath.fma did the slow big decimal stuff! Not good decisionmaking here on these apis. All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 18, 2023 I'd prefer to have separate apijars, because the current code compiles with patching base module. On the other hand: it just works! Yeah, this is a bit of a hack!. It would be better to separate these out, but then what would we do, still patch it into java.base or build a slim module around it or something? It doesn't feel any better than just patching it all into java.base! Let's keep it as is. The whole compile is a hack, modules do not matter. With separate apijar we could also add it to classpath as the package names are not special at all. All reactions Sorry, something went wrong. @ChrisHegarty Move DefaultVectorUtilProvider to it's own top-level class - since it... ... 030babd ... will likely grow over time ChrisHegarty ChrisHegarty commented May 19, 2023 View reviewed changes gradle/testing/defaults-tests.gradle Outdated Show resolved Hide resolved ChrisHegarty added 2 commits May 19, 2023 09:59 @ChrisHegarty refactor the provider and impl into a separate package 927f1c7 @ChrisHegarty move to non-exported internal package 99f7e41 @ChrisHegarty Copy link Contributor Author ChrisHegarty commented May 19, 2023 I refactored the provider and impl's: 1. So as to separate them out from VectorUtil - this should improve readability, etc, as we move beyond dotProduct. 2. I also moved them into a it's own non-exported package. I'm less sure about no.2. The general thought was that the code might be more reusable from there, but now that I think about it, it might be better as package-private where it was, since the "interface" is through VectorUtils - not directly to the imp. Thoughts? All reactions Sorry, something went wrong. @ChrisHegarty disable assertions in jdk.incubator.vector.LaneType 7b58a64 ChrisHegarty ChrisHegarty commented May 19, 2023 View reviewed changes gradle/testing/defaults-tests.gradle Outdated Show resolved Hide resolved @ChrisHegarty revert assertion disablement. Check locale is workable abb5979 187 hidden items Load more... uschindler added 3 commits May 24, 2023 23:17 @uschindler Track references to superclasses and interfaces correctly fe8abaf @uschindler add changes 8a6a33c @uschindler Merge remote-tracking branch 'remotes/origin/main' into panama_vector ... dd4eaac # Conflicts: # lucene/CHANGES.txt @uschindler Copy link Contributor uschindler commented May 24, 2023 Hi, I added spec conformant support for superclasses/interfaces to extractor (recursively collecting classes). I also added a changes.txt and merged main branch. Please have a final look and review. 1 ChrisHegarty reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @uschindler uschindler requested a review from rmuir May 24, 2023 21:55 uschindler uschindler approved these changes May 24, 2023 View reviewed changes @uschindler Copy link Contributor uschindler commented May 24, 2023 @ChrisHegarty Go ahead and merge / backport to 9.x. All reactions Sorry, something went wrong. Hide details View details @ChrisHegarty ChrisHegarty merged commit f756f90 into apache:main May 25, 2023 4 checks passed @ChrisHegarty Copy link Contributor Author ChrisHegarty commented May 25, 2023 Thank you @rmuir and @uschindler, this has been fun! 1 uschindler reacted with thumbs up emoji 1 uschindler reacted with rocket emoji All reactions * 1 reaction * 1 reaction Sorry, something went wrong. asfgit pushed a commit that referenced this pull request May 25, 2023 @uschindler Refactor loop to not addAll set to itsself on initial round (followup... ... cf7245e ... of #12311) @uschindler Copy link Contributor uschindler commented May 25, 2023 Hey yeah was fun. I added one commit, 2 minutes too late. I sent to main branch. Was some change to the recursive extraction loop to not add a set to itsself. 1 ChrisHegarty reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 25, 2023 If you cherry pick, take both commits. I will now update the Java 21 branch for mmap. 1 ChrisHegarty reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 25, 2023 Merge for PR #12294 was quite simple, it was done mostly automatic. I only had to add the new version number to extractor. I did not add the vector code yet; we can do it in this PR or separately (just some coordination needed). If there are no code changes for the vector code needed in 21, I will copy over the 20 classes to the 21 folder. 1 ChrisHegarty reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. ChrisHegarty added a commit to ChrisHegarty/lucene that referenced this pull request May 25, 2023 @ChrisHegarty @uschindler @rmuir Integrate the Incubating Panama Vector API (apache#12311) ... 2362165 Leverage accelerated vector hardware instructions in Vector Search. Lucene already has a mechanism that enables the use of non-final JDK APIs, currently used for the Previewing Pamana Foreign API. This change expands this mechanism to include the Incubating Pamana Vector API. When the jdk.incubator.vector module is present at run time the Panamaized version of the low-level primitives used by Vector Search is enabled. If not present, the default scalar version of these low-level primitives is used (as it was previously). Currently, we're only targeting support for JDK 20. A subsequent PR should evaluate JDK 21. --------- Co-authored-by: Uwe Schindler Co-authored-by: Robert Muir ChrisHegarty pushed a commit to ChrisHegarty/lucene that referenced this pull request May 25, 2023 @uschindler @ChrisHegarty Refactor loop to not addAll set to itsself on initial round (followup... ... 35bd37d ... of apache#12311) @ChrisHegarty ChrisHegarty mentioned this pull request May 25, 2023 [Backport] Integrate the Incubating Panama Vector API #12311 #12327 Merged @mikemccand Copy link Member mikemccand commented May 25, 2023 Hmm should we add the generated Panama code to .gitignore? My ./ gradlew precommit is failing with: * What went wrong: Execution failed for task ':checkWorkingCopyClean'. > Working copy is not a clean git checkout (skip with -Pvalidation.git.failOnModified=false), offending files: - gradle/generation/panama-foreign (untracked non-empty dir) - gradle/generation/panama-foreign/ExtractForeignAPI.java (untracked) All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 25, 2023 @mikemccand: This file is a relic in your checkout. Just clean your working copy. The file/folder was deleted by refactoring the build system to support mmap and vectors at same time (files/dirs renamed). All reactions Sorry, something went wrong. ChrisHegarty added a commit that referenced this pull request May 25, 2023 @ChrisHegarty @uschindler @rmuir [Backport] Integrate the Incubating Panama Vector API #12311 (#12327) ... 0b53670 Leverage accelerated vector hardware instructions in Vector Search. Lucene already has a mechanism that enables the use of non-final JDK APIs, currently used for the Previewing Pamana Foreign API. This change expands this mechanism to include the Incubating Pamana Vector API. When the jdk.incubator.vector module is present at run time the Panamaized version of the low-level primitives used by Vector Search is enabled. If not present, the default scalar version of these low-level primitives is used (as it was previously). Currently, we're only targeting support for JDK 20. A subsequent PR should evaluate JDK 21. --------- Co-authored-by: Uwe Schindler Co-authored-by: Robert Muir @msokolov Copy link Contributor msokolov commented May 25, 2023 I'm seeing very strange results after testing with 768-dim vectors. TaskQPS baseline StdDevQPS candidate StdDev Pct diff p-value HighTermVector 139.27 (6.7%) 57.21 (0.8%) -58.9% ( -62% - -55%) 0.000 AndHighHighVector 139.15 (6.4%) 57.15 (0.7%) -58.9% ( -62% - -55%) 0.000 LowTermVector 138.54 (6.2%) 57.00 (0.8%) -58.9% ( -62% - -55%) 0.000 MedTermVector 138.67 (6.9%) 57.23 (0.9%) -58.7% ( -62% - -54%) 0.000 AndHighMedVector 137.95 (6.1%) 57.10 (0.8%) -58.6% ( -61% - -55%) 0.000 AndHighLowVector 137.86 (6.4%) 57.21 (0.8%) -58.5% ( -61% - -54%) 0.000 PKLookup 199.30 (2.3%) 198.44 (2.5%) -0.4% ( -5% - 4%) 0.565 I have double-checked that candidate has 609fc9b and baseline is c9c49bc. Both conditions are run using the same index, tasks, etc. The JFR output is sort of a head-scratcher too. They clearly show that the JDK vector API is being called (I think?) but also show a lot of noisy things (Objects.requireNonNull). Is jdk.incubator.vector.FloatVector#reduceLanesTemplate() really what we want to see there? Another mystery is why org.apache.lucene.util.hnsw.HnswGraphSearcher#searchLevel() would have more samples in the candidate given that it has nothing to do with the vector api. In looking at these you should ignore things related to VectorDictionary - these are loading a word->vector dictionary that is used to look up query vectors; the loading takes a while but happens prior to the index being opened and the queries being executed. candidate PERCENT CPU SAMPLES STACK 9.00% 2721 jdk.incubator.vector.FloatVector#reduceLanesTemplate() 5.44% 1645 org.apache.lucene.util.hnsw.HnswGraphSearcher#searchLevel() 3.89% 1177 org.apache.lucene.util.packed.DirectReader$DirectPackedReader12#get() 3.03% 917 org.apache.lucene.util.packed.DirectReader$DirectPackedReader16#get() 2.99% 904 java.lang.invoke.VarHandleGuards#guard_LJ_I() 2.70% 816 jdk.internal.misc.Unsafe#copyMemoryChecks() 2.52% 761 perf.VectorDictionary#vectorDiv() 2.45% 741 org.apache.lucene.store.DataInput#readVInt() 2.43% 734 org.apache.lucene.util.packed.DirectMonotonicReader#get() 2.17% 655 java.util.Objects#requireNonNull() 1.92% 580 jdk.jfr.internal.JVM#emitEvent() 1.70% 513 java.util.Arrays#binarySearch0() 1.40% 423 org.apache.lucene.codecs.lucene95.Lucene95HnswVectorsReader$OffHeapHnswGraph#seek() 1.35% 407 java.util.HashMap#resize() 1.29% 391 org.apache.lucene.codecs.lucene95.OffHeapFloatVectorValues#vectorValue() 1.29% 389 sun.nio.ch.UnixFileDispatcherImpl#unmap0() 1.27% 385 org.apache.lucene.util.VectorUtilPanamaProvider#dotProduct() 1.26% 380 jdk.internal.foreign.AbstractMemorySegmentImpl#checkBounds() 1.23% 373 org.apache.lucene.util.LongHeap#downHeap() 1.22% 370 jdk.incubator.vector.FloatVector#fromArray0Template() 1.19% 361 java.util.zip.Inflater#inflateBytesBytes() 1.15% 348 org.apache.lucene.util.hnsw.NeighborQueue#decodeScore() 1.13% 341 org.apache.lucene.util.SparseFixedBitSet#getAndSet() 1.12% 338 org.apache.lucene.util.SparseFixedBitSet#insertLong() 1.02% 308 jdk.internal.misc.Unsafe#copyMemory() 0.96% 289 jdk.internal.foreign.AbstractMemorySegmentImpl#copy() 0.95% 286 perf.VectorDictionary#() 0.94% 283 java.util.Objects#checkIndex() 0.88% 267 jdk.internal.foreign.AbstractMemorySegmentImpl#getBaseAndScale() 0.85% 257 org.apache.lucene.store.MemorySegmentIndexInput#readByte() baseline PERCENT CPU SAMPLES STACK 24.69% 7386 perf.VectorDictionary#vectorDiv() 20.49% 6127 org.apache.lucene.util.VectorUtil#dotProduct() 3.42% 1022 java.nio.FloatBuffer#getArray() 2.65% 792 org.apache.lucene.util.hnsw.HnswGraphSearcher#searchLevel() 2.50% 748 perf.VectorDictionary#() 2.34% 699 jdk.internal.misc.Unsafe#checkPrimitivePointer() 1.95% 583 jdk.jfr.internal.JVM#emitEvent() 1.62% 485 java.util.HashMap#getNode() 1.61% 481 org.apache.lucene.util.SparseFixedBitSet#insertLong() 1.50% 450 java.nio.Buffer#position() 1.32% 395 java.util.HashMap#resize() 1.03% 309 java.io.BufferedReader#readLine() 0.98% 292 jdk.internal.misc.Unsafe#checkOffset() 0.91% 272 perf.PKLookupTask#go() 0.90% 270 java.util.zip.Inflater#inflateBytesBytes() 0.85% 253 java.util.HashMap#containsKey() 0.79% 236 org.apache.lucene.util.LongHeap#downHeap() 0.67% 200 org.apache.lucene.codecs.lucene90.blocktree.SegmentTermsEnum#seekExact() 0.65% 194 sun.nio.ch.FileChannelImpl#unmap0() 0.57% 170 org.apache.lucene.util.SparseFixedBitSet#getAndSet() 0.53% 159 jdk.internal.util.ArraysSupport#mismatch() 0.51% 154 org.apache.lucene.util.hnsw.HnswGraphSearcher#graphNextNeighbor() 0.48% 145 sun.nio.cs.UTF_8$Decoder#decodeArrayLoop() 0.48% 143 java.io.FileOutputStream#writeBytes() 0.46% 137 org.apache.lucene.store.ByteBufferGuard#getByte() 0.44% 131 org.apache.lucene.codecs.lucene95.Lucene95HnswVectorsReader$OffHeapHnswGraph#seek() 0.41% 123 java.nio.Buffer#checkIndex() 0.40% 120 org.apache.lucene.store.DataInput#readVInt() 0.38% 113 perf.VectorDictionary#vectorNorm() 0.35% 104 org.apache.lucene.util.LongHeap#upHeap() All reactions Sorry, something went wrong. @msokolov Copy link Contributor msokolov commented May 25, 2023 just some extra data about theg above testing: I was using jdk20 for the candidate and jdk17 for the baseline (by accident I guess). Both were using --add-modules jdk.incubator.vector. The machine I ran on is an Intel with avx2 sse4_1 sse4_2 and lots of other flags - I can post if someone thinks it might matter All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 25, 2023 Are you sure you run with default JVM options like tiered compilation and not xbatch? Are tests running long enough, each run at least a minute? All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 25, 2023 * edited Was this some kind of VM? Anyways for larger vectors it should run for longer time to get enough optimization rounds. The problem with the vector API is that it needs much longer to get "warm". If you measure only a few seconds on each JVM it just measures the warmup... All reactions Sorry, something went wrong. @msokolov Copy link Contributor msokolov commented May 25, 2023 * edited that's a helpful insight, yes I think we're really only doing a fairly quick run each time through - a handful of seconds. I'll try increasing that -- um no not a VM. No docker or anything like that. All reactions Sorry, something went wrong. @ChrisHegarty ChrisHegarty mentioned this pull request May 26, 2023 Leverage accelerated vector hardware instructions in Vector Search elastic/elasticsearch#96370 Open 8 tasks @alessandrobenedetti Copy link Contributor alessandrobenedetti commented May 26, 2023 * edited Just out of curiosity, are we ok with this sort of class in Lucene? (minimal variable names, many ad hoc if-else etc) Are some of them auto-generated? (for example lucene/core/src/java20/ org/apache/lucene/util/VectorUtilPanamaProvider.java) What's the standard approach in these scenarios? Not a polemic, I am genuinely curious because they seem far from being maintainable but I guess they are useful as they bring low level implementations goodies? Pardon me if it's a silly question, I tend to be overly concerned about not-readable code, but to be fair I didn't spend much time on it so an honest answer could be "it's already as readable as it could be :) " All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 26, 2023 * edited Hi @alessandrobenedetti, the code shown here is indeed crazy to read, but this is more a problem of the APIs in general. The Java Vector API is very low level and you have to exactly know how lanes, species and so on work. The code written by Robert is 100% according to the javadocs guidelines. There's also a lot of other low level code (codecs like BlockTermsReader) in Lucene, so it is not new. Also MMapDirectory indexinput look like that. They are not beatiful but optimized for performance. To me the variable names are perfectly fine vor vector code (ab, a1b,...). This is typical in that area. It won't get better with other names. The code on official JDK docs looks identical: https:// docs.oracle.com/en/java/javase/20/docs/api/jdk.incubator.vector/jdk/ incubator/vector/package-summary.html The arbitrary if/else constructs are a problem of underlying hardware infratstructure. It is NOT autogenerated, but follows low-level hardware specs, so there are arbitrary looking constants and if/else in it. This can be improved by moving numbers like 128 as constants, be free to make PRs! For performance reasons you should NOT split that up into too many different methods, as the code relies on escape analysis of the VM. We may split it later, but that's more a cleanup approach. An additional problem in the whole code is that it is Java version specific, so there will me multiple versions of the same code staying in different directories (java20, java21,...). Same for MMapDirectory. The extraction code for the Java APIs is special and a hack, but it is not part of Lucene's public library; it is a build tool only. Sorry for it, there's a new version now because a rewrite was needed to allow backporting and fix incomplete extraction: #12329 (this version looks much better, also technically bettrer organized). All reactions Sorry, something went wrong. @msokolov Copy link Contributor msokolov commented May 26, 2023 hm I looked more closely at the test I ran and it seems I managed to create a file full of identical vectors -- so this is going to lead to crazy results. WIll follow up once I've managed to fix the vector creation All reactions Sorry, something went wrong. @uschindler Copy link Contributor uschindler commented May 26, 2023 * edited Hi, I changed the CHANGES.txt entry in main and 9.x to correctly refer to ARM's chipset feature (NEON). @rmuir asked me to correct it. See: https://en.wikipedia.org/wiki/ARM_architecture_family# Advanced_SIMD_(Neon) All reactions Sorry, something went wrong. @alessandrobenedetti Copy link Contributor alessandrobenedetti commented May 26, 2023 thanks @uschindler for the explanation, I appreciate the work you are doing! 1 uschindler reacted with thumbs up emoji All reactions * 1 reaction Sorry, something went wrong. Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Reviewers @uschindler uschindler uschindler approved these changes @rmuir rmuir Assignees No one assigned Labels type:enhancement Projects None yet Milestone 9.7.0 Development Successfully merging this pull request may close these issues. vector API integration, plan B 7 participants @ChrisHegarty @uschindler @rmuir @msokolov @mikemccand @HoustonPutman @alessandrobenedetti Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.