Persistent Data Structures - partial::Conf
•Download as PPTX, PDF•
0 likes•197 views
This document discusses persistent data structures. It begins by introducing the speaker and their background. It then defines different types of persistent data structures including ephemeral, partially persistent, fully persistent, and confluently persistent structures. It provides examples of applications of persistent data structures like avoiding side effects, multithreading, and transaction rollback. It discusses implementation considerations like dealing with old nodes and using garbage collection. It concludes by discussing techniques to improve performance of persistent data structures like tail optimization, focus in Scala, and using transients.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Persistent Data Structures - partial::Conf
Similar to Persistent Data Structures - partial::Conf (20)
Recently uploaded
Recently uploaded (20)
Persistent Data Structures - partial::Conf
- 2. ABOUT ME • Currently - Backend @ Heap • Real-time music recommendations @ SoundCloud • Google, Facebook, Leanplum, Chaos Group • Bronze medal @ IOI ’09
- 3. INTERNATIONAL OLYMPIAD IN INFORMATICS What do IOI people have in common?
- 4. IOI PEOPLE CARE ABOUT PERF And also, algorithms and data structures … and lots of other things
- 5. I CARE ABOUT PERF, TOO
- 6. – Functional Programming @ Universities “Oh, just try to understand the concept.”
- 9. WHAT’S NEXT 1. Types of Persistent Data Structures 2. Applications 3. Implementation and performance considerations
- 10. TYPES OF PERSISTENT DATA STRUCTURES
- 11. EPHEMERAL DATA STRUCTURES Or, what most programmers call simply “data structures”
- 12. PARTIALLY PERSISTENT DS You can look, but you can’t edit
- 16. CONFLUENTLY PERSISTENT DS DAG = Directed Acyclic Graph
- 17. CONFLUENTLY PERSISTENT DS Now with merge support!
- 18. APPLICATIONS
- 20. MULTITHREADING
- 21. TRANSACTION ROLLBACK void addCustomer(List<int> customerIds, int id) { try (transaction.start()) { customerIds.add(id); transaction.commit() } catch (RollbackException e) { // ??? } }
- 22. TRANSACTION ROLLBACK void addCustomer(List<int> customerIds, int id) { try (transaction.start()) { customerIds.add(id); transaction.commit() } catch (RollbackException e) { customerIds.pop_back(); // what if we had 10 objects? } }
- 23. TRANSACTION ROLLBACK List<int> addCustomer(List<int> customerIds, int id) { try (transaction.start()) { val newCustomersIds = customerIds.add(id); transaction.commit() return newCustomersIds; } catch (RollbackException e) { return customerIds; } } (Of course, that’s kinda obvious at a functional programming conference…)
- 24. OPTIMISTIC UI Optimizing user perception instead of performance Image source: https://uxplanet.org/optimistic-1000-34d9eefe4c05
- 25. OPTIMISTIC UI • People hate waiting • API calls almost always succeed • => just pretend they succeeded and update UI • However, failures do occur sometimes
- 26. HANDLING FAILURE WITH FULLY PERSISTENT DS val speculativeState = state .update('list1', state.get('list2').get(0)) .remove('list2', 0) display(speculativeState); api .saveState(speculativeState) .onError(=> display(state));
- 27. WHAT IF THE SERVER KNOWS SOMETHING WE DON’T? Say, someone shot us in Quake
- 28. CONFLUENTLY PERSISTENT DS val speculativeState = state .update('list1', state.get('list2').get(0)) .remove('list2', 0) display(speculativeState); api .saveState(speculativeState) .onSuccess((serverState) => newState = merge( serverState, speculativeState)); .onError(=> display(state));
- 29. POSTGRES MVCC Speaking about transactions…
- 30. POSTGRES MVCC • MVCC ~~= when modifying a row, create a new version instead of modifying in-place • Arrays, etc. need to be copied every single time
- 31. UNDO AND BROWSING HISTORY
- 32. GEOMETRIC PROBLEMS Time is just another dimension
- 33. POINT LOCATION Or, how your browser determines where you clicked
- 34. POINT LOCATION Split vertically at intersections
- 35. POINT LOCATION Each vertical split is ordered
- 36. POINT LOCATION - ATTACK PLAN 1. Split map into vertical stripes at intersections 2. Create a BST for each stripe 3. Do a binary search to find the stripe 4. Locate the region in the BST
- 37. HOWEVER, N BINARY TREES = O(N^2) MEMORY
- 38. DELTA BETWEEN TREES IS LIMITED
- 39. DELTA BETWEEN TREES IS LIMITED
- 40. USE PERSISTENT BINARY SEARCH TREES
- 41. TIME Y
- 43. DEALING WITH OLD NODES
- 44. YOU REALLY WANT GARBAGE COLLECTION • Otherwise… • reference counting (e.g. C++ shared_ptr<T>) • now, each node is mutable • we need synchronization • destruction can be very slow and cause stack overflows
- 45. WHY 32 SLOTS PER NODE? Source: http://hypirion.com/
- 46. WHY ARE BINARY SEARCH TREES BINARY? • Why not 1000-way search trees? • logN N = 1, so why not? • Because we need to be able to search and insert • Complexities are not really O(logk N) • Search: O(log k * logk N) • Insert: O(k * logk N)
- 47. 1000-WAY SEARCH TREE • Each node would need to support efficient insertion of elements and search • Which sounds exactly like a binary search tree…
- 48. WHAT’S WRONG WITH BINARY? • Node(Node* left, int value, Node* right) • how much memory does the CPU read? • >= 1 cache line • usually 64 bytes • even more if you read from disk
- 49. SO… HOW ABOUT BITMAPPED VECTOR TRIES?
- 50. BITMAPPED VECTOR TRIE COMPLEXITIES • We don’t really need to search - we know the exact index we care about • Lookup - O(logk N) • Let’s set k = N!!! • * this vector trie would not be persistent though
- 51. PERSISTENT VECTOR COMPLEXITIES • Lookup - O(logk N) • constant work per node • Update - O(k * logk N) • need to copy k elements for each node
- 52. WE NEED BALANCE
- 53. LOOKUP VS UPDATE SPEED • Lookup gets faster with larger k • Updates are more complicated Source: http://hypirion.com/
- 54. EVEN MORE PERF
- 55. TAIL OPTIMIZATION • What do people usually do with vectors? • They append to them • Let’s optimize for that
- 56. TAIL OPTIMIZATION Keep the tail separate Source: http://hypirion.com/
- 57. SCALA’S FOCUS • Like a tail, but for any index • Optimizes local operations
- 58. TRANSIENTS • When it’s all still too slow • Prevents the data structure from being persistent for a while
- 59. EXTENSIBILITY 7 4 5 2 111 92 173 44 35 13
Editor's Notes
- explain what IOI and an informatics competition is
- They care about performance (well, except for complicated algorithms and data structures) We can have essentially the same solution, but if mine is 5 times slower than yours, I’ll fail To be honest, this matters especially when you can’t figure out the exact solution so you force your way there second place because I wrote the fastest “wrong” solution Writing efficient brute-force solutions is one of the most important skills in these competitions
- so I had kind of a rough start with functional programming not so much because of inherent qualities but because of mindset
- I studied FP when I was in university I’d ask “this sounds horribly inefficient, how does it actually work?” this was the answer ^
- That’s not exactly how computers work Or at least not at the level of understanding that I’d like to have
- - I’ll be comparing to Version Control Systems (as mentioned during the previous talk)
- once you modify it, it’s gone this is the default in most imperative and OO programming languages it’s like programming without version control - no history, very hard to synchronize
- it’s like git without branching git commit at HEAD only; git checkout
- version history is linear
- git commit, git checkout, git branch / git checkout -b version history is now a tree what’s missing? (git merge)
- - Already discussed during the previous talk
- - it’s a bit more complicated in some circumstances - e.g. if you don’t have GC
- - obvious at a functional programming conference, but it is actually something that persistent data structures allow us to do efficiently
- - if you think about it, this is exactly transaction rollback, but slightly closer to the user
- this is all completely speculative but it sounds very much like a persistent data structure Postgres team is certainly aware of persistent data structures so this is either not a priority or there are some implementation concerns
- keeping a list of changes is hard to maintain and doesn’t scale need to keep a mapping between action and reverse action and be very careful with it can’t go back multiple states at a time
- if this sounds too exotic, consider what your browser is doing all the time I know this doesn’t look related to any of the previous things, so we’ll take it step by step
- if you look at the white stripe in the middle, you can see there are no intersections inside it and all the segments are ordered ordered means we can do binary search not exactly by starting point, but you can do the math and order by it and we can put them in a binary tree order is the same, but the bounds change do a binary search to determine the right vertical stripe
- if you look at the white stripe in the middle, you can see there are no intersections inside it and all the segments are ordered ordered means we can do binary search not exactly by starting point, but you can do the math and order by it do a binary search to determine the right vertical stripe
- what happens when xs goes out of scope? we need to find a way to get rid of it
- we went from nice, immutable data structures to each node being mutable and requiring synchronization depending on the usage pattern, this might cause contention on the reference counters destruction needs to free all elements recursively
- I’ll start from far away and build up to it
- O(log k * log_k N) for search if we binary search inside the node
- what’s wrong is cache friendliness and memory locality disk block ~4kb
- given a lookup or update index, we know exactly what position in the node we care about lookup is O(log_k N), if update is the same - let’s make k = N? well, that’s exactly what we do - in C++ vectors, Java ArrayLists, etc.
- - we have to figure out how often we do update vs lookups
- - removes the log_k N multiplier for 31 out of 32 appends