Domshark

domshark

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Oded Blumenthal, Software and Information Systems Engineering, Ben Gurion University, Israel;
(2) Guy Shani, Software and Information Systems Engineering, Ben Gurion University, Israel. Table of Links Introduction
Background
Related Work
POMCP for Stochastic Contingent Planning
Domain Independent Heuristics for POMCP
Empirical Evaluation
Conclusion and References 7 Conclusion In this paper we suggested to model goal POMDPs as stochastic contingent planning models, which allows us to use domain independent heuristics developed in the automated planning community to estimate the utility of belief states. We implemented our domain independent heuristics into the rollout mechanism of POMCP — a well known online POMDP planner that constructs a search tree to evaluate which action to take next. We provide an empirical evaluation showing how heuristics provide much leverage, especially in complex domains that require a long planning horizon, compared to the standard uniform rollout policy that is often used in POMCP. For future research we intend to integrate our methods into other solvers, such as RTDP-BEL, or into point-based planners as a method to gather good belief points. We can also experiment with additional heuristics, other than the hadd heuristic used in this paper. References [1] Alexandre Albore, Héctor Palacios & Hector Geffner (2009): A Translation-Based Approach to Contingent Planning. In: IJCAI, 9, pp. 1623–1628, doi:10.5555/1661445.1661706. Available at https://dl.acm. org/doi/10.5555/1661445.1661706. [2] Blai Bonet & Héctor Geffner (2001): Planning as heuristic search. Artificial Intelligence 129(1-2), pp. 5–33, doi:10.1016/S0004-3702(01)00108-4. [3] Blai Bonet & Hector Geffner (2009): Solving POMDPs: RTDP-Bel vs. Point-based Algorithms. In Craig Boutilier, editor: IJCAI 2009, Proceedings of the 21st International Joint Conference on Artificial Intelligence, Pasadena, California, USA, July 11-17, 2009, pp. 1641–1646, doi:10.5555/1661445.1661709. Available at https://dl.acm.org/doi/10.5555/1661445.1661709. [4] Blai Bonet & Hector Geffner (2011): Planning under Partial Observability by Classical Replanning: Theory and Experiments. In: IJCAI 2011, Proceedings of the 22nd International Joint Conference on Artificial Intelligence, Barcelona, Catalonia, Spain, July 16-22, 2011, pp. 1936–1941, doi:10.5591/978-1-57735-516-8/IJCAI11-324. [5] Ronen I Brafman & Guy Shani (2016): Online belief tracking using regression for contingent planning. Artificial Intelligence 241, pp. 131–152, doi:10.1016/j.artint.2016.08.005. [6] Hector Geffner & Blai Bonet (2022): A concise introduction to models and methods for automated planning. Springer Nature. [7] Malte Helmert & Carmel Domshlak (2009): Landmarks, Critical Paths and Abstractions: What’s the Difference Anyway? In Lubos Brim, Stefan Edelkamp, Eric A. Hansen & Peter Sanders, editors: Graph Search Engineering, 29.11. - 04.12.2009, Dagstuhl Seminar Proceedings 09491, Schloss Dagstuhl -LeibnizZentrum für Informatik, Germany, doi:10.1609/icaps.v19i1.13370. Available at http://drops.dagstuhl. de/opus/volltexte/2010/2432/. [8] Malte Helmert, Patrik Haslum, Jörg Hoffmann & Raz Nissim (2014): Merge-and-shrink abstraction: A method for generating lower bounds in factored state spaces. Journal of the ACM (JACM) 61(3), pp. 1–63, doi:10.1145/2559951. [25] Guy Shani, Joelle Pineau & Robert Kaplow (2013): A survey of point-based POMDP solvers. Autonomous Agents and Multi-Agent Systems 27, pp. 1–51, doi:10.1007/s10458-012-9200-2. [26] William Shen, Felipe Trevizan, Sam Toyer, Sylvie Thiébaux & Lexing Xie (2019): Guiding search with generalized policies for probabilistic planning. In: Proceedings of the International Symposium on Combinatorial Search, 10, pp. 97–105, doi:10.1609/socs.v10i1.18507. [27] David Silver & Joel Veness (2010): Monte-Carlo planning in large POMDPs. Advances in neural information processing systems 23, doi:10.5555/2997046.2997137. [28] Richard D Smallwood & Edward J Sondik (1973): The optimal control of partially observable Markov processes over a finite horizon. Operations research 21(5), pp. 1071–1088, doi:10.1287/opre.21.5.1071. [29] Adhiraj Somani, Nan Ye, David Hsu & Wee Sun Lee (2013): DESPOT: Online POMDP planning with regularization. Advances in neural information processing systems 26, doi:10.1613/jair.5328. [30] Zachary Sunberg & Mykel Kochenderfer (2018): Online algorithms for POMDPs with continuous state, action, and observation spaces. In: Proceedings of the International Conference on Automated Planning and Scheduling, 28, pp. 259–263, doi:10.48550/arXiv.1709.06196. [31] Yuchen Xiao, Sammie Katt, Andreas ten Pas, Shengjian Chen & Christopher Amato (2019): Online planning for target object search in clutter under partial observability. In: 2019 International Conference on Robotics and Automation (ICRA), IEEE, pp. 8241–8247, doi:10.1109/ICRA.2019.8793494. [32] Nan Ye, Adhiraj Somani, David Hsu & Wee Sun Lee (2017): DESPOT: Online POMDP planning with regularization. Journal of Artificial Intelligence Research 58, pp. 231–266, doi:10.1613/jair.5328. This paper is available on arxiv under CC 4.0 license. Authors: (1) Oded Blumenthal, Software and Information Systems Engineering, Ben Gurion University, Israel; (2) Guy Shani, Software and Information Systems Engineering, Ben Gurion University, Israel. This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Oded Blumenthal, Software and Information Systems Engineering, Ben Gurion University, Israel; (2) Guy Shani, Software and Information Systems Engineering, Ben Gurion University, Israel. Table of Links Introduction Background Related Work POMCP for Stochastic Contingent Planning Domain Independent Heuristics for POMCP Empirical Evaluation Conclusion and References Introduction Introduction Background Background Related Work Related Work POMCP for Stochastic Contingent Planning POMCP for Stochastic Contingent Planning Domain Independent Heuristics for POMCP Domain Independent Heuristics for POMCP Empirical Evaluation Empirical Evaluation Conclusion and References Conclusion and References 7 Conclusion In this paper we suggested to model goal POMDPs as stochastic contingent planning models, which allows us to use domain independent heuristics developed in the automated planning community to estimate the utility of belief states. We implemented our domain independent heuristics into the rollout mechanism of POMCP — a well known online POMDP planner that constructs a search tree to evaluate which action to take next. We provide an empirical evaluation showing how heuristics provide much leverage, especially in complex domains that require a long planning horizon, compared to the standard uniform rollout policy that is often used in POMCP. For future research we intend to integrate our methods into other solvers, such as RTDP-BEL, or into point-based planners as a method to gather good belief points. We can also experiment with additional heuristics, other than the h add heuristic used in this paper. add References [1] Alexandre Albore, Héctor Palacios & Hector Geffner (2009): A Translation-Based Approach to Contingent Planning. In: IJCAI, 9, pp. 1623–1628, doi:10.5555/1661445.1661706. Available at https://dl.acm. org/doi/10.5555/1661445.1661706. [2] Blai Bonet & Héctor Geffner (2001): Planning as heuristic search. Artificial Intelligence 129(1-2), pp. 5–33, doi:10.1016/S0004-3702(01)00108-4. [3] Blai Bonet & Hector Geffner (2009): Solving POMDPs: RTDP-Bel vs. Point-based Algorithms. In Craig Boutilier, editor: IJCAI 2009, Proceedings of the 21st International Joint Conference on Artificial Intelligence, Pasadena, California, USA, July 11-17, 2009, pp. 1641–1646, doi:10.5555/1661445.1661709. Available at https://dl.acm.org/doi/10.5555/1661445.1661709. [4] Blai Bonet & Hector Geffner (2011): Planning under Partial Observability by Classical Replanning: Theory and Experiments. In: IJCAI 2011, Proceedings of the 22nd International Joint Conference on Artificial Intelligence, Barcelona, Catalonia, Spain, July 16-22, 2011, pp. 1936–1941, doi:10.5591/978-1-57735-516-8/IJCAI11-324. [5] Ronen I Brafman & Guy Shani (2016): Online belief tracking using regression for contingent planning. Artificial Intelligence 241, pp. 131–152, doi:10.1016/j.artint.2016.08.005. [6] Hector Geffner & Blai Bonet (2022): A concise introduction to models and methods for automated planning. Springer Nature. [7] Malte Helmert & Carmel Domshlak (2009): Landmarks, Critical Paths and Abstractions: What’s the Difference Anyway? In Lubos Brim, Stefan Edelkamp, Eric A. Hansen & Peter Sanders, editors: Graph Search Engineering, 29.11. - 04.12.2009, Dagstuhl Seminar Proceedings 09491, Schloss Dagstuhl -LeibnizZentrum für Informatik, Germany, doi:10.1609/icaps.v19i1.13370. Available at http://drops.dagstuhl. de/opus/volltexte/2010/2432/. [8] Malte Helmert, Patrik Haslum, Jörg Hoffmann & Raz Nissim (2014): Merge-and-shrink abstraction: A method for generating lower bounds in factored state spaces. Journal of the ACM (JACM) 61(3), pp. 1–63, doi:10.1145/2559951. [25] Guy Shani, Joelle Pineau & Robert Kaplow (2013): A survey of point-based POMDP solvers. Autonomous Agents and Multi-Agent Systems 27, pp. 1–51, doi:10.1007/s10458-012-9200-2. [26] William Shen, Felipe Trevizan, Sam Toyer, Sylvie Thiébaux & Lexing Xie (2019): Guiding search with generalized policies for probabilistic planning. In: Proceedings of the International Symposium on Combinatorial Search, 10, pp. 97–105, doi:10.1609/socs.v10i1.18507. [27] David Silver & Joel Veness (2010): Monte-Carlo planning in large POMDPs. Advances in neural information processing systems 23, doi:10.5555/2997046.2997137. [28] Richard D Smallwood & Edward J Sondik (1973): The optimal control of partially observable Markov processes over a finite horizon. Operations research 21(5), pp. 1071–1088, doi:10.1287/opre.21.5.1071. [29] Adhiraj Somani, Nan Ye, David Hsu & Wee Sun Lee (2013): DESPOT: Online POMDP planning with regularization. Advances in neural information processing systems 26, doi:10.1613/jair.5328. [30] Zachary Sunberg & Mykel Kochenderfer (2018): Online algorithms for POMDPs with continuous state, action, and observation spaces. In: Proceedings of the International Conference on Automated Planning and Scheduling, 28, pp. 259–263, doi:10.48550/arXiv.1709.06196. [31] Yuchen Xiao, Sammie Katt, Andreas ten Pas, Shengjian Chen & Christopher Amato (2019): Online planning for target object search in clutter under partial observability. In: 2019 International Conference on Robotics and Automation (ICRA), IEEE, pp. 8241–8247, doi:10.1109/ICRA.2019.8793494. [32] Nan Ye, Adhiraj Somani, David Hsu & Wee Sun Lee (2017): DESPOT: Online POMDP planning with regularization. Journal of Artificial Intelligence Research 58, pp. 231–266, doi:10.1613/jair.5328.

Rollout Heuristics for Online Stochastic Contingent Planning: Conclusion and References

I explained the concepts and theory behind Data Residency in a . It's time to get our hands dirty and implement it in a simple demo. previous post The sample architecture In the last section of the previous post, I proposed a sample architecture where location-based routing happened at two different stages: The API Gateway checks for an existing header. Depending on its value, it forwards the request to the computed upstream; If no value is found or no value matches, it forwards it to a default upstream. X-Country The application uses to route again depending on the data. If the value computed by the API Gateway is correct, the flow stays "in its lane"; if not, it's routed to the correct database, but with a performance penalty as it's outside its lane. Apache Shardingsphre I simplified some aspects: The theory uses two API Gateway instances. For the demo, I used only one. Remember that the location isn't set client-side on the first request. It should be returned along the first response, stored, and reused by the client on subsequent calls. I didn't bother with implementing the client. I like my demos to be self-contained, so I didn't use any Cloud Provider. Here's the final component diagram: The data model is simple: We insert location-specific data on each database: INSERT INTO europe.owner VALUES ('dujardin', 'fr', 'Jean Dujardin');
INSERT INTO europe.thingy VALUES (1, 'Croissant', 'dujardin');

INSERT INTO usa.owner VALUES ('wayne', 'us', 'John Wayne');
INSERT INTO usa.thingy VALUES (2, 'Lasso', 'wayne'); Finally, we develop a straightforward RESTful API to fetch thingies: GET /thingies/ GET /thingies/{id} Now that we have set the stage, let's see how we can implement routing at the two levels. Routing on Apache ShardingSphere Apache ShardingSphere offers two approaches: as a library inside the application, ShardingSphere-JDBC, or as a full-fledged deployable component, ShardingSphere-Proxy. You can also combine both. I chose the former because it's the easiest to set up. For a comparison between them, please check . this table The first step is to add the dependency to the POM: <dependency>
	<groupId>org.apache.shardingsphere</groupId>
	<artifactId>shardingsphere-jdbc-core</artifactId>
	<version>5.3.2</version>
</dependency> ShardingSphere-JDBC acts as an indirect layer between the application and the data sources. We must configure the framework to use it. For Spring Boot, it looks like the following: spring:
  datasource:
    driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver     #1
    url: jdbc:shardingsphere:absolutepath:/etc/sharding.yml                      #2-3 JDBC-compatible ShardingSphere driver Configuration file Opposite to what the documentation tells, the full prefix is . I've opened a to fix the documentation. jdbc:shardingsphere:absolutepath PR The next step is to configure ShardingSphere itself with the data sources: dataSources:                                                                  #1
  europe:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: org.postgresql.Driver
    jdbcUrl: "jdbc:postgresql://dbeurope:5432/postgres?currentSchema=europe"
    username: postgres
    password: root
  usa:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: org.postgresql.Driver
    jdbcUrl: "jdbc:postgresql://dbusa:5432/postgres?currentSchema=usa"
    username: postgres
    password: root
rules:                                                                       #2
  - !SHARDING
    tables:
      owner:                                                                 #3
        actualDataNodes: europe.owner,usa.owner                              #4
        tableStrategy:
          standard:
            shardingColumn: country                                          #3
            shardingAlgorithmName: by_country                                #5
    shardingAlgorithms:
      by_country:
        type: CLASS_BASED                                                    #6
        props:
          strategy: STANDARD
          algorithmClassName: ch.frankel.blog.dataresidency.LocationBasedSharding #7 Define the two data sources, and europe usa Define rules. Many rules are available; we will only use sharding to split data between Europe and USA locations Sharding happens on the column of the table country owner Actual shards Algorithm to use. ShardingSphere offers a couple of algorithms out-of-the-box, which generally try to balance data equally between the sources.
As we want a particular split, we define our own Set the algorithm type Reference the custom algorithm class The final step is to provide the algorithm's code: class LocationBasedSharding : StandardShardingAlgorithm<String> {    //1

  override fun doSharding(targetNames: MutableCollection<String>, shardingValue: PreciseShardingValue<String>) =
    when (shardingValue.value) {                                     //2
      "fr" -> "europe"
      "us" -> "usa"
      else -> throw IllegalArgumentException("No sharding over ${shardingValue.value} defined")
    }
} Inherit from , where is the data type of the sharding column. Here, it's StandardShardingAlgorithm<T> T country Based on the sharding column's value, return the name of the data source to use With all of the above, the application will fetch thingies in the relevant data source based on the owner's country. Routing on Apache APISIX We should route as early as possible to avoid an application instance in Europe fetching US data. In our case, it translates to routing at the API Gateway stage. I'll use APISIX for configuration. standalone mode Let's define the two upstreams: upstreams:
  - id: 1
    nodes:
      "appeurope:8080": 1
  - id: 2
    nodes:
      "appusa:8080": 1 Now, we shall define the routes where the magic happens: routes:
  - uri: /thingies*                          #1
    name: Europe
    upstream_id: 1
    vars: [["http_x-country", "==", "fr"]]   #2
    priority: 3                              #3
  - uri: /thingies*                          #4
    name: USA
    upstream_id: 2
    vars: [["http_x-country", "==", "us"]]
    priority: 2                              #3
  - uri: /thingies*                          #5
    name: default
    upstream_id: 1
    priority: 1                              #3 Define the route to the Europe-located app APISIX matches the HTTP methods, the URI conditions. Here, the condition is that the header has the value and X-Country fr APISIX evaluates matching in priority order, starting with the highest priority. If the request doesn't match, , because the header doesn't have the set value, it evaluates the next route in the priority list. e.g. Define the route to the USA-located app Define a default route The first request carries no header; APISIX forwards it to the default route, where ShardingSphere finds data in the relevant data source. Subsequent requests set the header because the response to the first request carries the information, and the client has stored it. Remember that it's outside the scope of the demo. In most cases, it's set to the correct location; hence, the request will stay "in its lane". If not, the configured routing will still find the data in the appropriate location at the cost of increased latency to fetch data in the other lane. X-Country Observing the flow in practice It's always a good idea to check that the design behaves as expected. We can use OpenTelemetry for this. For more information on how to set up OpenTelemetry in such an architecture, please refer to . End-to-end tracing with OpenTelemetry Note that Apache ShardingSphere supports OpenTelemetry but doesn't provide the binary agent. You need to build it from source. I admit I was too lazy to do it. Let's start with a headerless request: curl localhost:9080/thingies/1 It uses the default route defined in APISIX and returns the correct data, thanks to ShardingSphere. Now, let's set the country to , which is correct. fr curl -H 'X-Country: fr' localhost:9080/thingies/1 APISIX correctly forwards the request to the Europe-located app. Finally, imagine a malicious actor changing the header to get their hands on data that are located in the US. curl -H 'X-Country: us' localhost:9080/thingies/1 APISIX forwards it to the USA-located app according to the header. However, Shardingsphere still fetches data from Europe. Conclusion In the I explained the concepts behind Data Residency. In this post, I implemented it within a simple architecture, thanks to Apache APISIX and Apache ShardingSphere. The demo simplifies reality but should be an excellent foundation for building your production-grade Data Residency architecture. previous post, The complete source code for this post can be found on . GitHub Originally published at A Java Geek The featured image for this article was generated with Kadinsky 2. Prompt: Data warehouse.

How to Manage Data Residency

Node is lightweight & scalable, allows us to develop quickly, and npm has incredible packages. The founding team at HarperDB built the first and only database written in Node.js. A little while back, our CEO Stephen Goldberg was invited to to share the story of this endeavor. Stephen discussed the architectural layers of the database, demonstrated how to build a highly scalable and distributed product in Node.js, and demoed the inner workings of HarperDB. You can watch his talk at the link above, and even read a , but since we all love Node.js and it’s an interesting topic, I’ll summarize here. speak at a Women Who Code meetup (what some called crazy) post from back in 2017 The main (and simplest) reason we chose to build a database in Node is because we knew it really well. We got flak for not choosing Go, but people now accept that Go and Node are essentially head to head ( ). Zach, one of our cofounders, recognized that with the time it would have taken to learn a new language, it would never be worth it. in popularity & community support Pros of building a Database in Node.js We already knew Node.js Lightweight Rapid development Highly scalable npm The HarperDB team has a background in large scale software development. The initial goal of our database was to create a tool that empowers developers to focus on coding, without having to devote time and effort to database maintenance, while still providing a powerful solution. We wanted people to feel comfortable and confident in the product they were using. Our team has extensive experience in languages other than Node, but we had great success programming in it. (Although coming from Java, Stephen thought Node was horrible at first, but after about 90 days he learned to love it). Node is lightweight, allows us to develop quickly, and npm has incredible packages. Cons of building a Database in Node.js At the time was not accepted as an “enterprise grade language” Does not have direct control of Operating System/File System Not as performant as C/C++ (sometimes) Did not have native threading (now it does) We did have some troubles... being the first database written in Node.js we didn’t have the option to follow in anyone’s footsteps. We’re probably one of the first enterprise products ever built in Node, at least the most data-centric one. People questioned this. One guy told Stephen that he would rather cut his heart out with a spoon than program a database in Node.js. We did run into challenges around not having direct control of OS in the file system. Also, C/C++ are faster, but can be more complicated and not necessarily as scalable horizontally. It really depends if you're looking for vertical or horizontal computing. Now people have realized this was a great idea because we have all these incredible features in our product that we didn’t have to build and are inherent in what we do. Tech Stack This is what our tech stack looks like. We consider our to be part of the HarperDB stack, and that is built in React with a Node back end. The green box signifies any application built on top of HarperDB, for example our can be used to build custom workflows. The HarperDB technology is built entirely in Node.js, which encompasses our interfaces and HarperDB core. Management Studio Node-RED node Our product presents itself as a REST API which, under the hood, is essentially just an Express application, that’s the primary interface for how you interact with HarperDB. Our NoSQL parser is a custom solution we built internally. We use AlaSQL for our SQL parsing functionality which you can , we extend their functionality with custom code on top of that, it’s an amazing npm package for parsing SQL. We offer drivers, like ODBC and JDBC, built by a partner of ours. Finally, we use SocketCluster for distributed computing and clustering which . read more about here our CTO presented on in August The HarperDB core technology encompasses the “secret sauce.” This is what makes it possible for us to be fully indexed with no data duplication and offer various interface options to a single data model. Within the core there are numerous npm packages implemented to extend our functionality. Finally we have various options for storage media. We bundle LMDB by default as it provides significant performance gains over the other options. HarperDB core contains extensible code that allows us to add additional storage media options in the future. REST API HarperDB is a set of microservices A single endpoint All operations are post Stateless/RESTful (Sample code found at https://docs.harperdb.io/ ) At a former company our team dealt with the headache of hundreds of API’s with different endpoints, which was simply insane. People might think it’s weird that HarperDB is just one endpoint, but if you look in the body of the code, for every operation you do- all you ever have to change is the body, those first few lines. This is super simple, and when writing a REST-based application you can make it really straightforward. This is something you can take from us and use in any application! Basically you post a single message to the API, we see what operation you’re performing, and handle it with a standard set of methods. We’ve rewritten a lot of our application over the last couple years but this part has stayed mostly the same. Management Studio Built on the HarperDB REST API Written in React Native Allows for control of your HarperDB instances via GUI The HarperDB is a React front end built on top of our microservices (so we eat our own dog food). React is amazing, it’s changed the quality of front end development and allows us to make our application more accessible. By building on top of this, we’re also testing our own API’s at the same time - which makes it really powerful. Jaxon our VP of Product chose React for the Studio, while Stephen wrote our back end reporting in Express. Management Studio One awesome thing about JavaScript is how lightweight it is, regardless of what framework you're using (Node, React, etc), and you can easily couple together these different layers. AlaSQL SQL search is built on AlaSQL https://github.com/agershun/alasql Allows for enhanced SQL Our devs contribute to the project , it has some great things in it that we don’t, and allows us to wire in things like Math.js and GeoJSON so it’s an incredible package. If we had to build our own SQL parser we’d probably still be building HarperDB. It took one of our competitors, FaunaDB, about 4 years just to get to market, but we launched the beta of our product in 6 months, the original version in 12 months, and we just released our cloud product a few months ago (about 3 years later). We chose AlaSQL for HarperDB's back end functionality One amazing benefit of using Node for a language like this is as technology is advancing, most of the cool stuff that you want and need is on npm. We’re not saying we’re geniuses, but by developing in Node we got to stand on the shoulders of people like AlaSQL developers which is what we find amazing about the npm community. Maths.js HarperDB uses math.js functions inside our SQL Allows for enhanced math capability while leveraging the capabilities of npm community Maths.js is another incredible package for things like averages, data science, etc., that we wired into our SQL capability. It’s not hard to use and very powerful in combination with AlaSQL. Clustering/Replication Built on SocketCluster.io Fault tolerant Peer-to-Peer Table level replication Globally shared schema Distributed Computing Another very cool feature of building something in Node.js is that it’s stateless by nature, meaning it does not require holding data in memory that is critical to serving clients across sessions, which is very resource efficient. Most enterprise grade applications have background processes and stateful variables that can become highly unstable. Node is stateless, designed for the web, designed to scale horizontally and to be peer-to-peer. An amazing benefit from using a Node framework is that we were able to wire in SocketCluster to power our clustering and replication. HarperDB uses a simple pub-sub model, so we replicate data by publishing data to different chat rooms which different nodes subscribe to and are able to be distributed horizontally. Node can be horizontally scalable and less resource intensive than other languages, and its stateless nature makes it incredibly stable. By putting Node on lots of computers (horizontally scaling) you can make the framework significantly more powerful while driving down costs, having easier development, and being part of an awesome community. LMDB & File System Originally built our exploded data model on the file system Problematic due to the generation of many files taking up inodes and excess disk space, and other issues Rebuilt data model on LMDB Massive performance gain Originally we were using the file system directly with the above HarperDB data model, this is what makes the product unique. As data comes in, we map it to our data model, it's not a SQL engine or NoSQL engine. We exploded that data into individual attributes and stored them in a folder structure on the file system. We store each thing atomically, and you can query via SQL and NoSQL. We did run into some challenges at scale, so , a key value store that we operate on top of. We were able to implement our exact data model on top of that and it has provided incredible performance gains. , largely thanks to LMDB. more recently we wired in a package called LMDB In a recent benchmark we were about 37 times faster than MongoDB Once again, by leveraging the amazing Node community we are able to focus on what we’re good at. Also published at https://dev.to/harperdb/building-a-database-written-in-node-js-from-the-ground-up-2hgm

HarperDB - How and Why We Built It From The Ground Up on NodeJS

[Tutorial] How to Develop Blockchain Applications — Part 2/2

In this post we will get familiar with the architectural approaches that make . We will address five simple, yet efficient software development approaches for blockchain applications. Each of them being supported with code samples and tutorials. blockchain application development almost like a walk in the park This is an introductory post, that will be followed by separa te tutorials and workshops where we will build a fully working blockchain application. Bootstrapping The Development Environment Setup Before we jump into blockchain application development, we always need to have: Our own chain running. The knowledge to launch a local node. Connect to some kind of public test blockchain network that is run and maintained by someone else and out of our control. Knowledge of blockchain mechanics (p2p layer, consensus mechanism, a vast array of developer tools for client/server side). We all know the sysadmin magic that had to be done in order to get a blockchain node running in the past. As a consequence a lot of developers got turned away by the sheer complexity of the development environment setup or missing cryptographic libraries and implementations. Luckily for all of us, our HERO — came along. Delivering the promise of seamless and easily customisable blockchain deployment in three simple steps. The ARK Deployer Everything we learned in the field (meetings with organisations, PoC projects implementations, hackathons and workshops) combined with our expert knowledge has guided us towards building a product to enable easy and in a only a few minutes. simple deployment of your very own custom blockchain All ARK based bridgechains are accompanied with free and open-source SDK’s, that enable you to jump right into application development and leave the blockchain protocol and sysadmin details to be taken care of by our automation tools and SDK implementations in more than 1 . Feel free to join our friendly chat at and ask for help and guidance in our #help channel. 2 programming languages https://ark.io/slack ARK Logic: Blockchain Application Development Steps With ARK’s modular core our distributed-servers/nodes running in the background translate into containers — where you can deploy your own blockchain based applications and you don’t need to worry about consensus protocol or peer-to-peer network mechanics — it’s a protocol thing, just like TCP/IP, well a lot more complex; but it’s there running in the background, delivering security, trust and immutability — delivering the promise of blockchain. Distributed Blockchain Applications in General From the start of my journey in the blockchain space, I always wanted to build complex applications on top on this excellent technology. One of ARKs’ promises was/is to deliver tools and best practices that will close this gap and make blockchain application development a breeze. One of our first team accomplishments towards this goal is working hand in hand with the . ARK Logic ARK Deployer This gives us the power to create blockchain applications, that can be run within any blockchain based on ARK Core technology. By developing applications on our developers can blockchain agnostic applications, target bigger audiences and provide agnostic plug-able core technology build cross-chain compatible solutions. This introduces and further strengthens the role of the ARK Ecosystem, by bringing in . Our blockchain application development approach is closing the gap between traditional development practices by bridging the concept of software libraries and blockchain development. new interchain monetization services allowing businesses to fully exploit and research new crypto driven business models ARK Logic: Basic Overview of dapp Structure This is how we see the distributed blockchain applications development and deployment on our core-technology stack: Blockchain application is an abbreviated form for decentralized application-dapp, that can already be deployed as a blockchain module. A dapp has its backend code running on a decentralized peer-to-peer network (ARK). Contrast this with an app where the backend code is running on centralized servers. A dapp can have frontend code and user interfaces written in any language (just like a normal application) that can make calls to its backend via simple API calls, or by using any kind of protocol that was implemented as a communication channel in the dApp module implementation (see point 1). A dapp can also host its frontend on a decentralized network, in this case, the language limitations must be compatible with our core-technology language landscape and our blockchain network servers as an application provider. A dapp can implement only micro services, allowing modular design, easier bug-fixing, and upgrading as a normal software application. Now we can deploy a , like in most web applications — but where is “the blockchain/the ledger” and how do we use it? Ok, so what now? module Don’t worry, we got you covered with Your application life cycle is maintained by our Core and is inherited by the overall life cycle of a blockchain node. A strong benefit of plug-able applications/modules is having access to the blockchain mechanics in a very simple and developer friendly way. Blockchain interaction is something we take very seriously, and we deliver this via the following approaches. ARK Logic — Enabling your application to run in a modular fashion on the distributed network. ARK Logic: Best Practices In this section we will look into five core approaches that enable you to seamlessly develop distributed blockchain applications on top of our platform. As a developer you will learn: How to interact with the blockchain state. How to interact with the blockchain database. Learn to use events and react to state changes. Add new API endpoints via customisable HTTP server running within core nodes. Pack your blockchain application as a module and distribute it. . 1 Interacting with the blockchain state The core-blockchain package is the central entity around which everything revolves. It provides a state-machine that controls the state of your node and switches between states to sync, rollback or recover from a fork. It holds all of the information that is important to know when you want to see what the current state of your blockchain node is. Do not trust the database, trust the in-memory data it exposes, as it’s updated in real-time. { app } ; blockchain = app.resolvePlugin( ); { blockchain.isSynced(); blockchain.getLastBlock(); blockchain.getLastHeight(); blockchain.getLastDownloadedBlock(); blockchain.getEvents();
}

callBlockchainMethods(); import from "@arkecosystem/core-container" const "blockchain" async ( ) function callBlockchainMethods // Check if the blockchain is fully synced // Get the last block we've received // Get the height of the last block we've received // Get the last block we've downloaded // Get a list of events the blockchain emits Full Tutorial: https://docs.ark.io/tutorials/core/plugins/how-to-interact-with-the-blockchain.html#getting-started 2. Interacting with the database You can access blocks and transactions in a very simple and efficient way by using the database plugin. { app } ; database = app.resolvePlugin( ); { database.getBlock( ); database.getBlocks( , ); database.getBlocksByHeight([ , , ]); database.getBlocksForRound( ); database.getLastBlock(); database.getRecentBlockIds(); database.getTransaction( );
}

callDatabaseMethods(); import from "@arkecosystem/core-container" const "database" async ( ) function callDatabaseMethods // Get a block from the database by its id await "some block id" // Skip the first 100 blocks, grab the next 100 await 100 100 // Grab blocks at height 1, 5 and 10 await 1 5 10 // Get all blocks that have been forged in round 10 await 10 // Get the last block we've received await // Get the last 10 blocks we've received await // Get a transaction from the database by its id await "some transaction id" Full Tutorial: https://docs.ark.io/tutorials/core/plugins/how-to-interact-with-the-database.html#getting-started 3. Use events to listen and react to changes Core provides a package called core-event-emitter which exposes an instance of the Node.js EventEmitter. A common use-case is that your module will listen to events that core emitted in order to process the data for monitoring. Your module can also emit events that can be listened to by other plugins (or your own for internal use). { app } ; { EventEmitter, Logger } ; logger = app.resolvePlugin<Logger.ILogger>( ); emitter = app.resolvePlugin<EventEmitter.EventEmitter>( );

emitter.on( , { logger.warn( ); }); import from "@arkecosystem/core-container" import from "@arkecosystem/core-interfaces" const "logger" const "event-emitter" "forger.missing" => delegate // This will be a wallet object that contains information like the address, username, public key, votes, etc. ` just missed a block.` ${delegate.username} // Here we could for example send a slack notification that we just missed a block Full Tutorial: https://docs.ark.io/tutorials/core/plugins/how-to-interact-with-events.html#listening-for-events 4. Add new API endpoints via customisable HTTP server running within core nodes A common use-case for a plugin is that you process some data from within core and want to make use of that data with an external application. The easiest way to do this is through an HTTP server that exposes an API from which you request the data. { createServer, mountServer } ; { server = createServer({
    host: config.host,
    port: config.port
  });

  server.route({
    method: ,
    path: ,
    handler(request, h) { ;
    }
  }); mountServer( , server);
}

startServer({ host: , port: }); import from "@arkecosystem/core-http-utils" export async ( ) function startServer config const await "GET" "/" return "Hello World" return "My HTTP Server" "localhost" 8000 Full Tutorial: https://docs.ark.io/tutorials/core/plugins/how-to-create-http-servers.html#getting-started 5. Pack and distribute your blockchain application as a module The last piece of the puzzle is packing everything into a module and distributing it to your blockchain network. Our plugins are modular by design, meaning the concepts described above will all be already developed inside your own module. Having your own module, enables you to publish it to the largest package repository — npm, thus making it available to everyone. { Container } ; { LogManager } ; { defaults } ; { PinoLogger } ; plugin: Container.PluginDescriptor = {
  pkg: ( ),
  defaults,
  alias: , : , register(container: Container.IContainer, options) { logManager: LogManager = container.resolvePlugin( ); logManager.makeDriver( PinoLogger(options)); logManager.driver();
  }
}; import from "@arkecosystem/core-interfaces" import from "@arkecosystem/core-logger" import from "./defaults" import from "./driver" export const require "../package.json" "logger" extends "@arkecosystem/core-logger" async const "log-manager" await new return Modules are very simple to write. At there core they are an object with a register property, that is a function with the signature async function. Additionally the plugin object has a required pkgproperty and several optional properties including version. Full Tutorial: https://docs.ark.io/tutorials/core/plugins/how-to-write-a-core-plugin.html#basic-structure-properties-of-a-plugin Using the above mentioned concepts will make your blockchain application development a breeze and it lowers the gap between enterprise application developers and crypto developers. We encourage you to test these approaches and start building your first blockchain application. Next Steps: Part 2 Part two of this Blockchain Application Development series will cover introduction to developing custom transaction types with our . The basic premise of GTI is to provide an easy way to without the need to modify more complex parts of the Core. It can be as simple as including pre-defined templates depending on the use case of the blockchain or re-using already present types and modify their parameters to introduce new ones. Developing custom transaction types enables you to add your own custom logic and data, validate it via existing consensus mechanisms and store it on-chain. Generic Transaction Interface (GTI) implement and include new transaction types in your blockchain After that you will master all the skills needed to build blockchain applications with ARK Logic. We will leverage that and build a fully functional blockchain application. Read our new 2019 whitepaper , Follow us on social media ( Twitter | Facebook | Reddit ), join our community ( Slack | Discord ) and stay tuned to our blog on Medium and on Steemit .

The Introduction To Blockchain App Development  (Part 1/2)

Well! they say “Experience is the mother of wisdom”, therefore, I being a recent addition to The (with a two-month exposure) would like to walk you through the nuts and bolts of Polymer. Polymer Fandom So, without any Mumbo Jumbo talk, let’s begin with the basic definition of Polymer! What is Polymer? Polymer is a JavaScript library used for creating web applications using Web Components. mkk Now, you can think of Web Components as reusable elements that can be used in web pages or web apps. That means you can also use it with other JavaScript libraries. Polymer is like a “lego block” which can be used to build anything, almost anything. Why Polymer? Suppose you want to make a study table for yourself. Here’s what you’ll do: Take a log of wood cut into pieces according to your requirement, construct the table top and legs, flatten the pieces and join them all. Quite a long process, no? How about you just get the pieces and assemble the table? Super simple. That’s how polymer works. You want to use some component, import it and use it, you don’t need to know how it works. You want to use it with Angular, React or Vue or some other JS library, just import it and use it. 4 main features of Web Components It makes easier to import HTML documents. Similar to importing CSS documents. HTML Imports: It helps developers to create their own elements. Custom Elements: It holds the content that is not to be rendered when a page is loaded but may be instantiated during runtime using JavaScript. In simple words, it contains HTML tags that is not rendered when a page is loaded but can be rendered later using JavaScript. HTML Template: Shadow DOM? What is it? I’ve just heard about the DOM.Shadow DOM inserts a new node to the DOM called shadow root and creates a boundary between the DOM and shadow root, so that the element(Web Component) inside the root remains modular and separated from the main DOM. Didn’t understand yet? No worries. I’ll explain it below. Shadow DOM: How to use Polymer? Make sure to install Node.js, npm, Git, Bower and Polymer CLI. You can follow the set up guide on the . Polymer website Now, let’s get into some code. Here’s the of what we’re gonna make. live demo <link rel="import" href="../polymer/polymer-element.html"><link rel="import" href="../paper-input/paper-input.html"> The is an HTML import. This imports polymer library and a custom element named paper-input. link rel="import” <dom-module id="basic-example"> The wraps the custom element which includes the styling, scripting and markup of custom element. The attribute is used to include the element into the main document tree. <dom-module> id defines the structure and styling of the element. <template> The inside the defines the styling for the element. styling <template> The is a one-way bind. It’ll display whatever will be the value of ‘name’ property. [[name]] is a custom element which is basically a text-field. is two-way binding which means if we type something in the input, it’ll immediately reflect in the ‘name’ property and change the value of the ‘name’ to whatever value is typed. <paper-input> {{name}} <script>class BasicExample extends Polymer.Element{static get is(){return 'basic-example';}static get properties(){return{name: {type: String,value: ""}}}}customElements.define(BasicExample.is,BasicExample);</script> This is ES6 class syntax inside tag. <script> gives element a name, so that the browser can recognize it when we use it in tags. This name must match the given in the element's template definition . static get is(){return ‘basic-example';} id <dom-module id="basic-example"> here the custom element API calls the method to register the element named whose class name is . customElements.define(BasicExample.is,BasicExample); define basic-example BasicExample Now, our custom element is ready to be used anywhere. All you need to do is import this custom element in the file in which you want to use this element and that’s all. For instance if you want to use this element in the file named , then you’ll import it and use it as follows: index.html <link rel="import" href="path-to-element/basic-example.html">   <basic-example></basic-example> Back to Shadow DOM It’s completely fine if you didn’t yet understand what Shadow DOM is. It took me a lot of time to understand what Shadow DOM is. Let me explain this with help of an example. Suppose you made a custom element without Shadow DOM with some nice CSS. And some other developer wants to use your element in his/her web applications. If the styling class of his/her applications matches with the ones in your web component then it’ll override the styling in your element. That’s really bad, no one wants that. Why would any developer on earth import web component and then spend his/her time improving it’s styling? And that’s the main reason to use Shadow DOM. In other words it the styling, scripting and structure of custom elements. To make things even more clear I added the picture below. encapsulates Here’s a screenshot from the Polymer website. is some component, all it’s styling, structure and scripting is inside the shadow root. pw-shell What’s next for Polymer? Last week in the Polymer Summit the following things were announced: Polymer 3.0 announced. Use of NPM and yarn, which means no more bower. Use of ES6 modules, which means no more . <link rel="import"> An easy migration for migrating code from Polymer 2.0 to 3.0. tool The new is the biggest project till now developed using Polymer. YouTube By now, you would have at least got an idea about Polymer and how it works. So, give it try and build you own custom elements. here **Thanks for reading this article. Please hit the button if you like it.**Connect with me on .Follow me on and . Clap LinkedIn Twitter Quora

Getting started with Google Polymer

A good GPU not only provides a , it effectively takes some load off from the CPU and increases the overall performance of 3D applications and software you use. Another sector strong GPUs are flourishing in is the crypto mining sphere. GPUs have now started being used for mining due to their efficiency over CPUs. richer gaming experience In this article, we’ll take a detailed look at the top 5 GPUs you should consider buying due to their crypto-mining capabilities. GPUs for Crypto Mining: Nvidia GeForce RTX 3080 AMD Radeon RX 6800 XT Nvidia GeForce RTX 3090 Nvidia CMP 40HX AMD Radeon RX 5700 XT After introducing each GPU, we will explain: Which GPU is best for crypto mining Which GPU is best for gaming 1. Nvidia GeForce RTX 3080 Starting at just $699, Nvidia’s GeForce RTX 3080 contains the new and improved . Crafted with 54 billion transistors, the Ampere architecture is a technology that accelerates AI adoption. The architecture also brings upgraded tensor cores for Deep Learning Super Sampling (DLSS), tapping into groundbreaking AI to boost frame rates while generating excellent, crisp game images. Ampere architecture By extending the power of tensor cores, Ampere architecture allows you plenty of room to crank up your gaming resolutions to the max for a stunning visual experience. The RTX 3080 brings 10GB of GDDR6X graphics RAM, 320-bit memory interface width, memory speed of 19,000 MHz and a maximum digital resolution of 7680x4320, allowing it to provide a splendid gaming experience while delivering a highly improved performance in comparison to its predecessor, the RTX 2080. Image: Nvidia Furthermore, Nvidia GeForce RTX 3080 features , simulating the physical behavior of light to bring real-time and cinematic-quality rendering to even the most visually intense games. The best thing about the ray tracing feature in this card is that due to DLSS technology’s video rendering techniques, it doesn’t sacrifice the frame rate while maintaining amazing video quality. It also introduces a new thermal-optimized design that promises 55% airflow, 30% more efficiency and the ability to be up to three times quieter during heated gaming sessions. ray tracing Although the RTX 3080 has limited potential for crypto mining, it is still one of the fastest GPUs for Ethereum mining, giving a baseline FE measurement of 85 MH/s. The performance can be further tuned to get around 93 MH/s, but it has to be noted that the processor can limit its mining performance unless modded with better thermal pads that lower memory temperatures. 2. AMD Radeon RX 6800 XT The AMD Radeon RX 6800 XT is AMD’s comeback to the high-end GPU market. Powered by Navi 21 graphics processor, it sports Red Team’s RDNA 2 graphics architecture based on a 7nm manufacturing process, allowing it to bring very powerful performance to the table. Image: AMD The card contains capability, guaranteeing support for ray tracing and variable-rate shading. With the Radeon RX 6800 XT, AMD has paired 16GB GDDR6 memory with a 256-bit memory interface, leading to smooth and high-quality gaming visuals at both 1080p and 4K. At $649, this kind of high video quality is truly astounding. DirectX 12 Ultimate Radeon’s image sharpening technique allows the RX 6800 XT to employ a contrast-adaptive sharpening algorithm that enhances in-game visual clarity and brings out clear details without impacting the overall game performance. The high-powered GPU also contains what Radeon refers to as the ‘ ’, a massive bandwidth amplifier that allows the cache to be seen by the entire graphics core, allowing for faster rendering during gameplay while reducing the power consumption. Infinity Cache Additionally, the RX 6800 XT comes with a memory speed of 16,000 MHz and a Boost Clock of 2250 MHz. These clocks let gamers enjoy a seamless gaming experience at high FPS levels for the majority of games. Like other top AMD graphic cards, the RX 6800 XT can be used to mine cryptocurrencies like Etherium, Beam, Expanse and Ubique, all at an amazing hash rate of 65 MH/s, with a power consumption of 135 watts. You can find its detailed mining hash rate details . here 3. Nvidia GeForce RTX 3090 The GeForce RTX 3090 claims to provide ‘the ultimate gaming experience.’ At a whopping $1500, you should fully expect it to. The ferocious GPU is stuffed with the same Ampere GA102 graphics processor as the GeForce RTX 3080, but it has more of everything - it contains 328 tensor cores, 82 ray tracing acceleration cores and 10,496 Compute Unified Device Architecture (CUDA) cores. These upgraded cores help with playing ray-traced games at 1440p and 4K resolution with utmost ease. The RTX 3090’s mammoth 24GB of GDDR6X memory capacity exceeds the , which, combined with its memory speed of 19,500 MHz, allows for a blistering gaming experience like no other. typically recommended 16GB At the time of its release, the RTX 3090 was the world’s first graphics card that enables you to play and watch games at , although other GPUs have followed suit since. At this level of gameplay, the detail is so crisp and clear that you’ll be able to easily discern individual blades of grass. Additionally, distant game elements such as avatars' skin wrinkles are instantly recognizable. It also contains , a bouquet of technologies designed to analyze and reduce input lag and system latency for a phenomenal gaming experience. 8K HDR Nvidia Reflex The high memory of RTX 3090, combined with the 10,496 CUDA cores and an astounding hash rate of 121 MH/s also makes it a top option for crypto mining - you might easily make it to three digits each month, depending on your power consumption. Image: Nvidia 4. Nvidia CMP 40HX CMP 40HX by Nvidia is a professional crypto mining focused graphic card. Based on architecture, Nvidia’s CMP 40HX comes equipped with the TU106 graphics processor, 2304 shading units and 256-bit bus width. The Turing architecture allows the card to function effectively with its 12 nm chipset. Turing With an introductory price of $699, the classy GPU features 8GB of GDDR6 VRAM and operates at a frequency of 1470 MHz, with a memory speed of 14 Gbps. Additionally, it features 144 texture mapping units and 64 render output units (ROPs). The card also contains DirectX Ultimate capability, leading to incredible graphics performance through variable rate shading for gaming. The CMP 30HX is optimized for Etherium crypto-mining performance. The card allows a fully open, airflow-optimized bracket and is configured to allow high mining efficiency. Its extremely durable ball bearings can withstand years of intense use, and remain virtually silent while spinning under load. The powerhouse is rated at 185 watts and adheres to a 36 MH/s hash rate. However, ASUS’s internal testing performance of eight CMP 40HX prototypes was revealed through an image by , and the cards were each pumping out over 43 MH/s, leading to even greater promise over the crypto mining performance of the CMP 40HX. VideoCardz 5. AMD Radeon RX 5700 XT The AMD Radeon RX 5700 XT is a high-end GPU built on the 7nm process and based on Navi 10 graphics processor. At just $450, it provides amazing value for money as well. AMD has paired the card with 8GB GDDR6 memory connected using a 256-bit interface, with a memory speed of 14 Gbps. The RX 5700 XT’s RDNA architecture allows incredible visual effects combined with reduced latency levels to make for a very responsive gaming experience. Its Displayport 1.4 data and audio connection supports up to 8K resolution at 60 Hz or 5K at 120 Hz, allowing a truly immersive experience. Image: AMD When it comes to crypto mining, the RX 5700 XT is right up there among the best. It has an average mining hash rate of , which is truly astounding for its price range. It is a great option for mining a variety of cryptocurrencies such as Ethereum, Monero and Ravencoin, among others. 54 MH/s The beast is equipped with a cooling system with an aluminum radiator, copper tubes and dispersion blades, designed specifically to increase airflow efficiency. This system allows it to maintain its performance consistency to a great extent during mining, withstanding high amounts of heat. Which GPU to buy in 2021? Since we have discussed all GPUs with regard to gaming as well as mining capabilities, we’ll divide this section into two parts, looking at both these factors. Which GPU should you buy for crypto mining? All the aforementioned GPUs contain strong mining capabilities in general. However, when they are pitted against each other, some major differences come to the fore. Although Nividia’s CMP 40HX is designed specifically for mining and has its strong points, it’s ultimately a low-end mining option by Nvidia, especially keeping in mind that the 50HX and upcoming 90HX blow it away in almost all aspects. The Nvidia RTX 3080, Radeon RX 6800 XT and RX 5700 are all strong contenders in their own right, with good hash rate levels and processing speeds. However, miners typically seek to mine for very long durations, and the possibility of the cards heating up is very real. There is a high probability that you’ll need to wait for a very long period of time to realize a good ROI with these options, if at all. That leaves the Nvidia RTX 3090 as the last GPU standing. Its incredibly high 24GB memory, coupled with the jaw-dropping hash rate of over 120 MH/s, make it an ideal option for miners, even for the longest durations. Yes, it is priced significantly higher than the other GPUs discussed in the article, but the main thing to keep in mind here is that if your priority is crypto mining, there genuinely is no better option than the RTX 3090. It’s understandable if you want to forego the powerhouse for less costly options in terms of gaming, but when it comes to mining, you should cough up more cash and get your hands on the RTX 3090. You’ll have the best possible shot at recouping your investment a few months down the line, so go for it! Nvidia also on limiting graphic cards capability for mining to keep the availability of its top hardware for gaming users. hinted Which GPU should you buy for gaming? The CMP 40HX is made primarily for mining, so we’ll not consider it here. Moreover, although the RX 5700 XT has good enough gaming specs, its primary strength also lies in the mining department. All the other three among Nvidia’s GeForce RTX 3080, GeForce RTX 3090 and AMD Radeon RX 6800 XT pack a real punch in terms of overall gaming performance, but when it comes to choosing which one to go for, various factors come into consideration. The Nvidia GeForce RTX 3090 graphic card is the clear winner when it comes to gaming, but there is a caveat - at $1500, it’s priced way higher than the other two. If you are a deep-pocketed enthusiast who doesn’t mind spending exuberantly for the absolute best performance possible - both gaming and general - then it’s the GPU to go for. But if price is your concern, you should narrow the options down to the other two. Even though Nvidia GeForce RTX 3080 is priced $50 higher than AMD Radeon RX 6800 XT, its Ampere architecture brings more to the table in terms of performance improvements than the latter’s RDNA 2 architecture. Furthermore, RTX 3080’s DLSS technology significantly improves the image resolution of games with minimal impact on the FPS rate. As such, RX 6800 XT doesn’t offer a direct counterpart to DLSS. Image: TomsHardware From the 10-game DirectX Ray Tracing benchmark comparison at 1440p resolution above, we can see that RTX 3080 holds an edge over RX 6800 XT in all but two games - and . The overall average of 61.5 FPS across the 10 games is better than RX 6800Xt’s 45.8. Godfall Dirt 5 For all these reasons, you should shell out a little more cash and go with Nvidia’s GeForce RTX 3080 - the extra $50 shouldn’t be a reason to give up its impressive features and slightly better overall gaming performance. What are your thoughts? Feel free to let us know in the . Hackernoon Community

Stories, News & Mentions about DOMSHARK

Domshark’s Stories on HackerNoon