Showing papers by "Ulrich Meyer published in 2011"
TL;DR: Drawing conclusions on how to design scalable energy-efficient systems for processing large data sets, such as combining relatively weak computing power with high bandwidth storage devices, are led.
15 citations
18 Apr 2011
TL;DR: A tight lower bound is proved for the running times of Bellman-Ford on a class of sparse graphs with O(n) nodes and edges and a lower bound for the approximate bucket implementation of Dijkstra's algorithm is lifted.
Abstract: Despite disillusioning worst-case behavior, classic algorithms for single-source shortest-paths (SSSP) like Bellman-Ford are still being used in practice, especially due to their simple data structures. However, surprisingly little is known about the average-case complexity of these approaches. We provide new theoretical and experimental results for the performance of classic label-correcting SSSP algorithms on graph classes with non-negative random edge weights. In particular, we prove a tight lower bound of Ω(n2) for the running times of Bellman-Ford on a class of sparse graphs with O(n) nodes and edges; the best previous bound was Ω(n4/3-e). The same improvements are shown for Pallottino's algorithm. We also lift a lower bound for the approximate bucket implementation of Dijkstra's algorithm from Ω(n log n/ log log n) to Ω(n1.2-e). Furthermore, we provide an experimental evaluation of our new graph classes in comparison with previously used test inputs.
4 citations
01 Jan 2011
TL;DR: Authors of this report participated in the Sort Benchmark contests in 2009 and 2010, and TritonSort took over the lead in the Indy Minute and Indy Gray categories, although beating DEMSort by a few percent, which was considered a tie in the Gray case by the committee.
Abstract: Authors of this report participated in the Sort Benchmark contests in 2009 and 2010. In 2009, our DEMSort program took the lead in the then-new Indy Gray category [RSSK09, RSS10], sorting 100 TB on a cluster with about 200 nodes. A tie was declared with Yahoo, whose Hadoop-based program achieved about the same result in the Daytona class, but with 17 times the hardware effort. Former results in the then-expired Indy Terabyte category were outperformed by a factor of 3–4, the same for the Indy Minute results, beating Yahoo’s new Daytona Minute result by almost a factor of 2. In 2010, our group focused on energy efficiency [BMSS10b, BMSS10a]. With specifically selected hardware, namely a machine featuring an Atom processor and four solid state disks, we improved the records in the different Indy and Gray size categories by factors of up to 5. For the 10 GB inputs, we were slightly beaten by FAWNsort [VTA10] though. However, the better result of FAWNsort is mostly due to the large 12 GiB of RAM, which fits the whole input, so this approach does not scale much further. Due to disk space restrictions, we had not been able to submit a valid result for the 1 TB Daytona Joule category. To fill in this gap, we have run this category on a standard server machine, and report the results here. In the meantime, in 2010, TritonSort [RMM10] took over the lead in the Indy Minute and Indy Gray categories, although beating DEMSort by just a few percent, which was considered a tie in the Gray case by the committee. Just as DEMSort, TritonSort exploits the given hardware very well, it uses about the same number of disks. However, the described algorithm is quite basic, and seems to work well only for uniformly distributed input, but not in general. In particular, it is unclear how the distribution step works. Sampling or something similar is not mentioned, so the splitters are probably hard-coded for the Sort Benchmark input. Worst-case inputs would probably crash the program due to bad load-balance and out-of-space problems. In contrast to that, DEMSort gives worst-case guarantees. In order to be competitive using a machine with little computational power, we had tuned our algorithms already for our 2010 JouleSort submissions. These improvements included using one file per sorted run instead of one file per block, using radix sort for the internal sorting, reading/writing many blocks at once where possible (range I/O), and fixing a bug that prevented full overlap of I/O with computation and communication. By utilizing the improved version, we hoped for just a small improvement, in order to regain the lead. However, none of the improvements has helped for Minute Sort, where there is only one pass and one sorted run, and sorting does not have to be in-place. So we had to resort to the 100 TB case, running the improved DEMSort program on the same machine as in 2009.
1 citations