Antwort auf: ob allerdings dieser Schritt der richtige war...steht auf einem ganz anderen Blatt!!!
meine teilweise sehr "ollen" PCs laufen gerade wegen der SCSI Controller und Laufwerke ...völlig problemlos und einwandfrei!!!
Ich denke schon. einer der Gründe warum die Vergleichsrechnung Mac zum PC nicht stimmte, war die Unterstützung dieses eher elitären Standards. Das mehr an Leistung rechnet den Mehrreis nicht, zu mindestens nicht für die, die es nicht brauchen. Und die die es brauchen, können's ja in Form von Acard, Atto, Adaptec,... nachrüsten.
Antwort auf: 2) Controller...
auch da soll es welche geben ...die nicht nur einen Kanal haben und verwalten können!!!...demzufolge damit auch schneller reagieren!
Wie das? Einen normalen S-ATA und auch einen 133er ATA Bus bekommt auch eine aktueller 10.000er Platte nicht gesättigt. Insbesondere nicht für das Mengengeschaufel, das vorzugsweise auch beim Auslagern von Bildern anfällt. Bei S-ATA2 wirds völlig illusorisch, das mit weniger als drei Platten überhaupt ausschöpfen zu können.
Antwort auf: 3) RAID ist klar...war aber hier nicht das Thema:))
Dann sollte auch klar sein, das da für einen Zweiten Controller nichts zu tun ist. Evtl. für ne 2. Platte, das wars aber dann auch.
Antwort auf: 4) ATA/SATA....ist nach wie vor ...nicht wirklich schneller wie meine SCSI320,
ob wohl es dauernd "schnell geredet" wurde, bisher ist mir kein Standardsystem bekannt...wo SATA wirklich schnell ist!(außer RAID)
S.o. Flaschenhals ist hier schon lange nicht mehr der Controller, ausser man belastet ihn mit zigtausenden Anfragen kleinster Datenkrümel quer über die Platte, aber auch da geht die ja dann auch in die Knie. Vor allem, kann S-ATA immer noch nicht wirklich gut mit mehreren Medien gleichzeitig umgehen, von daher ist der Effekt weitere Platten anzuhängen eher bescheiden.
Antwort auf: 5) zwei Platten...auf dem PC sicher und wie oben einer bestätigt hat durchaus auch auf dem MAC, denn....(mein lieber Thomas;))....
du weiß ja auch sicher dass Datenfluss kein "Dauerdatenfluss" ist,
sondern in "Schüben" erfolgt....heißt,
wenn Photoshop "irgendwann einfällt" das es auslagern muss...
muss nicht zwangsläufig von der ersten Platte ein Zugriff erfolgen!!!!!!!!!!!
Keine Ahnung was du mir sagen willst. PS an sich ist mehr oder weniger autonom und erfordert erstmal so gut wie keine Plattenzugriffe wenns erstmal läuft. Wenn man mit 1,5GB allein PS an einem 50MB Bild werkelt, kann man die Platte für ne Stunde ausmachen, wenn man nicht gerade sichert, oder eben unsinnig viele Protokollobjekt-Schritte eingestellt hat.
Da ist heute nichts mehr mit Auslagern, zu mindestens nicht in den üblichen Dateigrößen einzelner Bilder. Bei Composings wirds anders, das geht ja je nach Ebenenzahl schon mal gern bis in die GB (wobei das in den allermeisten Fällen auch nicht nötig wäre.)
Antwort auf: DAS ist der Trick...und jetzt sage mir bitte WIESO ein Mac das nicht auch bewältigen könnte???
Kann er doch, und zwar besser als jeder PC (Wiviel RAM kann Windows noch mal z.Z: in Kombination mit Photoshop ansprechen? 2GB, richtig?)
Antwort auf: und nochmal. es ging wohl einzig um die Frage oben, ob PS große Datenmengen anstandslos verdauen kann(?) mit diesem Auslagerungstrick...kann es!
Das war sicherlich nciht die Frage, das konnte PS schon zu Zeiten wo in einem üppig Bestückten REchner 64MB steckten. Zu den Zeiten haben wir schon Bilder von hunderten MB bewältigt, nur eben, in anderen Zeitdimensionen. Ich könnt mich immer beömmeln wenn ich hier so A2 Scan Altlasten mit 140MB aus dem Archiv hole... Datei erzeugt 20:30, Datei zuletzt geändert: 20:34: Das waren nicht mehre Zugriffe, das war ein 'sichern unter' ;-)
Antwort auf: nach meiner Erfahrung können Daten der dreifachen RAM-Größe reingeholt werden(zwar langsam und schleppend...aber es geht, habs ausprobiert)
3? 10? was du willst, du kannst den Speicher für PS ja nahezu beliebig klein drehen, an der Verarbeitbarkeit scheitert es dann eben erst wenn die Auslagerungsdatei zu groß wird, bzw. die Platte dort voll läuft.
Nur mit vernünftigem Arbeiten hat das kaum noch zu tun.
Davon kann man eigentlich nur reden solange die Effiziensanzeige 100% anzeigt, und eben alle Protokollschritte noch in den RAM passen. Das ist in den Allermeisten Fällen der Fall, weil man eher selten komplette Bildberechnungen unmittelbar hintereinander ausführt. Denn nur wenn man z.B: einen Filter auf das komplette Bild anwendet, wird es auch komplett als Protokollobjekt abgelegt. Beim stempeln oder bei Partiellen Änderungen wird nur die aktive Auswahl oder eben auch mal nur eine Pinselspitze an Pixeln weggelegt.
werden die Dateien größer, bzw. die Ebenen mannigfaltiger, kommt in der REgel eben zuerst die Bremse durch die Protkollobjekte. Das sieht man z.B: meinen Benchmark mal umstellt und eben nicht die Hygiene betrreibt, wie im aktuellen Script, nach jeddem Befehl zum Snapshot zurückzukehren und somit die Protokollliste leer zu halten (bis auf den Snapshot). Macht man das nciht, bemerkt man je nach RAM nach ein paar der Operationen des Benchmarks, das das ganze tierisch in die Knie geht. Und das liegt einzig daran, das dann nach dem 10. Befehl das erste 50MB Protokollobjekt ausgelagert werden muss. Dann kommt der aktuelle Befehl zum Einsatz der im RAM abläuft und beim nächsten Befehl geht dann erstmal der 11. letze Schritt auf Platte. Man hat quasi ein Sichern nach jedem Befehl.
Und endgültig auf die Bremse steigt PS dann wenn eine Ebene eben nicht mehr mit dem 3-5fachen an Rechenpuffer für einen Befehl, nicht mehr in den RAM passt, dann ist eben fleissigstes Daten hin- und hergeschaufel angesagt. Und nach wie vor ist RAM in Relation zu Platte irgendwo um Faktor Tausend schneller.
Und damit sind wir wieder bei meinen obigen Vorschlägen: Meinen Benchmark laufen lassen, denn der ist absolut auf Prozessortakt und RAM ausgelegt. Ein eingeblendeter Taskmanager oder Aktivitätsanzeige zeigt, wie wenig auf mehr als einem Prozessor stattfindet (wobei OS X so clever ist, PS wirklich bei einprozessorigen Aufgaben, diesen auch zu 100% zuzuteilen und alles was sonst noch zu bearbeiten ist, auf den 2. oder weitere Prozessoren auslagert.
Läuft das in adäquater Geschwindigkeit, ist schon mal die PS Konfiguration und die Settings i.O. jetzt kann man eben weitergehen und sehen, ob sich performancetechnisch was durch weniger Protokollobjekte heben lässt, so dass man eben nicht bei 20 Prot. Obj. dauernd einzig und allein nach jedem Befehl das älteste Objekt noch eben auf Platte umkopiert, um es dann beim nächsten Befehl erst von dort zu löschen um dann das neue 20. auf Platte zu bugsieren. Dann haben wir nämlich dauernd ein Gehabe, als wäre die Datei 5mal so groß, weil eben nach bzw. vor jedem Befehl erstmal ausgelagert wird.
Oder anders gesagt: Man muss abwägen, ob noch alle Schritte des Protokolls in den RAM passen. Weil wenn nicht, ist es fasst so, als hätte man zu wenig RAM, weil eben für jeden Befehl ausgelagert wird, und eben nicht um Platz zum Rechnen zu haben, sondern nur um den alten kram, den man in 90% der Fälle eh nicht mehr braucht, noch eben umzubetten, um ihn dann meist unmittelbar danach dann endgültig zu vermüllen.
Ich hab 2 Platten beim Umbau von 120 bzw. 160 auf 250 bzw. 320GB meiner beiden G5s ne weile mit beiden Platten gearbeitet, und auch PS dahingehend konfiguriert, auf der ansonsten unbenutzten Platte zu swappen: Das bringt nicht viel, weil eben die Systemplatte, sofern nicht im HG irgendwas anderes auf ihr stattfindet, nicht viel tut ausser eben PS Cache auszulagern. Das macht die System/Programmplatte, sofern nicht überfüllt, ebensogut wie eine andere.
Und wenn es Bildgrößenmässig eben so übel wird, das für den laufenden Befehl Bildteile oder Ebenen von Platte geholt und fertige Berechnungen ausgelagert werden müssen, so ist wiederum eine Platte ohne RAID wiederum der Flaschenhals, egal ob extra SWAP-platte oder normale alltags HD.
Gerade oder auch am Mac gibts in Form von Menumeters und Aktivitätsanzeige reichlich Helferlein, die es einem leicht machen das System bei der Arbeit mit PS in einem Augenwinkel zu beobachten und so recht schnell mitzubekommen wann und wo es eng wird.
Unter Windows kenn ich es, allerdings nur für den Distiller, ganz anders.
Da kommen 20MB an PS um distillt zu werden und 20 Sekunden später sind 5MB PDF fertig. In dieser Zeit werden aber parallel dazu 250MB auf und von Platte transferiert!? Die selbe Datei am Mac mit vergleichbarer RAMbestückung und Zuteilung bewegt eigentlich nur die 25MB der ankommenden und abgehenden Daten. Dafür braucht er dann aber die Hälfte länger ;-)
