Thoughts on Aspen/Terrace comparing to sortledton?

[HuangLED]

Not exactly an issue per se.

I've read the paper thoroughly, great piece of work! and I saw related work mentioned aspen and terrace, but no further discussion on these two.

What would be the pros and cons comparing sortledton to aspen/terrace? Much appreciated and I understand the opinion could be biased, still super valuable for me. Actually would be great supplementary to the objective view in the paper. :-)

[whatsthecraic]

This is a question for the authors of Sortledton: @PerFuchs , @domargan. I'm not sure they man this forum though.

[HuangLED]

Didn't realize it until you point it out! Thank you.

[PerFuchs]

Hi, Aspen and Terrace are both very strong papers. I'm happy to have a Skype call as well. Measurements with them would be very interesting to see in direct comparison to the other data structures in our paper. Without measurements, I can only give you a qualitative comparison. All is written from the top of my head. My last read of all three papers was two years ago. Qualitative comparisons: the biggest difference between Sortledton and both other structures is that * Sortledton is optimized for single edge insertions while the other two for batched edge insertions. This manifests mostly in their concurrency control. It is likely that all data structures could handle both scenarios. * Sortledton focussed on simplicity, easy parallelisation and reuse while both other systems need more data structures which are also more complex than what we used. * aspen and terrace compress their data by difference encoding. This is in particular beneficial as the graph algorithms of Aspen‘s research group are memory bandwidth bound - according to a short conversation with their students on the VLDB. Sortledton’s design would allow for the same encoding but it will not combine well with single edge updates * terrace uses three data structures to encode neighbourhoods. They have the property of continuous memory for medium size neighbourhoods which is beneficial but comes at the cost of a high complexity data structure and hard parallelisation. They also inline small neighbourhoods in the index. Our experiments indicate that this could be a trade off towards analytical and gpm workloads and against traversals due to a larger index taking more cache space. I redacted my hypothesis on what makes the biggest quantitative differences as I believe the only scientific way to get to these is actually measuring. Again that’s written off my memory from a year or two ago. Take it with a grain of salt. Ruoyun Huang ***@***.***> schrieb am Do. 3. Aug. 2023 um 05:17:

…

Didn't realize it until you point it out! Thank you. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPGZQCWEMNCZK5F3P4EPD3XTMJ5RANCNFSM6AAAAAA2TQKBSA> . You are receiving this because you were mentioned.Message ID: ***@***.***>