Hacker Newsnew | past | comments | ask | show | jobs | submit | telez's commentslogin

seems like a UI design failure


"Don't make me think" was certainly the guiding principle at play here.


UI could be considered failure if we were talking about casual gossip. Particular UI shouldn't be the issue because the App was not supposed to be used for this. These should be professionals. Issue was between keyboard and chair.


I do not quite understand the last figure for the relaxed avl tree. For the 100 % lookup (rightmost) the TL2 algo should scale linearly with the number of threads. For read-only transactions, TL2 needs to sample the global version, then for all reads make sure the local version is less than or equal to the sampled version. given this, it is difficult to understand why the graph is sub linear and that TL2 is not as fast as the other STM implementations.


I don't see such a graph for TL2? I do see one for TLRW though which does use reader locks, hence the scalability cap.


the chart doesn't seem visible on ios safari but i can see it on firefox desktop however, the figure seems to be the same as from the linked paper: https://zenodo.org/record/7886718


Ah ok I found it there, I see what you mean now. My only guess would be cache effects? With that large AVL tree (1 M entries, so likely dozens of MiB), you are escaping L2 cache and hitting shared L3 or main memory for a large portion of lookups, and are bandwidth-constrained at the die level, thus adding that knee (which I think is visible with some of the other algorithms as well).


but TL2 shouldn't be using more memory than say TinySTM, i don't think. If the implementations are object based and nodes are cache aligned, adding an extra 8 bytes for the versioned-lock shouldn't bump the node size to greater than a cache line.

however, i do think the tl2 implementation as described in the paper is memory based, as is TinySTM so every read needs to do a hash to locate the corresponding lock / meta data. the read-only transactions for tl2 and TinySTM seem identical to me which is why i am so confused.

looking at other figures from the 2PLSF paper, the TL2 for 100% lookup on hash set and skip list it looks like such a dog compared to the other algos.


i find that duckdb is great for processing json files. i can never remember how to use jq other than for pretty printing. using duckdb in a bash script with the sql in a heredoc is pretty powerful.


use grouped targets https://www.gnu.org/software/make/manual/html_node/Multiple-... rather than sentinel.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: