Urcite to nesouvisi s tim, ze v GCC diky prekotnemu vyvoji stale roste pocet chyb? Osobne pouzivam 4.8/4.9 ...
+1
-2
-1
Je komentář přínosný?
Urcite to nesouvisi s tim, ze
HKMaly https://diit.cz/profil/hkmaly
3. 8. 2017 - 20:58https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseUrcite to nesouvisi s tim, ze v GCC diky prekotnemu vyvoji stale roste pocet chyb? Osobne pouzivam 4.8/4.9 ...https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060245
+
Měli by GCC přepsat do Haskellu. Koho kdy napadlo, že moderní kompilátor se dobře píše v Cčku? :-p
+1
-1
-1
Je komentář přínosný?
Měli by GCC přepsat do
Gath G https://diit.cz/profil/ggeal
3. 8. 2017 - 21:12https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseMěli by GCC přepsat do Haskellu. Koho kdy napadlo, že moderní kompilátor se dobře píše v Cčku? :-phttps://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060251
+
Neni v Ccku, od jiste doby (tusim 4.neco nebo 5.0 uz nevim) je v C++ (presneji jiste podmnozine C++), cili stejne jako Clang/LLVM (jediny rozdil je ze Clang byl v C++ od zacatku).
+1
+2
-1
Je komentář přínosný?
Neni v Ccku, od jiste doby
franzzz https://diit.cz/profil/franz-z
3. 8. 2017 - 22:29https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseNeni v Ccku, od jiste doby (tusim 4.neco nebo 5.0 uz nevim) je v C++ (presneji jiste podmnozine C++), cili stejne jako Clang/LLVM (jediny rozdil je ze Clang byl v C++ od zacatku).https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060305
+
Takže přepnuli Makefile a všechny existující definice obalili klauzulí 'extern "C"'? ;) Těžko to přepsali celé najednou. Mimochodem, není tohle ta fáze, ve které "diky prekotnemu vyvoji stale roste pocet chyb"? Hmmm...možná to nebyl nejlepší nápad?
+1
0
-1
Je komentář přínosný?
Takže přepnuli Makefile a
Gath G https://diit.cz/profil/ggeal
4. 8. 2017 - 08:38https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseTakže přepnuli Makefile a všechny existující definice obalili klauzulí 'extern "C"'? ;) Těžko to přepsali celé najednou. Mimochodem, není tohle ta fáze, ve které "diky prekotnemu vyvoji stale roste pocet chyb"? Hmmm...možná to nebyl nejlepší nápad?https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060410
+
A jak si stoji Haskell napriklad proti Rustu ???!!!
+1
0
-1
Je komentář přínosný?
Jake zasadni vyhody ma C/C++
ldx https://diit.cz/profil/vaclav-dvorak
3. 8. 2017 - 23:03https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseJake zasadni vyhody ma Haskell proti C/C++ ???!
A jak si stoji Haskell napriklad proti Rustu ???!!!https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060308
+
...to měl být vtip? Kompilátory stojí na transformacích stromů a grafů, dnes zpravidla v podobě řetězců transformací. Zbytek si domyslete (jazykové prostředky pro matching, redukce balastního kódu (a spousty bugů), paralelní (a neměnné) datové struktury, případná deforestace atd. atd.) Samozřejmě je možné, že ještě lepší by byl nějaký vhodný DSL. Ostatně dovnitř GCC nějaké (dost odlišné ovšem) už nacpali.
+1
0
-1
Je komentář přínosný?
...to měl být vtip?
Gath G https://diit.cz/profil/ggeal
4. 8. 2017 - 01:26https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse...to měl být vtip? Kompilátory stojí na transformacích stromů a grafů, dnes zpravidla v podobě řetězců transformací. Zbytek si domyslete (jazykové prostředky pro matching, redukce balastního kódu (a spousty bugů), paralelní (a neměnné) datové struktury, případná deforestace atd. atd.) Samozřejmě je možné, že ještě lepší by byl nějaký vhodný DSL. Ostatně dovnitř GCC nějaké (dost odlišné ovšem) už nacpali.https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060353
+
Takže namísto odpovědí "vtip". Taky dobrý přístup, reagovat výpisem detailů, které jsou nahony od původního dotazu... Kdybych argumentaci přijal a začal diskutovat a analyzovat ty detaily, tak se už k původnímu smyslu nedostanem, anebo by to bylo na týdenní konferenci. Takhle prosím ne.
Konečně jsem to pochopil, takže GCC které je interně v C a kompiluje C nahradit něčím co je interně v Haskellu a kompiluje C. Hmmm. Taková šílenost by mně nenapadla, protože to znamená, že C bude vlastně už jen historickým reliktem.
+1
0
-1
Je komentář přínosný?
Takže namísto odpovědí "vtip"
ldx https://diit.cz/profil/vaclav-dvorak
4. 8. 2017 - 19:34https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseTakže namísto odpovědí "vtip". Taky dobrý přístup, reagovat výpisem detailů, které jsou nahony od původního dotazu... Kdybych argumentaci přijal a začal diskutovat a analyzovat ty detaily, tak se už k původnímu smyslu nedostanem, anebo by to bylo na týdenní konferenci. Takhle prosím ne.
Konečně jsem to pochopil, takže GCC které je interně v C a kompiluje C nahradit něčím co je interně v Haskellu a kompiluje C. Hmmm. Taková šílenost by mně nenapadla, protože to znamená, že C bude vlastně už jen historickým reliktem.
https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060869
+
Některé jazyky jsou vhodnější na některé věci a méně vhodné na jiné. Budete v dnešní době psát assembler v assembleru? A) Použití C na spoustu věcí v dnešní době je 1) zbytečné a 2) komplikované, a procento celkového dnes psaného kódu vhodného k implementaci v C neustále klesá. B) Moderní techniky kompilace staví na složitých strukturách, které i na jednom procesoru v C vyžadují ruční správu paměti; v C++ je to řešeno o něco lépe, ale pořád ne úplně uspokojivě (stále narážíte např. (ale ne pouze) na problémy vlastnictví v paralelních a souběžných výpočtech). Přitom implementace jazyků jako OCaml ukazují, že vysoká vyjadřovací schopnost s sebou již nenese oběť v podobě horšího výkonu. C) A pokud zajdeme ještě dále, Haskell je ještě lepší než OCaml a DSL je ještě lepší než Haskell. Použití DSL na míru umožňuje použít spoustu dalších věcí vhodných pro komplexní kompilátor: podstatnou redukci objemu kódu, automatickou memoizaci (posílá do důchodu všechny nástroje typu ccache, pracuje i na objektech menších než kompilační jednotka apod.), snadnou paralelizaci, použití technik AOP pro instrumentaci fází kompilace a obecně lepší rozložení kompilátoru do modulů podle jejich účelu apod., generování optimalizovaných matcherů pro vstupní data ve všech fázích kompilace, fúzi/deforestaci některých transformací (zvláště při nanopass architektuře kompilátorů), nedeterministickou kompilaci na požádání (posílá do důchodu všechny nástroje typu acovea pro hledání rychlejšího kódu výměnou za čas CPU tam, kde jiné techniky selhávají) apod. A co je možná nejzajímavější, snadnou interoperabilitu s jakýmkoli hostitelským jazykem včetně JS, Javy, jazyků v .NET (nevynucuje konkrétní jazykové rozhraní nebo linkování vůči knihovně v C atd. a umožňuje jednu sadu složitých a na implementaci pracných abstraktních algoritmů použít opravdu všude nezávisle na architektuře, platformě i běhovém prostředí). Ano, máte pravdu, C je vlastně už jen historickým reliktem, stejně jako x86, reálný mód při bootování apod. GCC je psáno v C skutečně jen proto, že jeho vývoj začal v už 80. letech. Ostatně jeho autor jen stěží použil C proto, že ho použít chtěl. Považoval ho za výrazný downgrade v porovnání s tím, na čem mohl pracovat dříve.
+1
0
-1
Je komentář přínosný?
Některé jazyky jsou vhodnější
Gath G https://diit.cz/profil/ggeal
4. 8. 2017 - 22:22https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseNěkteré jazyky jsou vhodnější na některé věci a méně vhodné na jiné. Budete v dnešní době psát assembler v assembleru? A) Použití C na spoustu věcí v dnešní době je 1) zbytečné a 2) komplikované, a procento celkového dnes psaného kódu vhodného k implementaci v C neustále klesá. B) Moderní techniky kompilace staví na složitých strukturách, které i na jednom procesoru v C vyžadují ruční správu paměti; v C++ je to řešeno o něco lépe, ale pořád ne úplně uspokojivě (stále narážíte např. (ale ne pouze) na problémy vlastnictví v paralelních a souběžných výpočtech). Přitom implementace jazyků jako OCaml ukazují, že vysoká vyjadřovací schopnost s sebou již nenese oběť v podobě horšího výkonu. C) A pokud zajdeme ještě dále, Haskell je ještě lepší než OCaml a DSL je ještě lepší než Haskell. Použití DSL na míru umožňuje použít spoustu dalších věcí vhodných pro komplexní kompilátor: podstatnou redukci objemu kódu, automatickou memoizaci (posílá do důchodu všechny nástroje typu ccache, pracuje i na objektech menších než kompilační jednotka apod.), snadnou paralelizaci, použití technik AOP pro instrumentaci fází kompilace a obecně lepší rozložení kompilátoru do modulů podle jejich účelu apod., generování optimalizovaných matcherů pro vstupní data ve všech fázích kompilace, fúzi/deforestaci některých transformací (zvláště při nanopass architektuře kompilátorů), nedeterministickou kompilaci na požádání (posílá do důchodu všechny nástroje typu acovea pro hledání rychlejšího kódu výměnou za čas CPU tam, kde jiné techniky selhávají) apod. A co je možná nejzajímavější, snadnou interoperabilitu s jakýmkoli hostitelským jazykem včetně JS, Javy, jazyků v .NET (nevynucuje konkrétní jazykové rozhraní nebo linkování vůči knihovně v C atd. a umožňuje jednu sadu složitých a na implementaci pracných abstraktních algoritmů použít opravdu všude nezávisle na architektuře, platformě i běhovém prostředí). Ano, máte pravdu, C je vlastně už jen historickým reliktem, stejně jako x86, reálný mód při bootování apod. GCC je psáno v C skutečně jen proto, že jeho vývoj začal v už 80. letech. Ostatně jeho autor jen stěží použil C proto, že ho použít chtěl. Považoval ho za výrazný downgrade v porovnání s tím, na čem mohl pracovat dříve.https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060956
+
GCC je psano v C hlavne kvuli rychlosti. Opravdu nikdo netouzi po tom, aby to bylo psany v nejakym z modernich jazyku, jejichz vykon je proti C tragicky a kompilace vetsich projektu se tak natahla na nekolikanasobek...
+1
+1
-1
Je komentář přínosný?
GCC je psano v C hlavne kvuli
PPK https://diit.cz/profil/ppk
5. 8. 2017 - 11:51https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseGCC je psano v C hlavne kvuli rychlosti. Opravdu nikdo netouzi po tom, aby to bylo psany v nejakym z modernich jazyku, jejichz vykon je proti C tragicky a kompilace vetsich projektu se tak natahla na nekolikanasobek...https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1061073
+
GCC je psáno v C hlavně proto, že v C byla předchozí verze GCC. GCC 1.0 bylo psáno v C z důvodů tradice a tehdejších existujících prostředků; jak jsem již poznamenal, jeho autor to sotva udělal proto, že by měl tak primitivní nástroj jako C po zkušenostech z MIT nějak v lásce.
"nikdo netouzi po tom"
"jejichz vykon je proti C tragicky"
"kompilace vetsich projektu se tak natahla na nekolikanasobek"
...trololololo... :)
Mimochodem, nikdo přeci netvrdí, že tam nemohou být komponenty v C *tam, kde je to na místě*. Ale v případě komplexních datových struktur to na místě zpravidla není, z několika důvodů, které dobře známe již dvě dekády či déle.
+1
0
-1
Je komentář přínosný?
"nikdo netouzi po tom"
Gath G https://diit.cz/profil/ggeal
7. 8. 2017 - 20:37https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse"GCC je psano v C hlavne kvuli rychlosti."
GCC je psáno v C hlavně proto, že v C byla předchozí verze GCC. GCC 1.0 bylo psáno v C z důvodů tradice a tehdejších existujících prostředků; jak jsem již poznamenal, jeho autor to sotva udělal proto, že by měl tak primitivní nástroj jako C po zkušenostech z MIT nějak v lásce.
"nikdo netouzi po tom"
"jejichz vykon je proti C tragicky"
"kompilace vetsich projektu se tak natahla na nekolikanasobek"
...trololololo... :)
Mimochodem, nikdo přeci netvrdí, že tam nemohou být komponenty v C *tam, kde je to na místě*. Ale v případě komplexních datových struktur to na místě zpravidla není, z několika důvodů, které dobře známe již dvě dekády či déle.https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1061958
+
Ne, nesouvisi. Sice nevim jak je na tom gcc, ale s Clang/LLVM delam neustale, a nemuzu rict ze by to bylo nejak uber bezchybnej softik :) a "prekotny vyvoj" v GCC je oproti Clangu nejspis eufemismus ;) ostatne prave proto ted preslo LLVM na verzovani X.0.0 - protoze kazda verze je tak odlisna, ze si uvedomili ze je trapne se tvarit ze 3.8 je minor update 3.4, kdyz je praticky pulka kodu jina..
(jo maji C API ktere drzi kompatibilni, ale to API je dobre akorat na Hello world, cokoliv vyznamnejsiho musite delat s C++ "API" ktere nema zadne garance, protoze to neni API vy proste jen dratujete dovnitr kompilatoru.... tudiz se pripravte na vlnobiti #ifdefu ve svem kodu.. uplna paradicka :)
+1
+1
-1
Je komentář přínosný?
Ne, nesouvisi. Sice nevim jak
franzzz https://diit.cz/profil/franz-z
4. 8. 2017 - 08:37https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuseNe, nesouvisi. Sice nevim jak je na tom gcc, ale s Clang/LLVM delam neustale, a nemuzu rict ze by to bylo nejak uber bezchybnej softik :) a "prekotny vyvoj" v GCC je oproti Clangu nejspis eufemismus ;) ostatne prave proto ted preslo LLVM na verzovani X.0.0 - protoze kazda verze je tak odlisna, ze si uvedomili ze je trapne se tvarit ze 3.8 je minor update 3.4, kdyz je praticky pulka kodu jina..
(jo maji C API ktere drzi kompatibilni, ale to API je dobre akorat na Hello world, cokoliv vyznamnejsiho musite delat s C++ "API" ktere nema zadne garance, protoze to neni API vy proste jen dratujete dovnitr kompilatoru.... tudiz se pripravte na vlnobiti #ifdefu ve svem kodu.. uplna paradicka :)https://diit.cz/clanek/openbsd-preslo-na-llvm-clang/diskuse#comment-1060407
+
Urcite to nesouvisi s tim, ze v GCC diky prekotnemu vyvoji stale roste pocet chyb? Osobne pouzivam 4.8/4.9 ...
Měli by GCC přepsat do Haskellu. Koho kdy napadlo, že moderní kompilátor se dobře píše v Cčku? :-p
Neni v Ccku, od jiste doby (tusim 4.neco nebo 5.0 uz nevim) je v C++ (presneji jiste podmnozine C++), cili stejne jako Clang/LLVM (jediny rozdil je ze Clang byl v C++ od zacatku).
Takže přepnuli Makefile a všechny existující definice obalili klauzulí 'extern "C"'? ;) Těžko to přepsali celé najednou. Mimochodem, není tohle ta fáze, ve které "diky prekotnemu vyvoji stale roste pocet chyb"? Hmmm...možná to nebyl nejlepší nápad?
Jake zasadni vyhody ma Haskell proti C/C++ ???!
A jak si stoji Haskell napriklad proti Rustu ???!!!
...to měl být vtip? Kompilátory stojí na transformacích stromů a grafů, dnes zpravidla v podobě řetězců transformací. Zbytek si domyslete (jazykové prostředky pro matching, redukce balastního kódu (a spousty bugů), paralelní (a neměnné) datové struktury, případná deforestace atd. atd.) Samozřejmě je možné, že ještě lepší by byl nějaký vhodný DSL. Ostatně dovnitř GCC nějaké (dost odlišné ovšem) už nacpali.
Takže namísto odpovědí "vtip". Taky dobrý přístup, reagovat výpisem detailů, které jsou nahony od původního dotazu... Kdybych argumentaci přijal a začal diskutovat a analyzovat ty detaily, tak se už k původnímu smyslu nedostanem, anebo by to bylo na týdenní konferenci. Takhle prosím ne.
Konečně jsem to pochopil, takže GCC které je interně v C a kompiluje C nahradit něčím co je interně v Haskellu a kompiluje C. Hmmm. Taková šílenost by mně nenapadla, protože to znamená, že C bude vlastně už jen historickým reliktem.
Některé jazyky jsou vhodnější na některé věci a méně vhodné na jiné. Budete v dnešní době psát assembler v assembleru? A) Použití C na spoustu věcí v dnešní době je 1) zbytečné a 2) komplikované, a procento celkového dnes psaného kódu vhodného k implementaci v C neustále klesá. B) Moderní techniky kompilace staví na složitých strukturách, které i na jednom procesoru v C vyžadují ruční správu paměti; v C++ je to řešeno o něco lépe, ale pořád ne úplně uspokojivě (stále narážíte např. (ale ne pouze) na problémy vlastnictví v paralelních a souběžných výpočtech). Přitom implementace jazyků jako OCaml ukazují, že vysoká vyjadřovací schopnost s sebou již nenese oběť v podobě horšího výkonu. C) A pokud zajdeme ještě dále, Haskell je ještě lepší než OCaml a DSL je ještě lepší než Haskell. Použití DSL na míru umožňuje použít spoustu dalších věcí vhodných pro komplexní kompilátor: podstatnou redukci objemu kódu, automatickou memoizaci (posílá do důchodu všechny nástroje typu ccache, pracuje i na objektech menších než kompilační jednotka apod.), snadnou paralelizaci, použití technik AOP pro instrumentaci fází kompilace a obecně lepší rozložení kompilátoru do modulů podle jejich účelu apod., generování optimalizovaných matcherů pro vstupní data ve všech fázích kompilace, fúzi/deforestaci některých transformací (zvláště při nanopass architektuře kompilátorů), nedeterministickou kompilaci na požádání (posílá do důchodu všechny nástroje typu acovea pro hledání rychlejšího kódu výměnou za čas CPU tam, kde jiné techniky selhávají) apod. A co je možná nejzajímavější, snadnou interoperabilitu s jakýmkoli hostitelským jazykem včetně JS, Javy, jazyků v .NET (nevynucuje konkrétní jazykové rozhraní nebo linkování vůči knihovně v C atd. a umožňuje jednu sadu složitých a na implementaci pracných abstraktních algoritmů použít opravdu všude nezávisle na architektuře, platformě i běhovém prostředí). Ano, máte pravdu, C je vlastně už jen historickým reliktem, stejně jako x86, reálný mód při bootování apod. GCC je psáno v C skutečně jen proto, že jeho vývoj začal v už 80. letech. Ostatně jeho autor jen stěží použil C proto, že ho použít chtěl. Považoval ho za výrazný downgrade v porovnání s tím, na čem mohl pracovat dříve.
GCC je psano v C hlavne kvuli rychlosti. Opravdu nikdo netouzi po tom, aby to bylo psany v nejakym z modernich jazyku, jejichz vykon je proti C tragicky a kompilace vetsich projektu se tak natahla na nekolikanasobek...
"GCC je psano v C hlavne kvuli rychlosti."
GCC je psáno v C hlavně proto, že v C byla předchozí verze GCC. GCC 1.0 bylo psáno v C z důvodů tradice a tehdejších existujících prostředků; jak jsem již poznamenal, jeho autor to sotva udělal proto, že by měl tak primitivní nástroj jako C po zkušenostech z MIT nějak v lásce.
"nikdo netouzi po tom"
"jejichz vykon je proti C tragicky"
"kompilace vetsich projektu se tak natahla na nekolikanasobek"
...trololololo... :)
Mimochodem, nikdo přeci netvrdí, že tam nemohou být komponenty v C *tam, kde je to na místě*. Ale v případě komplexních datových struktur to na místě zpravidla není, z několika důvodů, které dobře známe již dvě dekády či déle.
Ne, nesouvisi. Sice nevim jak je na tom gcc, ale s Clang/LLVM delam neustale, a nemuzu rict ze by to bylo nejak uber bezchybnej softik :) a "prekotny vyvoj" v GCC je oproti Clangu nejspis eufemismus ;) ostatne prave proto ted preslo LLVM na verzovani X.0.0 - protoze kazda verze je tak odlisna, ze si uvedomili ze je trapne se tvarit ze 3.8 je minor update 3.4, kdyz je praticky pulka kodu jina..
(jo maji C API ktere drzi kompatibilni, ale to API je dobre akorat na Hello world, cokoliv vyznamnejsiho musite delat s C++ "API" ktere nema zadne garance, protoze to neni API vy proste jen dratujete dovnitr kompilatoru.... tudiz se pripravte na vlnobiti #ifdefu ve svem kodu.. uplna paradicka :)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.