Thank you ! It's indeed precomputed levels of detail, the backend serves a key-value store: for each bucket a top 10 events that start or end in this bucket. A bucket is described by its zoom level (from 1 day to 2^34 days) and time coordinates.
Wikidata is the source I used to get metadata about Wikipedia articles. Sometimes the data is automatically extracted from Wikipedia articles which introduces these errors. What's nice is that the timeline representation easily shows these outliers and will help us fix them !
Thank you for sharing your project, it must have been quite some work to curate the events. My plan is to at some point be able to implement various filters so that people can make usable timelines. Right now it's more of a tech demo.
Yes indeed, I'll fix them at some point ! For in-between events it doesn't really matter to be able to zoom in, but it'd be great to explore the birth of the universe on this timeline. Storage wise it's already supporting such precision, but the UI (which was made for the 1900-2100 range initially) still has issues.
Hi, I'm sorry for that, my backend is struggling a bit I didn't expect to be on the front page so soon.
On https://www.diena.co/everything/ there is a page with a video if you want to see how it looks and behaves.
Hi, thank you for giving it a try ! I test both on Firefox (152) and Chrome, mobile and desktop.
If you don't mind please send me ([email protected]) the error message that appears in the console.
> Doesn't the unrolled version skip the speculation for three out of every four entries ?
It does, but what matters is removing data dependencies often enough. By only speculating once every 4 items, we're lowering the average number of instructions per iteration (from 16 to 7.7). In the meantime, and thanks to value speculation, the CPU is still able to start working on 4 next items while processing the current loop iteration.
Indeed it's not pure unrolling of the second function.
> Will it end up worse than the "naive" version due to all the branch mispredictions?
If the data is allocated randomly, then the next cell prediction will often be wrong. In turn, the branch predictor of the CPU will predict that the prediction is wrong and won't continue execution with the predicted value. So it's the same behavior as the original implementation. So the overhead is not due to branch misprediction, but to additional cycles needed to compute the predicted value.
If the data is allocated in chunks, then the optimization remains useful as the cost of rolling back the CPU pipeline is not that much (I tested with the original list cut in 10 chunks and it added 100ms caused by 100k additional branch misses).