lortex

Hi, thanks you're right, I have tested mouse and mobile browsing but missed trackpad usage. I'll update the behavior !

Hi, to be clear, this project is a view of the Wikidata knowledge graph. Some parts of Wikidata come from automatic extraction of Wikipedia articles and other sources, which I am not responsible of. For each event there is a link to Wikipedia and a link to Wikidata, the latter can be used to fix mistakes. I will import an updated dataset at some point.

Happy to integrate feedback on the UI part of this project, as I've started doing thanks to some of the other HN comments. I can assure you that this code was written by my hands, line by line, and that each bug is my own !

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.

It is quite strange indeed, it's probably a bug in the visualization because in my database I see that Kellie's Castle has a low rank.

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 (lucas@pluvina.ge) the error message that appears in the console.

Hi, thank you for your comment.

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).