Alles rund um Compiler und Softwareentwicklung

Mein Encoding läuft allerdings immer über das Placebo-Preset. Dort könnte der Unterschied doch größer sein, oder?
 
Vermutlich nicht. Tendenziell würde ich eher vom Gegenteil ausgehen. Die performance-kritischen Funktionen sind handoptimiert. Der Compiler optimiert nur den Rest. Bei langsamen Presets wird aber in erster Linie die Zeit in diesen kritischen Funktionen verlängert, d.h. der Teil, den der Compiler optimieren kann verliert noch weiter an Bedeutung. Übrigens hat das Placebo-Preset seinen Namen nicht umsonst.
 
Bis Software die Features moderner CPUs nutzt, dauert es, aber nach und nach wird's besser: Die glibc nutzt jetzt AVX für Vektorberechnungen:

"Eine neue Bibliothek libmvec für mathematische Vektoroperationen wurde hinzugefügt. Sie enthält für die x86_64-Architektur optimierte Implementationen diverser mathematischer Funktionen, wenn diese auf einem Vektor (Array) von Eingabewerten ausgeführt werden sollen, und nutzt die Prozessorerweiterungen SSE oder AVX, die mittlerweile bis zu 16 einfach genaue oder 8 doppelt genaue Gleitkommazahlen parallel verarbeiten können."
http://www.pro-linux.de/news/1/22644...nicode-70.html
 
Kann ich mir nun nicht ganz vorstellen, dass Word nur i386 nutzt, ok wenn man die Tabellenfunktionen in Word als Excel ansieht evtl. Aber reiner i386-Code für alle Funktionen???
 
Wieso Wundert dich das, wenn eine Funktion damals in Asm geschrieben wurde und keine Fehler hatte wieso soll sie ausgetauscht werden, wobei ich mir nicht vorstellen kann das MS nicht ihr .net/visual c++ verwendet und damit doch einfach mit anpassen der Zielarchitektur die Funktionen für i486/i586 kompilieren kann, nun tun sie es einfach immer noch für i386, wobei die Mindestanforderungen ihres OS weit höher ist da verlangen sie doch min. PIII, also i686 oder neuer.
 
Ist ja jetzt nicht so, das Word sich die letzten 10 Jahre nicht weiter entwickelt hat. Und selbst Microsoft wird nicht alles neu in Asembler schreiben. Insofern wird's wohl ne Kompiler-Einstellung sein, wenn das überhaupt stimmt.
Wobei mir jetzt spontan auch kein Befehl der nach i386er Zeit einfiele, der für Ganzzahloperationen wichtig wäre.
 
Genau genommen ist in der Meldung von
Winword aus Office 15
die Rede. Das könnte als Abkürzung gemeint sein oder sich auf die Datei WINWORD.EXE beschränken, die nur 2 MB groß ist. Dann könnten all die DLLs und sonstigen Dateien auch neuere Befehle enthalten.
 
Nun dies bezieht sich allerdings sicherlich auf Powerpoint, welches ja auch Teil des Office Paketes ist. Dort gibt es GPU-Beschleunigung und Excel ist sicherlich mit SSE2 Befehlen zu Gange. Daher war wohl auch die spezifische Angabe "Winword 2016" entscheidend. Und da wüsste ich nicht wo SSE Vorteile in der reinen Textverarbeitung bieten sollten.
 
Der Fall, wo ich am häufigsten auf die CPU warte, ist Kompression / dekompression von Archiven (Server) unter Linux.

Dafür sollen natürlich alle Kerne genutzt werden, aber pbzip & Konsorten waren mir immer etwas zu "speziell", um sie im Alltag zu nutzen. Nachdem xz sich immer weiter durchsetzt und schon zu den "gängigen" Formaten gezählt werden kann, mache ich jetzt alles mit

xz -v9 -T 3 (bei einem Quadcore).

ENDLICH ein Standard-Packer, der die kleinsten Archive packt (im Vergleich mit zip, gzip, bzip2 etc) und dabei trotzdem noch schneller ist! *birthday*

Der Parameter -v bringt eine nette Fortschrittsanzeige.
tar unterstützt xz über den Parameter -J.
Ein 700 MB SQL-Dump war mit bzip2 55 MB groß, mit xz nur noch 34 MB.
 
Zuletzt bearbeitet:
Guter Tipp.
Wusste ich gar nicht, das xz mt ist. Die Manpage verstand ich so, dass mt noch nicht implementiert ist.
 
Multi-Threading ist ab Version 5.2 (vom Dezember 2014) implementiert. Mittlerweile ist diese Version auch in den Distris angekommen.
 
Für die herkömmlichen Komprimierungsverfahren gibt es jeweils multithread-Pendants.
gzip wird zu pigz
bzip2 wird zu pbzip2

Man muss also nicht auf Kompatibilität verzichten um multithreading packen oder endpacken zu können.
 
Darüber hatte ich gelesen. Was für mich dagegen sprach:

1) Die parallen Varianten der "original"-Packer waren mir wie gesagt "nicht geheuer", weil sie nicht besonders verbreitet sind. Das machte eher den Eindruck des Hobby-Projekts eines einzelnen Entwicklers, das nichts mit dem "Original" zu tun hatte. Es gab auch multithread-Varianten, deren Output nicht mehr kompatibel zum Standard-Packer war. Für einen Packer war mir das zu heiß.

Bei xz ist der multithread-Support direkt enthalten. Der Packer wird auch von den Kernel-Entwicklern eingesetzt, und meine Distro nutzt ihn standardmäßig (als Nachfolger von gzip) für die Komprimierung von logfiles. Für mich ist das der "neue Standard", mit Kompatibilitätsproblemen rechne ich nicht.

2) Außerdem komprimiert der modernere xz besser als gzip und bzip2.
 
Zuletzt bearbeitet:
Der Output von pigz und pbzip2 sind vom normalen Original ohne Probleme zu verarbeiten.
Ich verwende diese sowohl hier am Boot alsauch bei mir in der Firma und deren Kunden seit Jahren ohne Vorkommnisse.
 
Was ist denn das Fazit / der Grundtenor? Für diejenigen, die nicht den ganzen Test lesen und/oder kein Geld ausgeben möchen...
 
Würde mich auch interessieren. Naja, vielleicht hole ich mir die aktuelle c't sogar mal.
 
"Intel's Linux Compiler führen mit vieleicht 5 Prozent vor den Kollegen unter Windows. Zehn Prozent dahinter folgen nahezu gleichauf GCC (5.3.0/4.8.5) und MS VS2015."

Microsoft hatte noch Probleme mit C++11 Code in der libquantum.462 der SPECint Suite. Vektorisierung und Feedback-Optimierung klappen auch nur beim Intel-Compiler. Alles in allem ein 4-seitiger Überblick von Andreas Stiller.
 
Würde mich auch interessieren. Naja, vielleicht hole ich mir die aktuelle c't sogar mal.
Wieso denn? es wurde eh nur Intel Hardware verglichen und dann mit unterschiedlichen os Version. *noahnung*
so langsam geht das schon auf den Sack, Intel hat auch bestimmte nuc eingestellt die von messmittel firmen genutz werden.
Das unsere Engineering das nicht so doll finden kann man sicher nachvollziehen. Alles von vorne designen.
aber gut evt hat es intel nicht so mit der messtechnik...
 
DirectX 12:
"Apropos älter: AMDs FX-Prozessoren erleben durch Direct3D 12 eine Art zweiten Frühling. Statt mit rund 35 Prozent Differenz hoffnungslos unter D3D11 abgeschlagen zu sein, erreicht ein FX-8370 unter D3D12 fast die Leistung des sonst viel flotteren Core i5-4690."
http://www.golem.de/news/d3d12-benc...hneller-und-nvidia-langsamer-1602-119371.html

Den kurzen Erfolg gönne ich der Schnittstelle, bevor sie von Vulkan platt gemacht wird *buck*
 
DX12 kommt halt leider viele Jahre zun spät, man stelle sich nur vor wie das damals mit der ersten Generation von Bulldozer ausgesehen hätte.
Intel wäre wahrscheinlich trotzdem etwas schneller, aber der abstand wäre viel geringer.

Bulldozer hätte bei Hardware-DAUs dann sicher keinen so schlechten Ruf:\
 
AMD hätte allerdings schon etwas an der unterirdischen DX11 Leistung bzw. deren schlechter CPU Auslastung tun können.
 
Zurück
Oben Unten