Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Komprimierung: GNU Tar unterstützt…

Sehr gut.

  1. Thema

Neues Thema Ansicht wechseln


  1. Sehr gut.

    Autor: Sinnfrei 04.01.19 - 13:23

    Man braucht Facebook nicht mögen, aber der Algorithmus ist klar überlegen und setzt sich hoffentlich weiter gegen Deflate durch.

    Warum der Link zum Zstd-Github nicht im Artikel ist, ist mir allerdings Schleierhaft:

    https://github.com/facebook/zstd

    __________________
    ...

  2. Re: Sehr gut.

    Autor: schily 04.01.19 - 17:10

    Leider Quellcode, der nicht in C geschrieben ist und daher nicht kompiliert.

    "../lib/dictBuilder/divsufsort.c", line 153: warning: no explicit type given

    Die Jungs können nicht programmieren :-(

  3. Re: Sehr gut.

    Autor: bionade24 04.01.19 - 20:55

    Also den Code von Facebook's Scheduler Kyber fand ich sehr gut.

    Bitte BBCode nutzen und nicht einfach Links reinpasten, wir sind hier schließlich in einem IT-Forum!

  4. Re: Sehr gut.

    Autor: Sinnfrei 05.01.19 - 11:44

    Wie genau und womit hast Du denn versucht es zu kompilieren? Und welche Version? Die meisten anderen Menschen haben scheinbar kein Problem damit.

    __________________
    ...

  5. Re: Sehr gut.

    Autor: schily 05.01.19 - 13:56

    Ich habe die neueste Version auf Solaris mit dem Sun Kompiler kompiliert (das ist der Kompiler der automatisch gewählt wird).

    Der Fehler kommt, weil da jemand versucht nonstandard Kram im Inline Umfeld zu verwenden.

    Was aber auch zu denken gibt: bei der Kompilation wird gemeldet daß kein Multithread Support vorhanden ist. Dabei kommt der Standard und die Refrerenzimplementierung für die MT Umgebung von Roger Faulkner (der auch das /proc Filesystem entwickelt hat) und von Solaris.

  6. Re: Sehr gut.

    Autor: Sinnfrei 05.01.19 - 14:45

    Okay, Solaris wird vermutlich weniger häufig verwendet. Würde ich halt mal ein Issue aufmachen, grundsätzlich wird es wohl unterstützt. Gab anscheinend auf jeden Fall mal Versionen die funktioniert haben:

    https://www.opencsw.org/packages/zstd/

    __________________
    ...

  7. Re: Sehr gut.

    Autor: nirgendwer 06.01.19 - 13:35

    Erstens: Wenn Warnungen dazu führen, dass das bei dir nicht fertig kompiliert, dann ist das deine Sache aber weder vom Autor des Programms noch des Compilers so explizit vorgesehen.

    Zweitens: Ursache ist wohl weniger etwas non-standard innerhalb der Funktion, sondern ein nicht korrekt arbeitender Präprozessor-Parser; hier wird C90-Kompatibilität vorausgesetzt (z.B. __inline) und die Linebreaks sind auch eher unüblich, C-technisch ist beides jedoch korrekt. Der Typ jedenfalls ist explizit gegeben. Oder übersehe ich da etwas?

  8. Re: Sehr gut.

    Autor: schily 06.01.19 - 15:18

    Wenn der Code dem C Standard entsprechen würde, hätte er einwandfrei kompiliert.

    Gleiches gilt für die Meldung, daß kein Thread Support gefunden wurde.

  9. Re: Sehr gut.

    Autor: nirgendwer 06.01.19 - 17:30

    Was ist da denn nicht standardkonform? Sonderlich umfangreich ist die Codestelle ja nicht, da sollte sich das ja recht einfach benennen lassen, wenn das so klar ist.

    Und weshalb findet er anderswo Threadsupport und bei dir nicht?

  10. Re: Sehr gut.

    Autor: schily 06.01.19 - 19:37

    Zum Thema inline ist die Antwort einfach: "__inline" kommt im Standard nicht vor. Wenn man das verwendet, sollte man sich nicht wundern, wenn der Kompiler das anmeckert.

    Für die Threads brauch ich etwas meht Zeit für eine Analyse.

  11. Re: Sehr gut.

    Autor: schily 07.01.19 - 13:55

    So, auch für das Problem mit den threads ist nun klarer:

    Auch hier ist der Grund mangelnde Standardkonformität im zstd code.

    Dabei gibt es massenhaft Fehler, bei denen jeder Einzelne schon reichen würde:

    - Bei der Kompilation für Threads werden proprietäre Optionen wie -Wall verwendet

    - Beim Linken für Threads wird die non-standard Option -pthread verwendet statt die ältere Option -mt zu verwenden, die der Sun Kompiler bietet. Achtung: Die Makefiles verwenden gezielt den Sun Kompiler.

    - Beim Kompilieren für Threads wird ein privates nonstandard #define -DZSTD_MULTITHREAD verwendet statt -mt zu nutzen, daß dem Kompiler sagt die notwendigen #defines zu setzen.

    Selbst wenn man das alles korrigiert, wird (im Gegensatz zu Linux) noch immer nicht mehr als 100% Rechenzeit verbraucht. Da muß also noch ein weiterer Fehler in der Nutzung vom Threads im Code sein.

  12. Re: Sehr gut.

    Autor: schily 07.01.19 - 13:56

    Dieses Problem stammt übrigens im Gegensatz zu dem Thread Problem nicht vom Hauptentwickler, sondern vom Entwickler der libDictBuilder.

  13. Re: Sehr gut.

    Autor: nirgendwer 08.01.19 - 16:33

    Bei diesem Problem bin ich mittlerweile bei dir. Das inline-Handling an der Stelle ist kaputt, die Codestelle für den Präprozessor sieht auch ziemlich komisch aus. Funktioniert durchaus trotzdem, weil halt aktuelle Compiler __inline unterstützen, aber es ist nicht standardisiert (im Gegensatz zu "inline", welches es seit C99 ist, da lag mein Irrtum).

    Auch dass es "eingeschleppt" wurde. An anderer Stelle ist das inlining (inkl. korrektem Testen darauf) nämlich besser gelöst.

  14. Re: Sehr gut.

    Autor: nirgendwer 08.01.19 - 16:49

    Naja, "-W" als Warning-Optionen ist schon eher Standard als es ohne zu nutzen. Moderne Compiler machen das so. :-P

    Sind die Compileroptionen überhaupt standardisiert? Kann man wirklich davon ausgehen, dass der Standard anders ist, nur weil es Solaris anders macht? Gibt Solaris etwa die Standards vor? Wenn man sich da auf den einzigen gemeinsamen Nenner einigt, teleportiert man sich doch in die 70er zurück...

    Es ist übrigens völlig legitim proprietäre Optionen zu nutzen, wenn man offen sagt, dass man halt nur eine gewisse Teilmenge aller Systeme als kompatibel erachtet. Das ist hier wohl dann auch der Fall, denn das Makefile verwendet eben nicht gezielt den Solaris-Compiler, sondern den, der via CC vorgegeben wird, also _implizit_ den, der Default ist (bei Solaris dann wohl halt eben nicht den gcc, icc, clang, MSVC oder einen der vielen anderen, die damit klar kommen).

    Und SunOS aka Solaris ist halt eben _nicht_ in der Liste der unterstützten Systeme. Das ist dann wohl auch der Grund, weshalb es nicht auf Anhieb fehlerfrei funktioniert: Weil man es nicht darauf angelegt hat.

    Das Paket von opencsw.org ist da ziemlich deutlich und macht vornehmlich ein paar wichtige Änderungen: Es setzt CC=gcc, setzt bash als die shell ein (das wird dir sicher auch nicht gefallen ;-) und trägt SunOS als kompatibles System ein. Ist es ja dann auch, wenn man die passenden Tools nutzt.

    Insgesamt schöner mag es sein, den Leuten zu zeigen, wie sie ihre c- und Makefiles so aufbauen, dass sie auf Anhieb auch auf "Standard"-Systemen funktionieren (also Systemen mit Toolsets, die mit s anfangen, so wie smake, star, bosh, etc. ;-).

  15. Re: Sehr gut.

    Autor: schily 08.01.19 - 18:49

    Die Makefiles sind so aufgebaut, daß man ausgehend vom Aussehen glaubt sie wären portabel.

    Da sind proprietäre Optionen nicht sillvoll, wenn man wie in diesem Fall kein "Wissen" über den verwendeten Kompiler in das build System einbaut.

  16. Re: Sehr gut.

    Autor: schily 08.01.19 - 18:57

    Du verwendest mehrfach den Begriff "Moderne Compiler" in einer Weise, daß man glauben könnte Du meinst ernsthaft andere Kompiler seien nicht "modern".

    Das ist aber Unsinn. Moderne Kompiler unterstützen vielmehr in diesem Fall "inline" und wäre das verwendet worden, gäbe es aich kein Problem.

    Wenn Du übrigens portable Optionen suchst, empfehle ich:

    http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

    achja: POSIX sagt daß -W ein Präfix für herstellerspezifische Optionen ist, siehe:

    http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. OSRAM GmbH, Berlin, Garching bei München
  2. Modis GmbH, Bonn
  3. Amprion GmbH, Dortmund
  4. Klöckner Pentaplast GmbH, Montabaur

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 245,90€
  2. 294€
  3. 80,90€ + Versand


Haben wir etwas übersehen?

E-Mail an news@golem.de


5G-Report: Nicht jedes Land braucht zur Frequenzvergabe Auktionen
5G-Report
Nicht jedes Land braucht zur Frequenzvergabe Auktionen

Die umstrittene Versteigerung von 5G-Frequenzen durch die Bundesnetzagentur ist zu Ende. Die Debatte darüber, wie Funkspektrum verteilt werden soll, geht weiter. Wir haben uns die Praxis in anderen Ländern angeschaut.
Ein Bericht von Stefan Krempl

  1. Testlabor-Leiter 5G bringt durch "mehr Antennen weniger Strahlung"
  2. Sindelfingen Mercedes und Telefónica Deutschland errichten 5G-Netz
  3. iPhone-Modem Apple will Intels deutsches 5G-Team übernehmen

Ocean Discovery X Prize: Autonome Fraunhofer-Roboter erforschen die Tiefsee
Ocean Discovery X Prize
Autonome Fraunhofer-Roboter erforschen die Tiefsee

Öffentliche Vergaberichtlinien und agile Arbeitsweise: Die Teilnahme am Ocean Discovery X Prize war nicht einfach für die Forscher des Fraunhofer Instituts IOSB. Deren autonome Tauchroboter zur Tiefseekartierung schafften es unter die besten fünf weltweit.
Ein Bericht von Werner Pluta

  1. JAB Code Bunter Barcode gegen Fälschungen

Doom Eternal angespielt: Die nächste Ballerorgie von id macht uns fix und fertig
Doom Eternal angespielt
Die nächste Ballerorgie von id macht uns fix und fertig

E3 2019 Extrem schnelle Action plus taktische Entscheidungen, dazu geniale Grafik und eine düstere Atmosphäre: Doom Eternal hat gegenüber dem erstklassigen Vorgänger zumindest beim Anspielen noch deutlich zugelegt.

  1. Sigil John Romero setzt Doom fort