Weitere Extraktionsmethoden
3.1 Out-of-Core-Methoden
Chiang und Silva haben in [10] und [11] beschrieben, wie man eine Isofl¨achen-Extraktion bei knappem Speicherplatz durchf¨uhren kann. Ferner zeigen die beiden Autoren zusammen mit Farias und Wei in [9], wie sich das daf¨ur benutzte Prinzip der Out-of-Core-Extraktion auf einem Rechner mit mehreren Prozessoren anwenden l¨asst.
Die Grundidee der Out-of-Core-Extraktion ist es, die Volumendaten und die Suchstruktur auf der Festplatte oder einem ¨ahnlichen Datentr¨ager zu speichern und jeweils nur den Teil in den Haupt-speicher einzulesen, der f¨ur die Suche gebraucht wird. Unter Verwendung dieses Prinzips haben Chiang/Silva drei verschiedene Suchprinzipien realisiert, n¨amlich eine volumendaten-orientierte Blocksuche und eine Suche im Intervallbaum sowie im Segmentbaum, einer verallgemeinerten, nicht bin¨aren Version des Intervallbaums.
22
CCCCCCC
Abbildung 3.1: Ein Netz von Polygonen oder Polyedern wird in Metazellen zerlegt, die in einem gemeinsamen Block der Festplatte abgelegt sind. Im oberen Bild sind die Polygone die bei der
¨ublichen Extraktion verwendeten Zellen. Im unteren Beispiel sieht man, dass diese Methode auch auf ungleichm¨aßige Netze anwendbar ist.
3.1.1 Blockorientierte Out-of-Core-Extraktion
Bei der blockorientierten Out-of-Core-Extraktion wird die Liste aller Zellen des Volumen-Datensatzes wie in Abbildung 3.1 in Bl¨ocke, so genannte Metazellen verteilt, deren Informatio-nen auf jeweils einem Speicherblock der Festplatte abgelegt sind. Ferner wird ein Index angelegt, der zu jedem Block das Minimum und das Maximum der darin enthaltenen Volumendaten bein-haltet und so zu jedem Isowert die Suche nach den Metazellen erleichtert, die Teile der Isofl¨ache enthalten.
3.1.2 Intervallbaum-orientierte Out-of-Core-Extraktion
Von der intervallbaum-orientierten Out-of-Core-Extraktion haben Chiang und Silva zwei Versio-nen realisiert. Bei der ersten Version benutzen sie keine echten Intervallb¨aume, sondern so genann-te Segmentb¨aume. Diese ungenann-terscheiden sich von den Ingenann-tervallb¨aumen dadurch, dass jeder Knogenann-ten nicht nur zwei, sondern mehr Nachfolger haben kann. Ein Knoten des Segmentbaums enth¨alt je-weilsnUnterteilungswerteγ(0), ..., γ(n−1),n+ 1Zeiger auf Nachfolgerknoten, jenZeiger auf left- und right-Listen und n(n2−1) Zeiger aufmulti-Listen. Dieleft- undright-Listen entsprechen dermin- undmax-Liste im Intervallbaum und fassen jeweils die Intervalle zusammen, deren linke
γ(0) γ(1) γ(2)
0 1 2 3
left(0),left(1),left(2)
right(1),right(2),right(3)
multi(1,1),multi(1,2), multi(2,2)
γ(0) γ(1) γ(2)
0 1 2 3
left(0)
left(1)
left(2)
multi(1,1)
right(3) right(1)
right(2)
multi(1,2)
multi(2,2)
Abbildung 3.2: Ein Knoten des Segmentbaums. Darunter ist die zugeh¨orige Einordnung von Bei-spielintervallen in die left-, right- und multi-Listen dargestellt, wobei jedes Intervall als Linie dargestellt ist.
bzw. rechte Grenze im selben Bereich (Slab) der Form [γ(i), γ(i+ 1)) liegen. Diemulti-Listen fassen die Intervalle zusammen, die einen oder mehrere dieser Bereiche vollst¨andig ¨uberdecken (Multislabs). Unber¨ucksichtigt bleiben dabei nur die Intervalle, die ganz in einem Bereich enthal-ten sind. Diese werden an den entsprechenden Nachfolgerknoenthal-ten weitergegeben. In Abbildung 3.2 ist ein Beispielknoten eines Segmentbaums mit der zugeh¨origen Verteilung der Intervalle auf die Slabs und Multislabs dargestellt.
Bei der zweiten Version werden wirklich Intervallb¨aume auf der Festplatte gespeichert. Damit ein Datenblock des Speichermediums voll ausgenutzt werden kann, wird darin wie auf Abbil-dung 3.3 ein Ausschnitt des Baums mit mehreren Knoten gespeichert. Außer den Bl¨ocken, die Intervallbaum-Knoten enthalten, gibt es bei diesem Prinzip auch Min- und Maxlistenbl¨ocke, die nach Bedarf sequentiell gelesen werden, sowie Restzellenbl¨ocke, die dann verwendet werden, wenn eine Liste von Zellen in einem Teil des Intervallbaums vollst¨andig in einen Datenblock passt.
In diesem Fall werden die Zellen als Liste in einen Block gespeichert, anstatt die Konstruktion des Intervallbaums fortzusetzen.
Ich habe die Out-of-Core-Methode mit den echten Intervallb¨aumen ebenfalls realisiert und sowohl
Minliste Maxliste Minliste ...
Abbildung 3.3: Ein Ausschnitt des Intervallbaums, der nach Chiang/Silva in einem Block der Fest-platte gespeichert wird. Im dargestellten Beispiel werden 7 Knoten in 3 Leveln gespeichert, was bei einem Speicherbedarf von 24 Byte pro Knoten zu einem gesamten Speicherbedarf von 168 Byte pro Block f¨uhrt.
einzeln als auch als Wahlm¨oglichkeit f¨ur die Conditioned Trees ausgetestet. Hier folgen nun einige numerische Ergebnisse, in denen der Speedup-Faktor gegen¨uber der Brute-Force-Methode und der ben¨otigte Festplattenspeicher gemessen wurden.
Datensatz (Format) Speedup-Faktor Festplattenspeicher (MB)
Engine 256 (256×256×110) 31 85
Bighead 256 (256×256×225) 47 161
ScannedBrain400 (384×400×276) 21 641
Bunny (360×512×512) 97 1131
Von Prof. Dr. Daniel Keim stammte die Idee, bei der Out-of-Core-Extraktion mehrere Datenbl¨ocke unmittelbar nacheinander zu lesen, um die Suchzeit zu beschleunigen. Ich habe dieses Experiment f¨ur den ScannedBrain-Datensatz durchgef¨uhrt und herausgefunden, dass tats¨achlich geringf¨ugige Unterschiede in der Extraktionszeit bestehen, n¨amlich dass die bestm¨ogliche Suchzeit bei ca. 5 Datenbl¨ocken (2,5 kB) pro Leseoperation erreicht wird. Da der gr¨oßte Teil der Suchzeit f¨ur den Aufbau der Zellenliste ben¨otigt wird, ist der Unterschied jedoch geringf¨ugig und liegt bei einem Prozent, also f¨ur mein Beispiel im Bereich der Messgenauigkeit. Eine zuf¨allige Messung dieses Unterschieds ist jedoch auszuschließen da jeder der aufgelisteten Werte mehrmals gemessen wur-de, um die Tendenz zu best¨atigen.
Leseoperation (kB) Extraktionszeit (s)
Die Suche nach der optimalen Verwendung der Out-of-Core-Methode in Conditioned Trees ha-be ich eha-benfalls durchgef¨uhrt. Das Problem daha-bei ist allerdings, dass die Out-of-Core-Extraktion außer dem Hauptspeicher eine weitere Hardware-Komponente verwendet, n¨amlich den Festplat-tenspeicher. In Berichten, die sich haupts¨achlich mit Out-of-Core-Methoden besch¨aftigen, wird meistens stillschweigend vorausgesetzt, dass Festplattenspeicher kostenlos und in beliebiger Men-ge zur Verf¨ugung steht, was ich f¨ur unrealistisch halte. Aus diesem Grund habe ich den verwende-ten Festplatverwende-tenspeicher in die Kosverwende-tenformel einbezogen, jedoch nicht genauso stark bewertet wie den Hauptspeicher, sondern mit einem KostenfaktorHversehen, der dem Programm als Parameter
¨ubergeben werden kann.
Out-of-Core-Methoden werden in vielen Arbeiten ¨uber Isofl¨achen-Extraktion beschrieben. Ich pers¨onlich glaube, dass Out-of-Core-Verfahren keine gute Zukunft haben, weil die Prozessoren der modernen Computermodelle immer schneller werden, w¨ahrend die Entwicklung bei externen Speichermedien nicht so schnell ist. Ein Grund daf¨ur liegt darin, dass es einfach ist, einen Prozessor gegen einen schnelleren auszutauschen, ohne daf¨ur viel an der Hardwareumgebung zu ver¨andern.
Wenn hingegen das externe Medium beschleunigt wird, ist das mit gr¨oßerem Aufwand verbun-den, weil daf¨ur die Schnittstelle des Rechners angepasst werden muss (ein Speichermedium kann immer nur so schnell sein, wie der Zugriff auf ihn erfolgt). Oft muss daf¨ur auch eine ganz neue Norm eingef¨uhrt werden, weil den h¨aufig benutzten Speichermedien wie Disketten, CDs und Fest-platten einer vorgegebenen Architektur, schon durch die physikalischen Gegebenheiten nat¨urliche Grenzen gesetzt werden.