Fast and Delay-Robust Multimodal Journey Planning
Authors:
Dominik Bez,
Jonas Sauer
Abstract:
We study journey planning in multimodal networks consisting of public transit plus an unrestricted transfer mode (e.g., walking or cycling). In order to provide good results in practice, algorithms must account for vehicle delays. Delay-responsive algorithms receive a continuous stream of delay updates and must return optimal journeys in the currently known delay scenario. Updates are incorporated…
▽ More
We study journey planning in multimodal networks consisting of public transit plus an unrestricted transfer mode (e.g., walking or cycling). In order to provide good results in practice, algorithms must account for vehicle delays. Delay-responsive algorithms receive a continuous stream of delay updates and must return optimal journeys in the currently known delay scenario. Updates are incorporated in an update phase, which must be fast (e.g., a few seconds). The fastest known approach for multimodal journey planning is ULTRA, which precomputes shortcuts representing transfers between vehicles. This allows query algorithms to find Pareto-optimal journeys regarding arrival time and the number of public transit trips without any performance loss compared to pure public transit networks. However, the precomputation phase does not account for delays and is too slow to rerun during the update phase. We present Delay-ULTRA, a delay-responsive variant of ULTRA. Since accounting for all theoretically possible delays would yield an impractically large set of shortcuts, our approach precomputes shortcuts that are provably sufficient as long as delays do not exceed a configurable limit (e.g., 5 minutes). To handle delays above the limit (which are less frequent in practice), we propose a heuristic search for missing shortcuts that is fast enough to be run during the update phase. Our experimental evaluation on real-world data shows that Delay-ULTRA fails to find less than 0.02% of optimal journeys on metropolitan and mid-sized country networks, and 0.16% on the much larger Germany network. Considering that the available delay information in realistic applications is never perfectly accurate, these error rates are negligible. Query speed is at most twice as slow as ULTRA without delay information, and up to 8 times faster than the fastest exact algorithm, which does not require a preprocessing phase.
△ Less
Submitted 3 November, 2023; v1 submitted 31 October, 2023;
originally announced October 2023.
High Performance Construction of RecSplit Based Minimal Perfect Hash Functions
Authors:
Dominik Bez,
Florian Kurpicz,
Hans-Peter Lehmann,
Peter Sanders
Abstract:
A minimal perfect hash function (MPHF) bijectively maps a set S of objects to the first |S| integers. It can be used as a building block in databases and data compression. RecSplit [Esposito et al., ALENEX'20] is currently the most space efficient practical minimal perfect hash function. It heavily relies on trying out hash functions in a brute force way. We introduce rotation fitting, a new techn…
▽ More
A minimal perfect hash function (MPHF) bijectively maps a set S of objects to the first |S| integers. It can be used as a building block in databases and data compression. RecSplit [Esposito et al., ALENEX'20] is currently the most space efficient practical minimal perfect hash function. It heavily relies on trying out hash functions in a brute force way. We introduce rotation fitting, a new technique that makes the search more efficient by drastically reducing the number of tried hash functions. Additionally, we greatly improve the construction time of RecSplit by harnessing parallelism on the level of bits, vectors, cores, and GPUs. In combination, the resulting improvements yield speedups up to 239 on an 8-core CPU and up to 5438 using a GPU. The original single-threaded RecSplit implementation needs 1.5 hours to construct an MPHF for 5 Million objects with 1.56 bits per object. On the GPU, we achieve the same space usage in just 5 seconds. Given that the speedups are larger than the increase in energy consumption, our implementation is more energy efficient than the original implementation.
△ Less
Submitted 5 July, 2023; v1 submitted 19 December, 2022;
originally announced December 2022.
