Android cross-compile #5241
Closed
Android cross-compile #5241
Conversation
This file contains hidden or 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
This is an implementation of a map and set for integer keys. It's an ordered container (by byte order, which is sorted order for integers and byte strings when done in the right direction) with O(1) worst-case lookup, removal and insertion. There's no rebalancing or rehashing so it's actually O(1) without amortizing any costs.
The fanout can be adjusted in multiples of 2 from 2-ary through 256-ary, but it's hardcoded at 16-ary because there isn't a way to expose that in the type system yet. To keep things simple, it also only allows `uint` keys, but later I'll expand it to all the built-in integer types and byte arrays.
There's quite a bit of room for performance improvement, along with the boost that will come with dropping the headers on `Owned` `~` and getting rid of the overhead from the stack switches to the allocator. It currently does suffix compression for a single node and then splits into two n-ary trie nodes, which could be replaced with an array for at least 4-8 suffixes before splitting it. There's also the option of doing path compression, which may be a good or a bad idea and depends a lot on the data stored.
I want to share the test suite with the other maps so that's why I haven't duplicated all of the existing integer key tests in this file. I'll send in another pull request to deal with that.
Current benchmark numbers against the other map types:
TreeMap:
Sequential integers:
insert: 0.798295
search: 0.188931
remove: 0.435923
Random integers:
insert: 1.557661
search: 0.758325
remove: 1.720527
LinearMap:
Sequential integers:
insert: 0.272338
search: 0.141179
remove: 0.190273
Random integers:
insert: 0.293588
search: 0.162677
remove: 0.206142
TrieMap:
Sequential integers:
insert: 0.0901
search: 0.012223
remove: 0.084139
Random integers:
insert: 0.392719
search: 0.261632
remove: 0.470401
@graydon is using an earlier version of this for the garbage collection implementation, so that's why I added this to libcore. I left out the `next` and `prev` methods *for now* because I just wanted the essentials first.
These commits remove some obsolete language features, make some highlighting more correct with respect to the language spec, and introduce highlighting for macros, attributes, core traits, and the new region syntax.
…iples For cross compiling to targets that don't want to build a compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Suggestion cannot be applied right now. Please check back later.
r? @graydon
This is the bulk of the makefile work necessary to support cross-compiling with multiple toolchains. With this we can cross-compile to Android, but not run the test suite on Android. There is still some polish yet to add, but I want to get this merged.
Key changes:
platform.mkproduces distinct toolchain variables (CC, CXX, etc.) for each target triple, and in turn most of the makefiles are now parametrized over target triples.configurerequires--android-ndk-pathwhenarm-unknown-androidis a target tripleAs an example, to cross-compile to android, you configure with
../configure --target-triples=arm-unknown-android --android-ndk-path=~/dev/android-standalone-ndk-14. In this case the build triple and the host triples are automatically inferred, and the build triple added to the target triples, so if you are running on x86_64-unknown-linux-gnu, build-triple=x86_64-unknown-linux-gnu, host-triples=x86_64-unknown-linux-gnuand target-triples=x86_64-unknown-linux-gnu,arm-unknown-android.Thanks to @yichoi who did most of this work.
Issue #4513.