C Is Not a Low-level Language

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

good argument for using Assembly ?

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

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

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

Иначе да ти отговоря на въпроса: Асемблерът не помага да се решат основните проблеми, за които говори статията - структурирането на кода така, че да има максимално количество паралелизъм, който не е на ниво инструкции (т.е. ILP), и наличието на йерархия на паметта (инструкциите за prefetch-ване не помагат особено, а понякога даже вредят). Всъщност асемблерът помага за използването на SIMD, но този тип паралелизъм не е основният интерес на автора, въпреки че го разисква.

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

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

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

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

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

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

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

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

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

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

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

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

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