BG Development


Страници: (4) [1] 2 3 ... последна »  ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> C Is Not a Low-level Language
Demigod
Публикувано на: 13-08-2018, 22:51
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 4300
Регистриран на: 26.04.09



https://queue.acm.org/detail.cfm?id=3212479

good argument for using Assembly ?


--------------------
being insane is so .... liberating ....
PMEmail Poster
Top
ici
Публикувано на: 14-08-2018, 01:18
Quote Post


Group Icon
Име: Ивайло Илчев ики
Група: VIP
Ранг: Почетен член

Мнения: 15601
Регистриран на: 06.06.04



LLVM бил 200000 реда? O R'LY? GCC е над пет милиона и за всяка платформа има мръсни трикове които трябва да ги знаеш. Стандартната библиотека има мръсни трикове с които използва или неутрализира GCC. HAL има мръсни трикове с които използва тези на стандартните библиотеки или ги неутрализира. ОС-а има мръсни трикове. Чак тук има някаква прах върху този боклук която сме поръсили ние. Дали е C, Java или Асемблер има малко или никакво значение. В една яма с лайна, дали ще седнеш по турски или ще клечиш също няма никакво значение, важното е главата да не е потопена.


--------------------
Както и при християнската религия, така и при социализмът, най-лошата реклама за идеята са нейните последователи. - Джордж Оруел
PMEmail PosterUsers Website
Top
AK-85
Публикувано на: 14-08-2018, 05:02
Quote Post



Име:
Група: Потребител
Ранг: Старо куче

Мнения: 775
Регистриран на: 06.07.06



Смешното в статията (въпреки че фактите, изложени в нея, са като цяло верни) е, че напълно отговаря на клишето за академичния идеалист. Ще минем на паралелни програми, но някакси ще забравим за съществуването на закона на Амдал... Дори и да пишем на великите функционални езици, ще ми е много интересно да видя как се паралелизира код, който се състои основни от редукции (или по функционалному - fold-ове), които не използват асоциативни и комутативни операции като събиране.

Иначе обсъждането на loop unswitching предизвиква недоумение, а описанието на SVE в ARM архитектурата ме хвърли в потрес - даже произходът на съкращението е объркан; не е "Scalar Vector Extensions" (Редакторът спал ли е, че е оставил такъв оксиморон!), а е "Scalable Vector Extension", което загатва за едно от основните качества на разширението. Параграфът за Ниагарата на "Sun" изпуска момента, че на никого не му дреме дали функционалните блокове на процесора са заети, а за колко време се изпълнява кодът (и класическата книга за компютърна архитектура на Хенеси и Патерсън натъртва на точно това в една от първите глави).

Иначе да ти отговоря на въпроса: Асемблерът не помага да се решат основните проблеми, за които говори статията - структурирането на кода така, че да има максимално количество паралелизъм, който не е на ниво инструкции (т.е. ILP), и наличието на йерархия на паметта (инструкциите за prefetch-ване не помагат особено, а понякога даже вредят). Всъщност асемблерът помага за използването на SIMD, но този тип паралелизъм не е основният интерес на автора, въпреки че го разисква.
PM
Top
johnfound
Публикувано на: 14-08-2018, 08:31
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6707
Регистриран на: 27.05.04



Асемблер гарантирано няма да помогне да се паралелезират алгоритмите. За това нищо няма да помогне. Просто трябва да се осъзнае, че закона на Мур е мъртъв и никога вече няма да има експоненциален ръст на производителността на хардуера.

А начина по който се разработва софтуера в момента разчита именно на експоненциален ръст на производителността. Поради тази причина, в момента има натрупан огромен технологичен дълг и датата на падежът му е близко.

А изплащането на този технологичен дълг се състои в оптимизация на кода – оптимизацията вече не е "преждевременна". Точно сега е момента.

И тука идва ролята на асемблера – Че каква оптимизация е възможна без асемблер? Разбира се, много фирми още не са осъзнали прискърбния факт, но изплащането на технологичния дълг ще отнеме десетилетия и именно свалянето на нивото на използваните езици и оптимизациите на ниско ниво ще осигурят увеличаването на производителността през този период.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
dvader
Публикувано на: 14-08-2018, 09:33
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 4125
Регистриран на: 12.07.05



QUOTE (johnfound @ 14-08-2018, 08:31)
Че каква оптимизация е възможна без асемблер?

Всякаква...
Лош алгоритъм написан на микрокод не става добър алгоритъм.


--------------------
I find your lack of faith disturbing
PM
Top
ici
Публикувано на: 14-08-2018, 09:43
Quote Post


Group Icon
Име: Ивайло Илчев ики
Група: VIP
Ранг: Почетен член

Мнения: 15601
Регистриран на: 06.06.04



Представи си съвсем мизерен сензор голям два милиметра заедно с двата пина. Със специален дебъгер влизаш в конзола на питон и го настройваш да стане сензор за антифриз или за температура на входящият въздух или медицински термометър. Малка промяна на кристала и това вече е безжичен датчик за налягането в гумите. Кода необходим за тази трансформация е 20 реда. Никой не работи за "твоето" бъдеще. То отдавна е минало.


--------------------
Както и при християнската религия, така и при социализмът, най-лошата реклама за идеята са нейните последователи. - Джордж Оруел
PMEmail PosterUsers Website
Top
johnfound
Публикувано на: 14-08-2018, 10:02
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6707
Регистриран на: 27.05.04



@ici: Аз говоря (а и статията е) за малко по-други софтуерни и хардуерни системи.

@dvader: Много от "оптималните" алгоритми са далеч по-четливи на асемблер, отколкото на езици от високо ниво. Достатъчно е да погледнеш която и да е високо оптимизирана библиотека на C. Но защо да ходим толкова надалеч – еволюцията на кода на нашата с тебе битка е достатъчно илюстративен – твоят код от добре структуриран, четлив код, еволюира в пълна каша, само за да се доближиш по производителност до асемблерския код, който така и си остана четлив и прегледен.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
ici
Публикувано на: 14-08-2018, 10:46
Quote Post


Group Icon
Име: Ивайло Илчев ики
Група: VIP
Ранг: Почетен член

Мнения: 15601
Регистриран на: 06.06.04



Четлив и прегледен за кой? Знаеш ли му името?


--------------------
Както и при християнската религия, така и при социализмът, най-лошата реклама за идеята са нейните последователи. - Джордж Оруел
PMEmail PosterUsers Website
Top
Golden Gega
Публикувано на: 14-08-2018, 11:24
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 974
Регистриран на: 04.06.10



Мислете малко по-креативно. За един проект е по-важно TCO-то, отколкото брилянтните технологични решения. Например - когато една машина с масовите и евтини средства за производство на софтуер не може да реши даден проблем, се взимат няколко машини. Облаци, микросървиси и прочее - всички те дават по-евтини решения от хипер-ултра-гига технологични оптимизации.
Но пък няма лошо да има някой и друг Дон Кихот който блъска по някоя романтична, но нереалистична кауза.
PMEmail Poster
Top
johnfound
Публикувано на: 14-08-2018, 12:17
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 6707
Регистриран на: 27.05.04



QUOTE (ici @ 14-08-2018, 11:46)
Четлив и прегледен за кой? Знаеш ли му името?

Четлив и прегледен сорс, на какъвто и да е език означава, че този който го чете трябва да знае въпросния език. А по-конкретно, колкото по-ниско ниво на знание на езика се изисква за да разбереш сорса, толкова по-четлив е този сорс.

@Golden Gega: Тънкия момент е там, че голямо количество от задачите изобщо не могат да се решават паралелно. Тогава твоите облаци и разпределени системи са напълно безполезни. Даже при задачи, които се разпаралеляват почти напълно, но съдържат някаква последователна част, нещата стоят трагично – погледни споменатият по-горе закон на Амдал.

Не напразно почти всички игри изискват от процесорите производителност на една нишка. А АМД, които заложиха на многоядрени процесори следвайки модните тенденции в продължение на години губеха пазари и чак когато пуснаха ядро с върхова производителност за една нишка, предложиха реално конкурентен продукт.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (4) [1] 2 3 ... последна » Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0