Hello, > We run distributed SPARQL on GPUs using physical operators designed for > sparse vectors and sparse matrices and using communication patterns that > are optimized for the graph and the hardware. To get the full benefit of > acceleration, we need to be able to translate into our physical operators > model against our runtime data structures. How would that work for TP3? > Or is the requirement to target the Gremlin abstract machine?
The Gremlin VM is distributed in the sense that a group of Gremlin VMs communicate with one another via the Bulk Synchronous Parallel model of distributed graph computing (popularized by Google Pregel/Apache Giraph). Thus, if each core in your GPU is an independent Gremlin VM, they they will communicate and execute the computation. Note that Gremlin VM "workers" can be individual machines or threads so it will work on a multi-core system and in fact, that is exactly how TinkerGraph OLAP works -- it distributes Gremlin VMs across all available cores and executes Gremlin instructions (i.e. queries). Finally, note that the Gremlin VM is not as beefy as the JVM so its not expensive to have many of them running. Marko http://markorodriguez.com > > Thanks, > Bryan > > ---- > Bryan Thompson > Chief Scientist & Founder > SYSTAP, LLC > 4501 Tower Road > Greensboro, NC 27410 > [email protected] > http://blazegraph.com > http://blog.blazegraph.com > > Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance > graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints > APIs. Blazegraph is now available with GPU acceleration using our disruptive > technology to accelerate data-parallel graph analytics and graph query. > > CONFIDENTIALITY NOTICE: This email and its contents and attachments are > for the sole use of the intended recipient(s) and are confidential or > proprietary to SYSTAP. Any unauthorized review, use, disclosure, > dissemination or copying of this email or its contents or attachments is > prohibited. If you have received this communication in error, please notify > the sender by reply email and permanently delete all copies of the email > and its contents and attachments. > > On Fri, Oct 30, 2015 at 10:55 AM, Mike Personick <[email protected]> wrote: > >>>> http://tinkerpop.incubator.apache.org/docs/3.0.2-incubating/#match-step >> >> Very cool! >> >> I assume there is some way to provide a vendor-specific implementation for >> MatchStep? >> >> >> >> On Fri, Oct 30, 2015 at 7:35 AM, Marko Rodriguez <[email protected]> >> wrote: >> >>> Hello, >>> >>> *** Just want to work to dispel the "Gremlin isn't declarative"-myth that >>> doesn't seem to die :). >>> >>>> My 2 cents - Tinkerpop is a great API that makes graph application >>>> development much easier, but the lack of a declarative query language >>> is a >>>> barrier to making those applications scale. I strongly prefer to >>> develop >>>> application code using Tinkerpop over raw RDF or Sesame, but once the >>> data >>>> is there I prefer to access and update it via SPARQL. >>> >>> Gremlin3 support declarative pattern matching much like SPARQL. In fact, >>> internal benchmarks have shown that Gremlin3's query optimizer is equal or >>> more efficient than some vendors native declarative query language. >>> >>> http://tinkerpop.incubator.apache.org/docs/3.0.2-incubating/#match-step >>> Moreover, realize that these same queries compile to work over any OLAP >>> graph processor such as Apache Giraph or Spark. Thus, you can do >>> declarative pattern matching over an arbitrarily large cluster. >>> >>> http://www.slideshare.net/slidarko/acm-dbpl-keynote-the-graph-traversal-machine-and-language/131 >>> Finally, scroll through to slide 136. The Gremlin virtual machines is a >>> distributed virtual machine and any language that compiles to Gremlin's >>> instruction set automatically executes on the cluster. E.g., compile SPARQL >>> to Gremlin's instruction set and TADA! Distributed SPARQL. >>> >>> Thanks, >>> Marko. >>> >>> http://markorodriguez.com >> >> >>
