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. CSL Behring GmbH, Marburg, Hattersheim am Main
  2. Robert Bosch GmbH, Stuttgart
  3. Eurowings Aviation GmbH, Köln
  4. thyssenkrupp AG, Essen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. ES Blu-ray 10,83€, Die nackte Kanone Blu-ray-Box-Set 14,99€)
  2. (u. a. 3 Blu-rays für 15€, 2 Neuheiten für 15€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Marvel im Auto: Nie wieder eine Fahrt mit quengelnden Kindern
Marvel im Auto
Nie wieder eine Fahrt mit quengelnden Kindern

CES 2019 Audi und Holoride arbeiten an einer offenen Plattform für VR-Spiele im Auto. Marvel steuert beliebte Charaktere für Spiele bei. Golem.de hat in Las Vegas eine Testrunde durch den Weltraum gedreht.
Ein Erfahrungsbericht von Dirk Kunde


    Alternative Antriebe: Saubere Schiffe am Horizont
    Alternative Antriebe
    Saubere Schiffe am Horizont

    Wie viel Dreck Schiffe in die Luft blasen, bleibt den meisten Menschen verborgen, denn sie tun es auf hoher See. Fast 100 Jahre wurde deshalb nichts dagegen unternommen - doch die Zeiten ändern sich endlich.
    Ein Bericht von Werner Pluta

    1. Autonome Schiffe Und abends geht der Kapitän nach Hause
    2. Elektromobilität San Francisco soll ein Brennstoffzellenschiff bekommen
    3. Yara Birkeland Autonome Schiffe sind eine neue Art von Transportsystem

    Vorschau Spielejahr 2019: Postnukleare Action und die nächste Konsolengeneration
    Vorschau Spielejahr 2019
    Postnukleare Action und die nächste Konsolengeneration

    2019 beginnt mit Metro Exodus, Anthem, dem neuen Anno und The Division 2 richtig toll! Golem.de verrät, welche Blockbuster sonst noch kommen, was die Konsolenhersteller möglicherweise planen - und was auch Ende 2019 fast sicher nicht zum Spielen da sein wird.
    Von Peter Steinlechner

    1. Slightly Mad Mad Box soll Konkurrenz für Xbox und Playstation werden
    2. Jugendschutz China erlaubt neue Computerspiele
    3. Jugendschutz Studie der US-Regierung entlastet Spielebranche

    1. DEV Systemtechnik: Distributed CCAP Nodes sollen 10 GBit/s im Kabelnetz bringen
      DEV Systemtechnik
      Distributed CCAP Nodes sollen 10 GBit/s im Kabelnetz bringen

      Mit neuen Distributed-CCAP-Geräten, die bis zu 1.000 angeschlossene Kabelmodems pro Gerät unterstützen, soll ein maximaler Datendurchsatz von mehr als 10 GBit/s pro Knoten im Kabelnetz erreicht werden. Die Docsis-3.1.-Technik kommt aus Deutschland.

    2. Ausrüster: Nokia Deutschland baut massiv Arbeitsplätze ab
      Ausrüster
      Nokia Deutschland baut massiv Arbeitsplätze ab

      Bei Nokia Deutschland werden 15 Prozent der Arbeitsplätze in allen Bereichen gestrichen. Offenbar laufen die Geschäfte trotz 5G-Einführung nicht zufriedenstellend, weil die USA den Handelskrieg mit China weiter anheizen.

    3. Amazon: Fire TV Stick erhält verbesserte Fernbedienung ohne Aufpreis
      Amazon
      Fire TV Stick erhält verbesserte Fernbedienung ohne Aufpreis

      Amazon verkauft den normalen Fire TV Stick mit einer verbesserten Fernbedienung. Damit lässt sich auch die Lautstärke des Fernsehers oder einer Soundbar steuern. Kurzzeitig gibt es die Fire-TV-Fernbedienung einzeln zum halben Preis.


    1. 20:07

    2. 18:46

    3. 18:00

    4. 17:40

    5. 17:25

    6. 17:13

    7. 17:04

    8. 16:22