Skip to content

Commit

Permalink
fixing typos
Browse files Browse the repository at this point in the history
  • Loading branch information
makingthematrix authored Sep 6, 2019
1 parent bf5dcf0 commit 2c30b19
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,16 +5,16 @@ An implementation of a set and a map with unsigned integers as keys.

I believe in using the right tools for a job. There are cases where generic data structures together with traits implementations designed to work for any kind of element held inside, and any kind of usage, result in sub-optimal performance, and unclear code.

This project is an attempt to provide more suited alternatives for `HashSet` and `HashMap` when used in situations like video games or real scene simulations. I imagined a situation when the user has to handle a few hundreds or thousands (but not billions) of data structures describing objects in the scene. They can be created, modified, and deleted fairly quickly. Instead of references, they hold identifiers to data structures in other maps. The identifiers can be simple integers, so the data structure is of known size at any point in time. This allows the user to store all of them in one or many maps where unsigned integers work as keys, retrieve those keys as sets of unsigned integers, operate on them, and finally use them to access the data structures. A set of identifiers, `USet`, is pretty lightweight and can be cloned without much effort if moving the ownership is not possible. A map, `UMap`, may be hold in one place, accessible from many others, as a form of a primitive (ECS)[https://en.wikipedia.org/wiki/Entity_component_system].
This project is an attempt to provide more suited alternatives for `HashSet` and `HashMap` when used in situations like video games or real scene simulations. I imagined a situation when the user has to handle a few hundreds or thousands (but not billions) of data structures describing objects in the scene. They can be created, modified, and deleted fairly quickly. Instead of references, they hold identifiers to data structures in other maps. The identifiers can be simple integers, so the data structure is of known size at any point in time. This allows the user to store all of them in one or many maps where unsigned integers work as keys, retrieve those keys as sets of unsigned integers, operate on them, and finally use them to access the data structures. A set of identifiers, `USet`, is pretty lightweight and can be cloned without much effort if moving the ownership is not possible. A map, `UMap`, may be held in one place as a form of a primitive [ECS](https://en.wikipedia.org/wiki/Entity_component_system).

### Implementation

Implementation is very simple:
`USet` is built around a vector of booleans. It also has an offset, which helps with memory conservation, and redundant minimum and maximum values, which greatly speed up operations on the set. If the n-th element in the vector is `true`, from the API point of view it means that the set contains the value `n - offset`.
`USet` is built around a vector of booleans. It also has an offset, which helps with memory conservation, and redundant minimum and maximum values, which greatly speed up operations on the set. If the n-th element in the vector is `true`, from the API point of view it means that the set contains the value `n + offset`.

Accordingly, `UMap<T>` is built around a vector of elements of the type `Option<T>`. If the n-th element in the vector is `Some(t)`, from the API point of view it means that the map contains the value `t` under the identifier `n - offset`.
Accordingly, `UMap<T>` is built around a vector of elements of the type `Option<T>`. If the n-th element in the vector is `Some(t)`, from the API point of view it means that the map contains the value `t` under the identifier `n + offset`.

All this means that `USet` and `UMap` trade memory for CPU. They are not very well suited for storing huge number of entries in the memory, but for smaller amounts the benchmarks show a 3.5-4.0x performance boost over a similar functionality.
All this means that `USet` and `UMap` trade memory for CPU. They are not very well suited for storing huge number of entries in the memory, but for smaller amounts the benchmarks show a 3.5-4.0x performance boost of `USet` over a similar code using `HashSet`.

### Usage

Expand Down

0 comments on commit 2c30b19

Please sign in to comment.