|
|
|
|
|
|
|
|
|
|
|
|
|
*hust* gcc hat das schon seit mehreren versionen. 
nebenbei, ist das zeugs immer noch ziemlicher unsinn. entweder man versteht und kann MT programmierung und macht es richtig oder man lässt es.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
suck it gcc! | |
was has du gegen den GCC? 
|
|
|
|
|
|
|
|
|
|
|
|
clang hat tolle Fehlermeldungen, speziell im Vergleich zu g++.
|
|
|
|
|
|
|
|
|
|
|
Natürlich habe ich nichts gegen gcc, und ja, ich weiß, dass der auch openmp kann. Schon lange.
Aber ich habe halt vor nicht allzu langer Zeit mal clang++ auf meine Codes losgelassen und bin nicht nur von dem schnelleren Kompilieren und den viiiel schöneren Fehlermeldungen begeistert, sondern die Programme laufen auch noch einen Tacken schneller. Und c++11 wird freundlicherweise auch ordentlich unterstützt.
Wegen MT: In meinem letzten Projekt habe ich tatsächlich <thread> genutzt, was in c++11 ziemlich cool ist; Generell finde ich OpenMP aber eigentlich sehr gut, wenn man mal eben eine Schleife parallelisieren will oder so. (Zumal ich irgendwie noch Probleme beim statischen Linken von pthread habe)
Ich habe mich halt gefreut, dass clang endlich OpenMP support bekommt und das suck it, gcc! war nur zur Provokation gedacht. 
/e: LLVM/clang kommt mir irgendwie leichtgewichtiger vor als die gnu toolchain, aber das kann auch ein Trugschluss sein.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 09.10.2013 8:26]
|
|
|
|
|
|
|
|
|
Als ich gesehen habe, dass der HASS zu ist und auf der vorletzten Seite Davos und Barto gleichzeitig aufgetaucht sind, war das schon vorher klar 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von flying sheep
| | Zitat von Oli
suck it gcc! | |
was has du gegen den GCC?
| |
LLVM ist der Hype und fuer Hipster und so.
Im ernst - die Frage sollte man oefter stellen.
Der GCC erzeugt mit und ohne OpenMP Binaries die genauso schnell sind (oder gelegentlich schneller). Die Fehlermeldungen des GCC, sind Dank der Konkurrenz von LLVM besser geworden, koennten aber noch besser werden. GCC hat neue Analysewerkzeuge erhalten. Die Lizenz des GCC ist fuer Open-Source politisch besser, waehrend die BSD-Lizenz Firmen erlaubt sich am Code ungeniert zu bedienen ohne etwas zurueck zu geben und dann am urspruenglichen Projekt vorbeizuziehen.
Das LLVM-Projekt ist gut, schon allein deshalb weil es neue Konkurrenz fuer den GCC geschaffen hat und dessen Entwicklung jetzt schon voran getrieben hat. Die Compilerwelt bestand doch in der Praxis nur noch aus MSVC und dem GCC (ICC, IBM XL sind ja praktisch aussen vor), das kann nicht gut sein.
http://draketo.de/light/english/free-software/phoronix-distort-results-gcc-llvm-clang-amd-vishera
Was mich persoenlich an GCC und LLVM genervt hat, sind beiderseitige Vaporwareankuendigen zu C++11. Und heise.de ist da jedes mal voll drauf eingestiegen. Der GCC koennte ein Feature ganz gut gebrauchen:
Export der Compilerinformationen per API an Editoren, also fuer Code-Completion und Markierung von Fehlern/Warnungen im Quelltext. Jedes Plugin fuer eine Texteditor und die meisten IDEs frickeln da irgendwas zusammen was nicht die Ansprueche erfuellt.
// edit
Gerade nochmal nachgelesen wie sich Microsoft in den fruehen 90igern den TCP/IP-Stack von BSD kopiert hat, ueber Spider (schottisches Firma?). Den Stack haben sie laengst neu geschrieben, aber teilweise sind die diversen Netzwerktools immer noch die von Berkley.
Apple hat mit Darwin die Aenderungen an BSD wenigstens oeffentlich verfuegbar gemacht.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 09.10.2013 11:31]
|
|
|
|
|
|
|
|
|
|
Für letzten Punkt wird sehr gerne Clang eingesetzt, gerade weil Clang im Gegensatz zu GCC eine echte API hat und als Bibliothek benutzt werden kann, was mit dem GPL-GCC schwierig ist - die API müsste unter der LGPL stehen und nicht gegen GCC linken... also unter der Motorhaube GCC extern aufrufen - Pfusch.
|
|
|
|
|
|
|
|
|
|
|
Also, ich schere mich um Benchmarks und die Philosophischen Gedanken, die hoschi beschreibt, herzlich wenig.
Ich habe beides an meinen Projekten ausprobiert und, abgesehen von mangelnder OpenMP Unterstützung, clang für besser befunden. OpenMP wird jetzt nachgeliefert, und das freut mich.
Herzlichst,
Ein ANWENDER
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 09.10.2013 10:56]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Für letzten Punkt wird sehr gerne Clang eingesetzt, gerade weil Clang im Gegensatz zu GCC eine echte API hat und als Bibliothek benutzt werden kann, was mit dem GPL-GCC schwierig ist - die API müsste unter der LGPL stehen und nicht gegen GCC linken... also unter der Motorhaube GCC extern aufrufen - Pfusch.
| |
Japp, genau. Habe dafuer kurzzeitig ein Gedit-Plugin mit LLVM benutzt. Wenn es funktioniert hat, war es wirklich angenehm. Leider war es damals nicht zuverlaessig und ich verwende GCC, nicht LLVM. Also haben Fehlermeldungen nicht gepasst, weil Compiler A was konnte was B nicht verstanden hat. Logisch.
Angeblich hat Richard Stallman etwas gegen entsprechende Aenderungen an Code und Lizenz. Ich sehe da gar kein Problem.
|
|
|
|
|
|
|
|
|
|
|
Der GCC ist einer der heiligen GPL-Grale, vermute ich mal.
SublimeClang hat mich auch relativ schnell genervt, da ja ST2 keine richtigen Projekte wie ne echte IDE hat und daher man alles doppelt konfigurieren darf (einmal Build-System, einmal SublimeClang). Mit einer echten IDE sehe ich das Problem nicht so. Ich habe btw. den Verdacht, dass JetBrains bei ihrer C++-IDE Clang benutzen werden...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 09.10.2013 11:06]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Also, ich schere mich um Benchmarks und die Philosophischen Gedanken, die hoschi beschreibt, herzlich wenig.
| |
Softwarepolitik und Performance interesserien dich nicht.
| |
Ich habe beides an meinen Projekten ausprobiert und, abgesehen von mangelnder OpenMP Unterstützung, clang für besser befunden. OpenMP wird jetzt nachgeliefert, und das freut mich.
| |
Pragmatismus halt. Was hier vollkommen in Ordnung ist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Der GCC ist einer der heiligen GPL-Grale, vermute ich mal.
| |
Von mir aus kann das gerne die heilige LGPL-Gral werden. Loest das Problem und besser als die BSD-Lizenz.
|
|
|
|
|
|
|
|
|
|
|
Muss bei so einer Lizenzänderung nicht jeder Contributor gefragt werden?
Apropos: für Webanwendungen am besten die AGPL?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 09.10.2013 11:08]
|
|
|
|
|
|
|
|
|
Kommt auf die Lizenz(en) an. Bei GPL+ ist ein Upgrade implizit enthalten, bei GPL (ohne Plus, wie beim Linux-Kernel) nicht. Und dann kannst du theoretisch, haengt von der jeweiligen BSD-Lizenz ab, auch ein BSD-Projekt kopieren und der GPL unterstellen. Ich wuerde einen Anwalt fragen.
Im dem Fall des GCC, waere es wohl praktischer den GCC auf GPL zu belassen und eine LGPL-API nach aussen hin anzubieten. Integriert oder als extra Bibliothek. Keine Ahnung. Sollte jedenfalls gemacht werden 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 09.10.2013 11:21]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
...was mit dem GPL-GCC schwierig ist - die API müsste unter der LGPL stehen und nicht gegen GCC linken... also unter der Motorhaube GCC extern aufrufen - Pfusch.
| |
Du spielst auf das Getrickse von Nvidia (Quellgeschlossen) mit dem Linux-Kernel (GPL) ab. Andererseits kann ich mit quellgeschlossenem Code gegen die GLIBC (LGPL) linken, die ruft wiederum Sache im Kernel (GPL) auf. Ich vermute genau diesen LGPL-Layer haette Nvidia eben auch gerne zum Kernel (gehabt)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 09.10.2013 11:29]
|
|
|
|
|
|
|
|
|
|
Jep, das erinnerte mich direkt an diesen Lizenz-Kindergarten. Bei FOSS-Lizenzen fände ich als absoluter Juralaie eine verlässlich recherchierte Übersicht "Wer mit wem darf" ganz praktisch (klappt bei Sex doch auch).
|
|
|
|
|
|
|
|
|
|
|
|
Bei GPL und MIT wuerde es ja noch gehen, aber die ganzen BSD und MPL-Lizenzen verwirren mich dann endgueltig. Nach Geruechten koennte man LLVM (unter der gewaehlten BSD-Lizenz) kopieren und unter GPL stellen koennen, oder halt nicht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 09.10.2013 13:08]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Jep, das erinnerte mich direkt an diesen Lizenz-Kindergarten. Bei FOSS-Lizenzen fände ich als absoluter Juralaie eine verlässlich recherchierte Übersicht "Wer mit wem darf" ganz praktisch (klappt bei Sex doch auch).
| |
du meinst für starter sowas wie das hier?
http://www.gnu.org/licenses/license-list
|
|
|
|
|
|
|
|
|
|
|
|
Mehr eine Matrix mit "Mein Projekt ist..." und "Projekt ich möchte nutzen" ; in den Zellen dann unter welchen Einschränkungen das geht.
|
|
|
|
|
|
|
|
|
|
|
Das Problem ist, dass insbesondere Unternehmen staendig neue Lizenzen fuer ihre Produkte generieren. Bestes Beispiel ist bzw. war SUN.
Laut gnu.org:
LLVM ist eine Mischung aus 3-Clause BSD und MIT/X11 also wohl kompatibel zur GPL. Als koennte man wohl tatsaechlich den ganzen Code inklusive der Lizenz von LLVM (die muss mit!) rueberkopieren und der GPLv3+ unterstellen? Schublade fuer kranke Theorien.
Und LGPLv3+ ist kompatibel zu GPLv2+, welche der GCC nutzt. Also muesste das mit der API fuer Code-Completion ueber LGPLv3+ moeglich sein. Schublade fuer bitte implementieren.
Bitte um Korrektur 
Der libstdc++ implementiert jetzt wohl langsam <regex> aus C++11, das letzte offene Feature. Bisher konnte das zwar der Compiler (GCC), aber halt nicht die Library (libstdc++). Darauf bezog sich die Anmerkung zu Vaporware von mir. Geschichte dahinter ist, dass man irgendwann im letzten Jahrzehnt <regex> als Draft implementiert hat aber dann wegen Regex von Boost nicht mehr sonderlich dahinter her war. Und LLVM hat einfach mal im voraus C++11 angekuendigt, nur halt ohne eine Release.
Fuer den GCC 4.9 gibt es wohl neben OpenMP 4auch gleich noch CILK Plus. Fuer mich nicht wichtig, aber duerfte wohl beides in GCC 4.9 landen.
Die Haswell-GPU wird in Zukunft ein bisschen schneller seine Daten bekommen, weil die CPU weniger tun muss?
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 09.10.2013 17:33]
|
|
|
|
|
|
|
|
|
ich wollte noch mal kurz auf das (un)lustige software raid problem von mir zurückkommen.
ich hab das ganze jetzt mit drei unterschiedlichen festplatten paaren durchgetestet und jedes mal reproduzierbar (zumindest in ansätzen) die gleichen probleme vorgefunden.
hängt eine platte an dem intel C202 controller, dann fährt die volle bandbreite. hängt die zweite mit dran, dann läuft eine von beiden langsamer, mit sehr schwankenden schreib, als auch leseraten.
bei den kabeln bin ich inzwischen auch beim 3. satz. die werden es daher auch nicht sein.
durch die drei verschiedenen platten paare, dürfe ich wohl auch firmware und sonstige hardware (auf seiten der platten) probleme ausschliessen können.(?)
getestete platten paare waren jetzt:
2x HGST HTE541010A9E680
2x HGST HTE725050A7E630
2x WD Red WD10JFCX
die beiden letzteren liefern alleine je um die 120 MB/s lesend und ca. 95-105 MB/s schreibend. die erstere paarung ist ein bisschen langsamer, allerdings auch nur so ca. 10 MB/s.
nebenbei angemerkt, die 7mm HGST HTE platten sind für 2.5 zoll 7.2k rpm platten sehr schnell, was die zugriffszeiten angeht.
darf ich auf grund dieser befunde davon ausgehen, dass entweder die firmware des boards einen bug hat bzw. das irgendwas mit dem C202 chip nicht stimmt?
das was mich dabei allerdings noch am meisten irritiert ist, dass ich parallel ohne weiteres die SSD mit voller interface bandbreite leise bzw. beschreiben kann. das hat weder positive, noch negative auswirkungen auf die beiden platten.
es macht halt auch keinen unterschied ob die jetzt im software raid1 laufen oder für sich alleine. eine von beiden ist immer langsamer als die andere und hat zusätzlich recht starke schwankungen.
die 6 sata ports des C202 hab ich inzwischen alle in verschiedenen konstellationen durchprobiert, immer das gleiche ergebnis.
/e
bei dem board handelt es sich übrigens um das X9SCL+-F.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 09.10.2013 19:06]
|
|
|
|
|
|
|
|
|
|
Frag zuerst mal bei der LKML für IO nach, ob da Probleme bekannt sind oder sowas...
|
|
|
|
|
|
|
|
|
|
|
den bugtracker hatte ich schon befragt, da war bzgl. des C2xx jetzt nicht wirklich was relevantes offen.
das ist im prinzip auch halt nur die server version der [B|H|Z]67 chipsätze (cougar point) für sandy bridge.
bevor nur einer auf die idee kommt, dass da was mit den sata ports war. das war mir das erste, was ich kontrolliert hatte. das ist die gefixte chipsatz generation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
$ sysctl -A | grep net.ipv4.ip_forward
... ist 1?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann zeig mal
ip route
iptables -L -vn
iptables -t nat -L -vn
|
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
pi@RePIter ~ $ ip route
default via 192.168.178.1 dev wlan1
10.0.0.0/24 dev wlan0 proto kernel scope link src 10.0.0.1
192.168.178.0/24 dev wlan1 proto kernel scope link src 192.168.178.50
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.39 |
|
| |
| Code: |
pi@RePIter ~ $ sudo iptables -L -vn
Chain INPUT (policy ACCEPT 194 packets, 15090 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 135 packets, 14356 bytes)
pkts bytes target prot opt in out source destination |
|
| |
| Code: |
pi@RePIter ~ $ sudo iptables -t nat -L -vn
Chain PREROUTING (policy ACCEPT 2 packets, 240 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 2 packets, 240 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 4 packets, 368 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 4 packets, 368 bytes)
pkts bytes target prot opt in out source destination |
|
|
|
|
|
|
|
|
|
|
|
|
Da fehlt schonmal das masquerading.
Aus deinem Howto kopiert:
iptables --table nat --append POSTROUTING --out-interface wlan1 -j MASQUERADE
iptables --append FORWARD --in-interface wlan0 -j ACCEPT
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.28 - Die Tastaturflüsterer ) |
