Datum: 12.03.2010 Uhrzeit: 23:28:23 ManfredG Dass Oly Studio Software nicht die schnellste ist, ist ja bekannt. Bei mir ist es so, dass diese Software unter Win7 64-Bit (6 GB RAM) extrem langsam läuft. Auf meinem Notebook unter Win7 32-Bit (4 GB RAM) läuft es zwar immer noch langsam, aber im Vergleich zum 64-Bit Betriebssystem richtig flüssig. Kann man evtl. das Prg. irgendwie beschleunigen“ – oder ist in absehbarer Zeit mal ein vernünftiges Update vorgesehen? Danke für Antworten LG Manfred“ —————————————————————————————————————————————— Datum: 13.03.2010 Uhrzeit: 15:17:13 JosefH Hallo Manfred, eine für 32Bit Systeme compilierte Software läuft auf 64Bit Systemen immer im Kompatibilitätsmodus, soll heißen, Betriebssystemaufrufe müssen zur Laufzeit immer über ein API konvertiert werden. Das drückt natürlich die Performance der Software. Ich gehe davon aus, daß bald eine 64Bit Version von Oly Master und Studio verfügbar sein wird. Gruß Josef — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 10:07:34 Hans Wein JosefH“ schrieb: > eine für 32Bit Systeme compilierte Software läuft auf 64Bit > Systemen immer im Kompatibilitätsmodus soll heißen > Betriebssystemaufrufe müssen zur Laufzeit immer über ein API > konvertiert werden. Dann muss Microsoft ziemlich doof sein denn Office wird bis heute nur als 32 Bit Version verkauft. 64 Bit gibt es nach dieser Aussage erst in Bälde: Zitat ZDNet: „Die unter dem Codenamen Office 14 entwickelte nächste Version von Microsoft Office will der Softwareanbieter als 32- und 64-Bit-Version in den Handel bringen. Damit wird das Unternehmen erstmalig eine seiner Desktop-Anwendungen für den Massenmarkt auch als 64-Bit-Software verö¶ffentlichen. Bisher bietet Microsoft nur seine Betriebssysteme und Server-Produkte wie SQL Server auch in 64-Bit an.“ > Das drückt natürlich die Performance der Software. Beim aktuellen Office 2007 sollen ein paar Funktionen unter 64 Bit-Vista nicht laufen von einem allgemeinen Performanceeinbruch habe ich bei diesem Produkt bisher noch nichts bemerkt. Wenn die Oly-Anwendungen tatsächlich unter 64 Bit zicken sollten dann liegt das mit Sicherheit an Programmierfehlern in diesen und nicht an der Architektur des Betriebssystems. > Ich gehe davon aus daß bald eine 64Bit Version von Oly Master > und Studio verfügbar sein wird. Wenn Oly so lange wie MS braucht wird es womö¶glich noch eine Weile dauern 😉 Hans“ —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 11:05:59 JosefH Hallo Hans, > > Dann muss Microsoft ziemlich doof sein, denn Office wird bis heute > nur als 32 Bit Version verkauft. 64 Bit gibt es nach dieser Aussage > erst in Bälde: > keineswegs, MS arbeitet nur bedarfsorientiert! Office wird hauptsächlich im kommeriellen Bereich eingesetzt, da ist Win XP noch Standard, und Office 2003! Und das wird bis 2014 auch so bleiben. Keine vernünftige Firma hat auf Vista migriert, Win 7 schaut man sich erst nach dem ersten Servicepack an. Und was macht schon Word, Excel, Powerpoint und Outlook im Vergleich zu Oly Master oder Studio? Und wenn Access überhaupt eingesetzt wird, dann nur als Frontend für MS SQL Server, oder für winzige Anwendungen! > Wenn die > Oly-Anwendungen tatsächlich unter 64 Bit zicken sollten, dann liegt > das mit Sicherheit an Programmierfehlern in diesen und nicht an > der Architektur des Betriebssystems. > Wenn man 64Bit Register hat und nur 32Bit einschießt braucht man mehr als die doppelte Zeit um die Hardware anzusprechen… >> Ich gehe davon aus, daß bald eine 64Bit Version von Oly Master >> und Studio verfügbar sein wird. > > Wenn Oly so lange wie MS braucht wird es womö¶glich noch eine Weile > dauern 😉 > > Hans Oly wird schneller als MS sein, sicherlich. Josef — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 13:23:01 Hermann Brunner JosefH schrieb: > > Wenn man 64Bit Register hat und nur 32Bit einschießt braucht man > mehr als die doppelte Zeit um die Hardware anzusprechen… > Sorry Josef, so pauschal kann man das hier nicht stehen lassen. Der Vergleich lautet ja nicht 32-bit Software auf 64-bit System versus 64-bit Software auf 64-bit System, sondern: 32-bit Software nativ versus 32-bit Software auf 64-bit Converter. Die Ausgangsfrage war ja, ob eine 32-bit Software unter einem 64-bit System generell *dramatisch* langsamer laufen *muss*. Die Antwort ist: normalerweise *nein* – es sein denn es werden eklatante Programmierfehler gemacht, ungeschickt mit System-calls hantiert, Driver sonderbar gebaut, etc… Eine ganz normale (32-bit) Anwendungssoftware sollte unter einem Konverter auf einem 64-Bit Betriebssystem nur unmerklich leiden“ wenn überhaupt. Beispiel: JPEG Rotation: Ein 64-Bit Rechner kann mit einer 32-Bit Routine ziemlich genau gleich schnell ein JPG Bild drehen wie ein 32-bit Rechner mit vergleichbarer Taktrate. (Das wäre ein Beispiel für eine rechenintensive Anwendung.) Dass das Potential der 64-bit Architektur nicht voll genutzt wird steht dabei selbstverständlich außer Frage – so richtig flott kö¶nnte es eben nur eine Software die die 64er Registerbreite ausnutzt. Wenn die Anwendung I/O-intensiv ist (Beispiel: Datenbanken) dann wird der Unterschied eher geringer weil ein Großteil der Verarbeitungszeiten auf I/O-Wartezeiten fällt d.h. der noch so schnelle Rechner generell seine „Power“ nicht so richtig ausspielen kann. Der Datentransfer selbst ist dabei irrelevant da dieser schon seit ewigen Zeiten (auf vernünftiger Hardware) im sogenannten DMA-Modus läuft (also nicht durch Prozessor-Register limitiert ist) und DMA-Controller haben meist einen breiteren Bus zum Hauptspeicher. Just My2Cents Hermann“ —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 14:18:37 JosefH Doch Hermann, das kann man! Eine Hochsprachenanweisung unter 32Bit entspricht x Prozessoranweisungen unter einem 32Bit System. Eine Hochsprachenanweisung unter 32Bit entspricht x * 1,5 Prozessoranweisungen unter einem 64Bit System. Diese einfache Rechnung stammt von einem EDV-Riesen, kann nur durch schnellere Prozessoren kompensiert werden. Und DMA hat überhaupt nichts mit I/O’s zu tun. IDE bleibt IDE, SCSI ganz anders, und SATA ist außenvor. Du meintest sicherlich UDMA…? Gruß – Josef — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 17:04:12 Hermann Brunner JosefH schrieb: > Und DMA hat überhaupt nichts mit I/O’s zu tun. Na wenn Du meinst, dass das so ist, dann wird es schon so sein… Man sollte jedem in seinem Glauben lassen 😉 LG, Hermann —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 18:39:19 JosefH Hallo Hermann, es soll Leute geben, die zwischen Arbeitsspeicher und ext. Festplattenspeicher nicht unterscheiden kö¶nnen. Ich wünsche Dir den DMA: Den Dance Music Award 😉 Josef Auszug aus der Wikipedia: UDMA wie auch DMA ermö¶glichen es der Festplatte, Daten unter Verwendung eines DMA-Controllers direkt vom bzw. zum Arbeitsspeicher zu übertragen, ohne dabei den Prozessor zu benutzen. Dadurch wird das System entlastet. Beim Bus Mastering übernimmt der Festplattencontroller selbst die Aufgabe eines DMA-Controllers. Die verschiedenen Standards sind UDMA33, UDMA66, UDMA100, UDMA133 usw. und geben die theoretisch zu erreichende Datentransferrate in MB/s an. Den Anfang machte UDMA33. Die Abkürzung DMA steht für: * Dance Music Award, ein Musikpreis * Danish Music Awards, Pop-Musikpreis in Dänemark * Davis-Monthan Air Force Base, als IATA-Code für den US-Luftwaffenstützpunkt in Arizona * Defense Mapping Agency, eine Vorgängerinstitution der National Geospatial-Intelligence Agency * Deutsches Musikarchiv in Berlin * Differential Mobility Analyser, ein Messgerät zur Bestimmung der Mobilitätsverteilung von gasgetragenen Partikeln und damit auch indirekt die Grö¶ßenverteilung * Digital Media Adapter, ein Endgerät aus Intels Digital-Home-Initiative * Dimethylarsinsäure, siehe Agent Blue * Dimethylacetamid, ein organisches Lö¶semittel * Dimethylaniline, eine Gruppe von isomeren chemischen Verbindungen * Direct Market Access, bezeichnet Tools, die die Anbieter von Wertpapierdienstleistungen mit den Wertpapiermärkten verbinden * Direct Memory Access, eine (direkte) Speicherzugriffsart in der Computertechnik * District Management Area, südafrikanische Gemeindeform für schwach besiedelte Gebiete, die keine eigene Gemeindeverwaltung haben, sondern vom Distrikt verwaltet werden * DMA Design, ein Entwicklerstudio, welches heute unter dem Namen Rockstar North bekannt ist * Doctor of Musical Arts ein akademischer Grad an US-amerikanischen Universitäten und Konservatorien * Dominica, als olympisches Länderkürzel * Dynamisch Mechanische Analyse, eine Charakterisierungsmethode für Materialien, vor allem von Polymeren — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 19:35:51 Hans Wein Hermann Brunner“ schrieb: > Eine ganz normale (32-bit) Anwendungssoftware sollte unter einem > Konverter auf einem 64-Bit Betriebssystem nur unmerklich „leiden“ > wenn überhaupt. Beispiel: JPEG Rotation: Ein 64-Bit Rechner kann > mit einer 32-Bit Routine ziemlich genau gleich schnell ein JPG Bild > drehen wie ein 32-bit Rechner mit vergleichbarer Taktrate. Hier kommt noch hinzu dass die große Masse der Bitmaps (immer noch) 32 Bit pro Pixel aufweist. Mir ist daher nicht klar wie ein System mit doppelt so breiten Datenregistern von diesen profitieren kann. > Wenn die Anwendung I/O-intensiv ist (Beispiel: Datenbanken) dann > wird der Unterschied eher geringer weil ein Großteil der > Verarbeitungszeiten auf I/O-Wartezeiten fällt d.h. der noch so > schnelle Rechner generell seine „Power“ nicht so richtig ausspielen > kann. Datenbanken sind vielleicht gar nicht so sehr als Beispiel geeignet weil viele der hier verwendeten Funktionen erst dann gestartet werden wenn die Daten im RAM liegen. Aber grundsätzlich hast du natürlich recht. Mittlerweile werde ich sowieso den Eindruck nicht los dass der entscheidende Vorteil der 64 Bit-Architektur nahezu ausschließlich in der Mö¶glichkeit liegt einen grö¶ßeren Adressraum anzusprechen und da dürfte der Kreis der die damit mö¶glich gemachten Arbeitsspeichergrö¶ßen *wirklich* ausnutzt derzeit noch überschaubar sein. Hans“ —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 19:35:53 Hans Wein JosefH schrieb: > Eine Hochsprachenanweisung unter 32Bit entspricht x > Prozessoranweisungen unter einem 32Bit System. > > Eine Hochsprachenanweisung unter 32Bit entspricht x * 1,5 > Prozessoranweisungen unter einem 64Bit System. Sorry, aber diese Aussagen sind mir schlicht und ergreifend zu allgemein-nebulö¶s. Dazu gibt es einfach zu viele verschiedene Hochsprachen“ und zu viele verschiedene Befehle. > Diese einfache Rechnung stammt von einem EDV-Riesen kann nur > durch schnellere Prozessoren kompensiert werden. Wie wär’s mit etwas Butter bei die Fische (zum Nachlesen). Hans“ —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 20:16:11 JosefH Du hast Recht Hans, als Hochsprache ist natürlich C gemeint. Und den Riesen darf ich nicht nennen. A bee – Josef — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 20:30:06 JosefH Hans Wein schrieb: > Hier kommt noch hinzu, dass die große Masse der Bitmaps (immer > noch) 32 Bit pro Pixel aufweist. Mir ist daher nicht klar, wie ein > System mit doppelt so breiten Datenregistern von diesen profitieren > kann. > > Hans ….hat die PS-3 nicht 128Bit Registerbreite? Pro Prozessorzyklus 4 Data-Items verarbeiten, da hat was… — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 14.03.2010 Uhrzeit: 22:13:04 Hermann Brunner JosefH schrieb: > Und DMA hat überhaupt nichts mit I/O’s zu tun. Na wenn Du meinst, dass das so ist, dann wird es schon so sein… > Hallo Hermann, > > es soll Leute geben, die zwischen Arbeitsspeicher und ext. > Festplattenspeicher nicht unterscheiden kö¶nnen. > > Josef > > Auszug aus der Wikipedia: > > UDMA wie auch DMA ermö¶glichen es der Festplatte, Daten unter > Verwendung eines DMA-Controllers direkt vom bzw. zum > Arbeitsspeicher zu übertragen, ohne dabei den Prozessor zu > benutzen. (…) Hallo Josef, …. mir war natürlich nicht klar, dass für Dich eine Disk (Festplatte“) *kein* I/O-Gerät ist. Für mich ist es das. Meist sogar der performance-relevanteste aller I/O-Kanäle. Ausschließlich darauf bezog sich meine Anmerkung dass die „Breite“ der CPU-Register im Falle des DMA-Transfers eher bedeutungslos ist sondern die DMA-Anbindung des Controllers an den Hauptspeicher die wichtigere Rolle spielt – diese ist aber seit einigen Generationen von Hardware aber schon grö¶ßer als 32 Bit. Je nach Rechner-Architektur (ich spreche jetzt ausdrücklich auch von Non-Windows/Intel/PC Hardware) häufig auch bereits 128Bit und mehr obwohl es noch gar keine nennenswert verbreiteten 128Bit CPU-Architekturen gibt. Lg Hermann PS: Zu den von Dir zitierten „Leuten“ gehö¶re ich definitiv nicht wohl aber zu denen die das Lesen eines Disk-Blocks und den dazu nö¶tigen Xfer der Daten zum Hauptspeicher für I/O halten ;-)“ —————————————————————————————————————————————— Datum: 15.03.2010 Uhrzeit: 21:09:44 Helge Suess Hallo Hans! > Hier kommt noch hinzu, dass die große Masse der Bitmaps (immer > noch) 32 Bit pro Pixel aufweist. Mir ist daher nicht klar, wie ein > System mit doppelt so breiten Datenregistern von diesen profitieren > kann. Darum geht’s nicht wirklich. Ein entscheidender Unterschied gibt sich z.B. bei der Kompression oder beim Verschlüsseln von Daten. Da sind 64 Bit Anwendungen wesentlich schneller. Auch bei Algorithmen, die in der Bildbearbeitung vorkommen kan sich das auswirken. Ich habe vor kurzem einen Vergleich verschiedener Anwendungen gesehen. Da waren die 64 Bit oft signifikant schneller. Die Komperssion wirkt sich z.B. beim Zugriff auf Speichermedien aus wenn diese komprimiert sind. Da kann man durch die geringeren Schreibzugriffe ordentlich an Geschwindigkeit raus holen. > Mittlerweile werde ich sowieso den Eindruck nicht los, dass der > entscheidende Vorteil der 64 Bit-Architektur nahezu ausschließlich > in der Mö¶glichkeit liegt, einen grö¶ßeren Adressraum anzusprechen, > und da dürfte der Kreis, der die damit mö¶glich gemachten > Arbeitsspeichergrö¶ßen *wirklich* ausnutzt, derzeit noch > überschaubar sein. Der grö¶ßere Adresseraum ist nur ein Teil der Erweiterung. Gerade bei der Bildbearbeitung macht das aber einen wesentlichen Faktor aus. Ich verwende Win7 in 64 Bit und habe bei Anwendungen die noch als 32 Bit Anwendungen laufen keine spürbaren Verschlechterungen der Performanz erlebt. Studio oder Master habe ich allerdings noch nicht unter Win7 laufen gelassen. Helge ;-)=) 2 — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 16.03.2010 Uhrzeit: 12:40:34 Hermann Brunner Hallo Helge, Helge Suess schrieb: > Der grö¶ßere Adresseraum ist nur ein Teil der Erweiterung. Gerade > bei der Bildbearbeitung macht das aber einen wesentlichen Faktor > aus. Da muss man aber einschränkend noch dazusagen: Nur wenn die SW innerhalb eines einzigen Prozesses auch einen Adressraum > 2GB adressiert – was z.B. bei der Verarbeitung von Photos in üblichen Bildverarbeitungsprogrammen erst bei überdimensional großen Pics, oder bei gleichzeitigem öffenen von sehr vielen Bildern vorkommt. Ein Process-Space von 2GB ist ja auch in einer 32-Bit Architektur problemlos mö¶glich, wenn das Betriebssystem das ordentlich kann. (In der Windows-Welt seit WinNT, WinXP, Win2000 – lediglich die Varianten 95 / 98 / 98me waren da ewas sonderbar gestrickt…) > Ich verwende Win7 in 64 Bit und habe bei Anwendungen die noch als > 32 Bit Anwendungen laufen keine spürbaren Verschlechterungen der > Performanz erlebt. Studio oder Master habe ich allerdings noch > nicht unter Win7 laufen gelassen. Das war meine Vermutung weiter oben im Thread – die Vorteile (grö¶ßere Datenbreite) überwiegen auch bei Nicht-Nutzung des 64bit-Adressraums die Nachteile (Emulation des 32-bit Codes) – daher keine / kaum Performanz-Verluste zu erwarten. LG, Hermann —————————————————————————————————————————————— Datum: 16.03.2010 Uhrzeit: 12:56:59 Helge Süß Hallo Hermann! > Da muss man aber einschränkend noch dazusagen … erst bei überdimensional großen Pics, … Was den Adressraum betrfft ja. Was die Effizienz der Algorithmen betrifft kann 64 Bit hier oft sehr viel effizienter arbeiten. > Das war meine Vermutung weiter oben im Thread – die Vorteile > (grö¶ßere Datenbreite) überwiegen auch bei Nicht-Nutzung des > 64bit-Adressraums die Nachteile (Emulation des 32-bit Codes) > – daher keine / kaum Performanz-Verluste zu erwarten. Es gab da einen Vortrag auf der TechEd im November letzten Jahres. Da wurden Themen wie Performance-Vergleiche und das Verhalten von 32 Bit Anwendungen unter 64 Bit besprochen. Müsste ich mir mal die Folien raus suchen. Helge ;-)=) 12 — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 16.03.2010 Uhrzeit: 17:48:43 Hans Wein Helge Suess“ schrieb: >> Hier kommt noch hinzu dass die große Masse der Bitmaps (immer >> noch) 32 Bit pro Pixel aufweist. Mir ist daher nicht klar wie ein >> System mit doppelt so breiten Datenregistern von diesen profitieren >> kann. > Darum geht’s nicht wirklich. Ein entscheidender Unterschied gibt > sich z.B. bei der Kompression oder beim Verschlüsseln von Daten. > Da sind 64 Bit Anwendungen wesentlich schneller. Auch bei > Algorithmen die in der Bildbearbeitung vorkommen kan sich das > auswirken. Ich habe mir jetzt die VisualStudio-Dokumentation vorgeknö¶pft und wenn ich mir die Aufrufparameter der GDIPlus-Bibliothek von Windows ansehe so sind die meisten immer noch als Integer oder Single definiert d.h. 32 Bit. Long habe ich auf die Schnelle nur beim Encoderobjekt gefunden und der wird angeblich sogar noch in eine 32 Bit-Ganzzahl konvertiert. Ich schätze ein echter Performancegewinn wird z.B. dann zum Tragen kommen wenn Fließkommavariablen vom Typ Double gefragt sind und das mag durchaus bei Verschlüsselungen der Fall sein (ab damit habe ich mich noch nie befasst). In vielen anderen Fällen werden die Register halt viele Nullbytes mit sich herumschleppen 🙂 Hans“ ——————————————————————————————————————————————
