Ich werde den Kauf der nächsten CPU davon abhängig machen, ob es sich für meine Zwecke (;%kaum Spiele, aber Videoschnitt, MP3, 3D-Animationen/Modeling) lohnt. THG listet deutlich schnelleres MPEG-4/H.264 und etwas schnelleres MPEG-2 Encoding für Quad-Core CPUs von Intel, aber nutzt als Referenz den Mainconcept Codec sowie Pinnacle Studio 11 Plus. Da ich beides nicht verwende, würden mir die 4 Kerne nichts bringen, wenn meine SW nur Dual unterstützt.
Weiß jemand, ob TMPEG Enc. 2.5x Plus, Premiere Pro 2 (;oder Essential 3.x) und TMPEG DVD Author 2.x (;3.x soll angeschafft werden), sowie VirtualDUB für H264/AVC Codec Quad's unterstützen bzw. daraus einen nennenswerten Nutzen (;im Vergleich mit Dual-Core) ziehen?
Derzeitige CPU ist PentiumD805 @ 2x3GHz. OS soll so lange als möglich XP bleiben.
Xpost & f'up
Antwort von Sebastian Kaps:
Christian Grünwaldner schrieb:
> Studio 11 Plus. Da ich beides nicht verwende, würden mir die 4 Kerne > nichts bringen, wenn meine SW nur Dual unterstützt.
Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt. Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten Threads abgehandelt werden - dann sorgt das Betriebssystem für eine möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs - oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung stehen.
-- Ciao, Sebastian
Antwort von Christian Potzinger:
Sebastian Kaps maltreated the Keyboard with following:
> Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung stehen.
Ack. Man muss allerdings sicher stellen, dass das OS (;meine W2K Version unterstützt max. 2) alle CPUs unterstützt. -- ryl: G'Kar
Antwort von Sebastian Kaps:
Christian Potzinger schrieb:
> Ack. Man muss allerdings sicher stellen, dass das OS (;meine > W2K Version unterstützt max. 2) alle CPUs unterstützt.
Das ist bei XP ja der Fall.
-- Ciao, Sebastian
Antwort von Jens Heydekorn:
Hallo,
ich kann nicht sagen, ob die von Dir genannten Applikationen auf Multi-Core-CPUs schneller arbeiten.
Doch ist es prinzipiell unerheblich, wie viele Kerne die CPU hat, wenn der Algorithmus nicht geeignet ist. Oder anders herum formuliert: Sollte =
ein Programm einen Vorteil aus zwei Kernen ziehen, so kann bzw. könn= te es auch einen Vorteil aus noch mehr Kernen ziehen. Allerdings hängen die Geschwindigkeitsvorteile von einer Reihe von Faktoren ab, die Theorie und Praxis abweichend erscheinen lassen. Hier sind die Praxistests von THG nützlich, doch allg. Rückschlü= sse erlauben diese nicht.
Gruß -JH
Antwort von Norbert Müller Christian Grünwaldner schrieb: > Siehe Betreff. > > Ich werde den Kauf der nächsten CPU davon abhängig machen, ob es sich > für meine Zwecke (;%kaum Spiele, aber Videoschnitt, MP3, > 3D-Animationen/Modeling) lohnt. THG listet deutlich schnelleres > MPEG-4/H.264 und etwas schnelleres MPEG-2 Encoding für Quad-Core CPUs > von Intel, aber nutzt als Referenz den Mainconcept Codec sowie > Pinnacle Studio 11 Plus. Da ich beides nicht verwende, würden mir die > 4 Kerne nichts bringen, wenn meine SW nur Dual unterstützt. > > Weiß jemand, ob TMPEG Enc. 2.5x Plus, Premiere Pro 2 (;oder Essential > 3.x) und TMPEG DVD Author 2.x (;3.x soll angeschafft werden), sowie > VirtualDUB für H264/AVC Codec Quad's unterstützen bzw. daraus einen > nennenswerten Nutzen (;im Vergleich mit Dual-Core) ziehen? > > Derzeitige CPU ist PentiumD805 @ 2x3GHz. OS soll so lange als möglich > XP bleiben.
DVD-Author 2.0 (;verwende ich auch): http://tmpgenc.pegasys-inc.com/de/product/tda20.html Optimiert für Intel Pentium4 Prozessor mit HT-Technologie
DVD-Author 3.0: http://tmpgenc.pegasys-inc.com/de/product/tda3d.html Optimiert für Intel Pentium4 Prozessor mit HT-Technologie und Intel® CoreT 2 Duo Prozessor
TMPGEnc Plus 2.5 http://tmpgenc.pegasys-inc.com/de/product/tp.html Optimized for Intel® Pentium®4 processor with HT technology
Ausser der höheren Rechenleistung eines Quad-Core wird also von den Programmen her nichts zu erwarten sein - wobei ich mich frage, wie das mit der Programmoptimierung geht.
Mein Problem derzeit ist, dass die neuen DirectX 10 Grafikkarten für Avid/Pinnacle Liquid Edition ein Problem darstellen - das Programm funktioniert damit nicht. http://forums.pinnaclesys.com/forums/thread/45551.aspx - muß mich einmal durch diesen Wust an englischsprachigen Zuschriften durchkämpfen :-(; Habe auch aus diesem Grund noch immer ein i865/Pentium 4HT System mit ATI X800GT, würde aber gerne auf ein P35 Board wechseln, auch wenn dessen Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt kühl und leise und bietet min. 256bit-Anbindung an 512MB Speicher?
Gruß, Norbert
Antwort von Heiko Nocon:
Sebastian Kaps wrote:
>Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt.
Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder?
>Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten >Threads abgehandelt werden - dann sorgt das Betriebssystem für eine >möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs - >oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung >stehen.
Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht ab und an noch einen dritten, wenn's im Haupthread der Anwendung (;Benutzeroberfläche) etwas zu tuen gibt.
Auch der Ausweg, einfach immer sehr viele Threads zu erzeugen und dem OS die Arbeit zu überlassen, sie möglichst effizient laufen zu lassen, ist kein wirklicher Ausweg.
Zum einen gibt es nämlich mehr als genug nicht parallelisierbare Probleme, die lassen sich einfach nicht in Threads aufsplitten, zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.
Und zum anderen erzeugen Threads auch einen gewissen Verwaltungsoverhead, der mit der Zahl der Threads überproportional ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32 Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur Verfügung hat.
D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die effektive Rechenleistung wenigstens annähernd proportional mit der Zahl der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl der Kerne mit freier Rechenzeit als Bezug nehmen).
Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der Realität leider auch von System zu System. Es ist also praktisch unmöglich, eine Software zu schreiben, die auf jedem System optimal läuft.
Antwort von Sebastian Kaps:
Heiko Nocon schrieb:
>> Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt. > Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder?
Windows? Ja, da war mal was. Dort ist das aber keine Einschränkung der Software, sondern der Lizenz. (;Und, ja, es gibt natürlich Software, die explizit nur eine CPU unterstützt.)
> Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine > zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von > vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht > ab und an noch einen dritten, wenn's im Haupthread der Anwendung > (;Benutzeroberfläche) etwas zu tuen gibt.
So gesehen richtig, nur funktioniert das so nicht. Wenn eine Software gleichzeitig auf mehr als einer CPU laufen soll, dann fängt der Entwickler nicht an und "zerlegt Aufgaben in zwei Threads", sondern er wird sämtliche Aufgaben in soviele Threads wie (;sinnvoll) möglich kapseln.
Der Schritt von Software für eine CPU zu Software, die auf mehreren CPUs läuft ist groß, weil man die entsprechenden Aufgaben erstmal in Teilaufgaben unterteilen muß und man sich bei parallel laufenden Threads einige Gedanken über Synchronisierung der Threads und die Konsistenz der Daten machen muß. Hat man das erstmal getan, dann ist es egal, ob die Software auf 2 oder 200 CPUs läuft.
> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare > Probleme, die lassen sich einfach nicht in Threads aufsplitten, > zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.
Ich gehe mal davon aus, daß das Encoding von Videos durchaus gut parallelisierbar ist.
> Und zum anderen erzeugen Threads auch einen gewissen > Verwaltungsoverhead, der mit der Zahl der Threads überproportional > ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32 > Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur > Verfügung hat.
Ja. Und? Deswegen (;u.a.) ist ein Quad-Core-Rechner auch nicht doppelt so schnell wie ein Dual-Core-Rechner. Das war aber nicht das Thema.
> D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die > effektive Rechenleistung wenigstens annähernd proportional mit der Zahl > der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares > Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend > der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl > der Kerne mit freier Rechenzeit als Bezug nehmen).
Letzteres ist Aufgabe des Betriebssystems und nicht der Anwendung.
> Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich > ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der > Realität leider auch von System zu System. Es ist also praktisch > unmöglich, eine Software zu schreiben, die auf jedem System optimal > läuft.
Stimmt. Hat aber mit dem Thema nix zu tun ;-)
-- Ciao, Sebastian
Antwort von Christian Schroeder:
Heiko Nocon schrieb: > Sebastian Kaps wrote: > >> Es gibt keine Software, die eine explizite Anzahl CPUs unterstützt. > > Doch, natürlich. Windows z.B. Da hast du doch schonmal von gehört, oder? > >> Entweder ist die Software so geschrieben, daß Teilaufgaben in separaten >> Threads abgehandelt werden - dann sorgt das Betriebssystem für eine >> möglichst optimale Verteilung auf die zur Verfügung stehenden CPUs - >> oder eben nicht. Es ist dann unerheblich, ob 2 oder 4 CPUs zur Verfügung >> stehen. > > Nein, das stimmt so natürlich auch nicht. Wenn eine Anwendung eine > zeitaufwendige Aufgabe z.B. in zwei Threads zerlegt, dann hat sie von > vier Cores genau garnix, sondern nutzt maximal zwei davon und vielleicht > ab und an noch einen dritten, wenn's im Haupthread der Anwendung > (;Benutzeroberfläche) etwas zu tuen gibt. > > Auch der Ausweg, einfach immer sehr viele Threads zu erzeugen und dem OS > die Arbeit zu überlassen, sie möglichst effizient laufen zu lassen, ist > kein wirklicher Ausweg.
Der Programmierer zerlegt die Aufgabe nicht in eine feste Anzahl von Threads, sondern nutzt z.B. das MPI-Konzept. Da wird im Grunde eine Warteschlange von parallel zu verarbeitenden Daten erstellt und dann von den Prozessoren abgearbeitet. Wenns zwei sind, machen das zwei, oder eben vier oder oder. Lediglich die Datenmenge (;und ihre Struktur) bestimmen, wie viele Prozessoren man sinnvoll nutzen kann.
> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare > Probleme, die lassen sich einfach nicht in Threads aufsplitten, > zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden.
Wie Sebastian schon sagte, sollte das bei Videocodierung nicht so sein. > > Und zum anderen erzeugen Threads auch einen gewissen > Verwaltungsoverhead, der mit der Zahl der Threads überproportional > ansteigt. Es ist also kontraproduktiv, ein Problem in meinetwegen 32 > Threads zu zerlegen, wenn man nur zwei Cores für deren Abarbeitung zur > Verfügung hat.
Wie gesagt: Die Anzahl der Prozessoren wird nicht hart codiert.
> D.h: Um eine zunehmende Anzahl von Kernen so zu benutzen, daß die > effektive Rechenleistung wenigstens annähernd proportional mit der Zahl > der Kerne wächst, muß eine Anwendung nicht nur ein parallelisierbares > Problem bearbeiten, sondern außerdem die Zahl der Threads entsprechend > der Zahl der Kerne anpassen (;erste Näherung, eigentlich muß sie die Zahl > der Kerne mit freier Rechenzeit als Bezug nehmen). > > Das umzusetzen, ist alles andere als einfach. Das Problem kann man sich > ja sowieso nicht aussuchen und die Zahl der Kerne ändert sich in der > Realität leider auch von System zu System. Es ist also praktisch > unmöglich, eine Software zu schreiben, die auf jedem System optimal > läuft.
Das ist natürlich richtig, gilt aber nicht in Bezug auf die Anzahl der Kerne.
-- Gruß Chris Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren
Antwort von Andreas Erber:
Norbert Müller wrote:
> dessen Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt > kühl und leise und bietet min. 256bit-Anbindung an 512MB Speicher? >
Ich hab gute Erfahrungen mit einer Club3D Ati Radeon X1952TX gemacht, im idle ist die genauso leise wie mein Dell Dimension 9150, der nicht unhörbar leise ist, aber so unterm schreibtisch nicht weit davon entfernt. Wenn man spielt dreht der Lüfter natürlich auf, aber das macht der CPU Lüfter auch und man hört beide deutlich aber nicht unangenehm.
Allgemein liest man dass die Club3D Karten das mit der Kühlung ganz ordentlich hinbekämen, evtl bestellst dir mal eine von denen, kannst sie ja dank Fernabsatzgesetz wieder zurücksschicken wenn sie doch zu laut ist.
LG Andy
Antwort von Norbert Müller Andreas Erber schrieb: > Norbert Müller wrote: > >> dessen Northbrige ziemlich heiss wird. Doch welche Grafikkarte bleibt >> kühl und leise und bietet min. 256bit-Anbindung an 512MB Speicher? >> > > Ich hab gute Erfahrungen mit einer Club3D Ati Radeon X1952TX gemacht, > im idle ist die genauso leise wie mein Dell Dimension 9150, der nicht > unhörbar leise ist, aber so unterm schreibtisch nicht weit davon > entfernt. Wenn man spielt dreht der Lüfter natürlich auf, aber das > macht der CPU Lüfter auch und man hört beide deutlich aber nicht > unangenehm. > Allgemein liest man dass die Club3D Karten das mit der Kühlung ganz > ordentlich hinbekämen, evtl bestellst dir mal eine von denen, kannst > sie ja dank Fernabsatzgesetz wieder zurücksschicken wenn sie doch zu > laut ist.
Vielen Dank, ich hab' nämlich derzeit überhaupt keine Ahnung von den GraKa's, meine Sapphire Radeon X800GT, im Vorjahr um teure 200.- gekauft, 256MB/256bit (;AGP) reicht an sich für mein Videoschnittsystem in DV, jedoch sollte mein überarbeiteter PC auch für HDV-Schnitt passen. Dafür wird eine AGP/besser PCIe-Karte mit 256/besser 512MB empfohlen*, sonst keine Angaben. Und Spiele spiele ich keine.
Drum auch meine Frage, es könnte doch vielleicht auch einfacher/leistungsschwächer gehen als mit der X1952TX? Habe die Radeon HD 3850 entdeckt, die soll auch relativ kühl und sehr leise laufen, am liebsten wäre mir jedoch eine HD 2600 (;Pro oder XT, keine Ahnung, was der Unterschied ist), leider hat die nur 128bit Speicheranbindung, auch bei 512 MB, jedoch auch eine Controller-Ringleitung mit 256bit -- wiederum keine Ahnung, ob das die 128bit aufmotzt.
Für OpenGL (;3D) und sehr viele Spuren in der Timeline verwenden die Semiprofis (;*auf Videoschnittsystem Avid/Pinnacle Liquid Edition, das ich auch verwende) Grafikkarten-Monster wie GeForce 7800, so eine Zusatzheizung will ich aber nicht haben. So 35-50 Watt würden mir reichen - die Matrox-Karten haben nur 12 Watt, sind angeblich auch für Video geeignet, haben aber nur 64bit oder 128 bit an 256 MB und das Schnittsystem rendert viele Effekte über die GPU.
VG, Norbert
Antwort von Heiko Nocon:
Sebastian Kaps wrote:
>Wenn eine Software >gleichzeitig auf mehr als einer CPU laufen soll, dann fängt der >Entwickler nicht an und "zerlegt Aufgaben in zwei Threads"
Doch, du wirst lachen, genau so wird auf breiter Front existierende Software erstmal notdürftig "multicoretauglich" gemacht. Leicht isolierbare Teilaufgaben werden explizit in getrennte Threads gepackt und laufen dann (;weil eigentlich nicht parallelisierbar) in einer Art "daisy chain", teilweise sogar mit busy loops als Synchronisation. (;Wohl, um die Core-Auslastung den erwünschten 100% besser anzunähern)
Extrem traurig und kaum zu glauben, aber ganz real an sehr vielen kommerziellen Produkten zu bewundern, auch und gerade im Bereich Video-Encoder...
Natürlich sind die Dinger so immer noch schneller als auf einem Einzelkern, aber deutlich langsamer, als sie sein könnten.
Antwort von Christian Schroeder:
Marcus Jodorf schrieb: > Christian Schroeder schrieb: > >>> Zum einen gibt es nämlich mehr als genug nicht parallelisierbare >>> Probleme, die lassen sich einfach nicht in Threads aufsplitten, >>> zumindest nicht so, daß die verfügbaren Cores optimal genutzt werden. >> Wie Sebastian schon sagte, sollte das bei Videocodierung nicht so >> sein. > > Nicht wirklich. Das ist genau bei Videokodierung ein Problem. > Denn bei verlustbehafteten Verfahren bestehen gewisse Abhängigkeiten im > Datenstrom, die man beachten muß. Nachfolgeframes bauen z.B. auf > vorhergehenden auf und das kann man nicht mal eben einfach > entserialisieren. > Einige Abhängigkeiten kann man zwar mißachten, was aber zu Lasten der > Effizienz geht -> schlechtere Kompression und/oder > Qualitätsverschlechterung.
Klar muss das Keyframe abgearbeitet sein, um die nächsten Frames zu bearbeiten, aber ab dem nächsten Keyframe gehts doch wieder von vorn los. Das sollte doch kein Problem sein.
-- Gruß Chris Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren
Antwort von Christian Schroeder:
Marcus Jodorf schrieb: > Christian Schroeder schrieb: > >>> Einige Abhängigkeiten kann man zwar mißachten, was aber zu Lasten der >>> Effizienz geht -> schlechtere Kompression und/oder >>> Qualitätsverschlechterung. > >> Klar muss das Keyframe abgearbeitet sein, um die nächsten Frames zu >> bearbeiten, aber ab dem nächsten Keyframe gehts doch wieder von vorn >> los. Das sollte doch kein Problem sein. > > Denk einfach nochmal drüber nach. Wie willst Du z.B. das > Quellmaterial möglichst optimal aufteilen? > > Sagen wir mal, Du würdest jeden Thread jeweils von Keyframe zu Keyframe > (;auf das Ergebnis bezogen!) arbeiten lassen, also GOP basiert. Das wird > dann schon schwierig, wenn man es mit einem Codec zu tun hat, der mit > variablen GOP-Längen arbeitet. > Ein Thread verarbeitet dann beispielsweise drei Quellframes und der > nächste bringt in seiner GOP dann 16 Frames unter und der dritte schafft > aufgrund des Quellmaterials vielleicht 5 Frames, usw. > Problem bei der Geschichte ist halt, daß man nicht unbedingt schon > vorher - wenn man die Quellframes den Threads zuteilt - weiß, wann der > nächste Keyframe gesetzt wird. Selbst wenn man ein Maximalintervall > festlegt, kann es quellmaterialbedingt nötig sein, noch an ganz anderen > Positionen Keyframes zu setzen. > > Kurz: Du kannst vorher nicht wirklich wissen, wieviele Frames ein Thread > jeweils optimal im nächsten Abschnitt bearbeiten sollte. Wo der nächste > Keyframe sitzt, entscheidet sich erst bei der Kodierung. Da hat man also > ein Allokationsproblem bei der Aufteilung der Quellabschnitte. > Um sowas einigermaßen in den Griff zu kriegen, muß man teilweise > erheblichen Aufwand treiben. > > Falls Du das mit den Keyframes oben andersherum meinst und auf das > Quellmaterial bezogen hast, dann hast Du sofort ein Qualitätsproblem.
So meinte ich das.
> Fütterst Du die Threads einfach mit den Frames von Keyframe zu Keyframe > des Quellmaterials, dann ist auch der Thread gezwungen, spätestens mit > dem letzten Frame eine GOP abzuschließen. Je nach Material und Codec > kann das völlig ineffizient sein.
Ich dachte mir das so (;ohne es zuende gedacht zu haben), dass die Threads im Quellmaterial auf Keyframes zugreifen und dann die notwendigen Informationen untereinander austauschen.
-- Gruß Chris Wer Freiheit aufgibt, um Sicherheit zu gewinnen, wird beides verlieren
Antwort von Ka Prucha:
"Marcus Jodorf" schrieb > Ka Prucha schrieb: > >> Ich denke da eher an die Mechanik, > > Was habt ihr nur alle mit Eurem defragmentieren? Selbst MS ist doch > schon lange genug von fat weg, als daß das immer noch die Köpfe so > verseuchen könnte?
Servus
Wir verwenden in der Firma Mutiprozessorsysteme und eine Software bei der explizit die Anzahl der Prozessoren vorgeben werden kann. Ist zwar nicht Video sondern Photogrammetrie, aber das Geräusch der Festplatten zeigt, das es reichlich Zeit ist etwas besseres als diese alte Magnetscheibentechnologie zu verwenden.
Ach ja, FAT verwende ich seit mindestens fünf Jahren nur auf den Speicherkarten diverser Digitalkameras.
Defragmentieren ist normalerweise heute nicht notwendig, sonder eher Unsinn. Ausgenommen man würde wirklich die von dir vorgeschlagene Teilungsstrategie für Videocodierung verwenden.
Wie schon einmal geschrieben, erst bei Solid-State Disks oder vergleichbaren, ist das dann die bessere Strategie.
mfg Ka Prucha
Antwort von Andreas Erber:
Ka Prucha wrote:
> Wie schon einmal geschrieben, erst bei Solid-State Disks oder > vergleichbaren, ist das dann die bessere Strategie.
Auf Solid State Disks sollte es völlig egal sein wie die Daten drauf stehen, da jederzeit auf jeden Datenblock gleich schnell zugegriffen werden kann. Selbst bei Maximalster Fragmentierung sollte sich da kein allzugroßer effekt Einstellen.
LG Andy
Antwort von Ka Prucha:
"Andreas Erber" schrieb > > Auf Solid State Disks sollte es völlig egal sein wie die Daten drauf = stehen, > da jederzeit auf jeden Datenblock gleich schnell zugegriffen werden = kann. > Selbst bei Maximalster Fragmentierung sollte sich da kein = allzugroßer effekt > Einstellen.
Servus
Genau! Allerdings sind die noch dafür zu bezahlenden 250 Euro, bei der = für Video empfehlenswerte Mindestgröße von 32 GB, für Amateure noch in = der oberen Preislage. Ist schon ernsthaft zu überlegen, aber man darf dann nicht traurig sein wenn es nächstes Jahr nur noch die Hälfte kostet.
