Комментарии 142
Ох какой длинный комментарий.
Какое милое КПДВ. А можно до конца цитировать плз?
Вся цитата на КДПВ не влезла, а если серьезно, то вам не кажется что само предложение уже противоречивое: Код в три раза медленнее или после модификации работает так же, вы определитесь уже? И моя претензия что таблица не обновлена остается в силе :) Да и ваша цитата про модификацию далее по тексту. Вообщем имхо кдпв на то и кдпв чтобы быть провакационным, надеюсь вы не обижаетесь. Хм… возможно я ваши цитаты не обозначил что они именно ваши — исправлю.
Вполне может. Алиасинга того же нет, да и вообще язык строже.
В данном случае это не явно не проявилось. С удовольствием посмотрю на других примерах.
Если вы таки посмотрите на дизасм
Если вы таки прочтете мой пост внимательно…
Вы сами видите что на ллвм min разворачивается в абсолютно разные инструкции в зависимости от окружающего кода. В хаскель коде ведь просто min от двух аргументов, так что вопрос про списки вообще не стоит. Более того вы там переставили порядок аргументов в версии через {} и без неё, что тоже важно. К тому же, на gcc можно тоже путем флагов или прагм (не точно) выбрать во что развернется min.
march=native дает минимальный прирост, а иногда даже делает хуже я не помню точно, давно было. Тут никакой авто-векторизации нету, так что толку от него имхо мало.
и различные реализации C++ между собой больше различаются, чем хаскель и быстрейшая реализация на плюсах.
Ну у хаскеля вообще разброс в 10 раз. Но вы можете проверить как он будет себя вести при перестановках порядка сравнения и т.п. Я же предложил это в заключительной части. Я вангую что будет то же разброс в 2-3 раза в зависимости от комбинации данные + код что и у С++.
По поводу всего остального. Я Хаскель упомянул только в первой части, и показал как именно эквивалентный 1в1 код на С++ дает примерно тот же результат на этой задаче. И почему мелочи важны. Далее речь про разные компиляторы и т.п. Кто выиграл не так интересно как почему, и тут ответ как раз кроется в cmov vs jump что и было показано.
Эм, а где там написано, что он работает так же?
Так у вас показано в таблице для Си — там 103%. Это и есть так же. Ну и у меня так же.
Там нету ни одного векторного регистра в теле внутреннего цикла, вы мой асм смотрели или нет?)
И это баг в llvm.
Это не совсем баг, можно переставить ветвление в разном порядке, каждый будет лучше для определенного паттерна входных данных. Какой он как выбирает не понятно. В хаскеле же вы тоже юзаете эту багофичу. Не ужили я так плохо написал что не донес эту мысль :(
Ну у хаскеля вообще разброс в 10 раз.
Там у вас их куча на графиках. Мы точно про одну и ту же задачу говорим. Я не про wc если что.
Ну вот про эту разницу я и прокомментировал что дело в march=native. Можно в этом ковыряться еще но это дает процентов 10, по сравнению с разницей в два раза.
заточек под компилятор
Это была не заточка под компилятор а под данные. Что я продемонстрировал на примере разных данных. В чем смысл сравнения решений, если порядок "==" разный?
Когда я с этим игрался, то порядок аргументов, дававший выигрыш для clang, ухудшал время работы при компиляции gcc.
Это всё равно заточка под данные. Просто разный компилятор по разному раскрывал min.
Upd: на самом деле там много разных мелочей, тот же +1 до или после сравнения. Например, последний вариант гцц который самый быстрый на "аааа" стороках, тоже проседает на рандомных данных, я думаю потому что там закрался бранчинг. Правильно отпрофайлить бранчинг сложно (см. статью про wc), я показал более подробнее основной момент.
Я про то, что он зачем-то спиллит регистры.
Кто гцц или шланг?
Вполне может. Алиасинга того же нет, да и вообще язык строже.
Но скорее всего с llvm так не поступает. Потому что вот например Rust
попытался передавать где только может "restrict" и llvm сломалось,
пришлось не выпендриваться: https://github.com/rust-lang/rust/issues/54878
Непонятно, правда, причём тут LLVM, если это дело фронтенда.
Простите, а что, при передаче в LLVM массив внезапно забывает, что у него константная длина? Почему и фронтенд, и бекенд не могут оба делать эту работу? Хотя раз она может и должна делатся бекендом, то зачем ее делать фронтенду?
Вообще, все эти срачи про языки становятся надоедливыми. Я не понимаю, в чем их смысл. Начинать с идеоматического кода и потом обмазывать его всякими хаками по основам исследований, а что лучше в данный конкретный момент с данными конкретным компилятором и на данных конкретных данных — это сравнение хитрецы и навыков реализатора, но никак не языков. Сравнение языков будет, если вы дадите задачу реализовать сотне студентов, которые только что прочти "XXX для чайников" и сравните результат.
Проблема в том, чтобы поставить эксперимент, потому что в такой постановке никто не мешает студенту засунуть в середину вычислений код для подсчета котиков в интернете, а введение формальных правил, типа "используйте то" или "не используйте это" — прямое нарушение условий эксперимента. С другой стороны, постановка условия в виде "реализуйте оптимальнейшим образом" обязательно приведет к тому, что часть особо умных прочитают еще что-нибудь по языку и просто спустятся поближе к уровню ассемблера, что и сделали авторы всех обсуждаемых статей. Так что сравнение языков — это будет сравнение наивных подходов на этих языках к реализации задач. Но не забывайте, что наивный подход в каждом языке разный — банальный (но не точный, просто для иллюстрации) пример — использование рекурсии в ФП языках и цикла в императивных. Наивный алгоритм будет диктоваться как задачей, так и общей философией языка. На этой уровне уже начинает влиять то, как именно была построено обучение в "XXX для чайников", так что идеального сравнения никогда не будет — всегда найдется к чему придраться.
Если на языке нельзя, пользуясь приемами, описанными в вводной книжке, которую можно прочитать за вечер, написать близкий к идеальному код — это плохой язык. Все остальное — это уже демонстация опыта и глубоких пониманий конкретных реализаций, что, ИМХО, от языка никак не зависит.
Если на языке нельзя, пользуясь приемами, описанными в вводной книжке, которую можно прочитать за вечер, написать близкий к идеальному код — это плохой язык.Вот именно фразы, подобные этой, приводят меня в бешенство.
Да, если ты — ублюдочная девочка, борящаяся «за всё хорошоее и против всего плохого» (а в реальности твоих спонсоров волнует чтобы картинка хорошо по TV смотрелась и больше ничего) — то подобные высказывания нормальны.
Если же вы реально хотите чтобы мир стал лучше — то стоит задуматься. Любая сложная задача имеет простое, легкое для понимания — но неправильное решение.
Почему так? Потому что абстракции протекают и потому единственный способ сделать язык «хорошим» в вашем смысле — это сделать его настолько тупым и неэффективным, что это станет неважно. Ну там QuickBasic, Python, JScript, JavaScript в Netscape 2.0 и так далее.
Далее, проходит несколько лет, люди, пользующиеся этим вот всем, замечают что язык у них — как бы «хороший», но очень уж медленный и ресурсоёмкий. Его оснащают разного рода JIT'ами и примочками типа NumPy, язык становится «плохим»… и через несколько лет всё повторяется.
Пожалуйста — не будьте Гретым Туборгом, это ни к чему хорошему не придёт.
Если же вы реально хотите чтобы мир стал лучше — то стоит задуматься.
Когда вы делаете шаг вперед — вы задумываетесь, какие мышцы бедра напрячь, какие силы приложить к каждой кости, какие углы должны быть между костями, учитываете массу надетой сейчас обуви и налипший на ней снег, и тысячу других мелочей, или все же просто берете, и шагаете?
Точно также и с языками — есть те, где вы вынуждены думать о всяких мелочах, которые вот ну совсем никак не должны влиять на конечный результат. О них должен думать компилятор — его затем и придумали. В этих вещах нет и не может быть никакой вариабельности — тупой, как пробка алгоритм, который верен сейчас, был верен сто лет назад и через сто тоже будет верным. Вы же предлагаете постоянно держать эту чушь в голове, делая за компилятор его работу.
А есть те, где это сделано за вас. Ну например. На заре зарождения языков программирования вы вынуждены были нумеровать строки программы, чтобы иметь возможность к ним перейти с помощью GOTO. Даже если вы его никогда не использовали. Затем появились языки, которые выкинули эту чушь из своей грамматики — за строками должен следить компилятор. Стало лучше? Удобнее? Какие-то абстракции протекли от автонумерации строк? Освободились ли головы программистов от необходимости следить, сколько строк занимает программа, искусственно нумеровать строки не через 1, а через 10, или 100, или любое другое число, чтобы иметь возможность вставить что-то в середину без переписывания всей программы?
Далее, проходит несколько лет, люди, пользующиеся этим вот всем, замечают что язык у них — как бы «хороший», но очень уж медленный и ресурсоёмкий.
А может просто они пытаются писать на нем то, что стоило бы писать на чем-то другом, более подходящем? Ну, знаете, вместо лома подметать веником. Но вместо этого вы пытаетесь заменить лом сначала связкой ломов, потом вилами, потом граблями, добавляете им зубцов, делаете из мягкого железа и в виде лент. Да, в итоге получился металлический веник, подметать удобнее, хотя дорогой паркет царапает, но теперь косплеить Фримена использовать его как лом уже нельзя.
Его оснащают разного рода JIT'ами и примочками типа NumPy, язык становится «плохим»…
Само по себе добавление JIT-а или использование библиотек, написанных на другом языке, не делает ваш язык "плохим". Плохим он становится, когда вы начинаете оглядываться, когда вы вынуждены оглядываться на все эти джиты и подобное. Утрированно, вот раньше вы могли расположить переменные в любом порядке, а теперь джиту нравится, только когда порядок вот такой и никакой другой. Причем еще и скачет непредсказуемо, если вы вдруг добавляете переменных, потому что там какой-нибудь хеш считается от списка переменных. И вот вместо того, чтобы думать над задачей, вы начинаете пляски, как вам расположить переменные таким образом, чтобы JIT или сборщик мусора или еще что-нибудь не сломалось. Вы можете сколько угодно знать и оправдывать такое положение вещей, с пеной у рта доказывать, что иначе сделать нельзя, так как абстракции текут, и вообще, программисты совсем обленились, должны же они хоть что-то делать, но это именно то, что делает язык "плохим", хоть ты тресни. И всего этого нет и не будет в книгах "для чайников".
Потому что абстракции протекают и потому единственный способ сделать язык «хорошим» в вашем смысле — это сделать его настолько тупым и неэффективным, что это станет неважно. Ну там QuickBasic, Python, JScript, JavaScript в Netscape 2.0 и так далее.
А мне казалось, что наиболее тупые языки (вроде ассемблера) как раз и являются самыми производительными. Ну или я не понял, что именно вы вкладываете с слово "тупой".
Знаете, где-то слышал:
Если ото всех вокруг воняет дерьмом — может, это ты сам обделался?
Если у вас слишком часто текут абстракции, то может проблема в языке с этими абстракциями? Иногда можно заменить протекшие абстракции менее текущими, иногда их вообще можно выкинуть.
Любая сложная задача имеет простое, легкое для понимания — но неправильное решение.
Как и всякое категоричное утверждение, это нуждается в доказательстве.
Ну да, по-моему, в этих рассуждениях есть рациональное зерно. Чем больше производительности ты пытаешься выжать, тем ниже по технологическому стеку ты вынужден спускаться, и зачастую лучше просто использовать более подходящий язык, чем пытаться исправить дело с помощью компиляторозависимых трюков на менее подходящем. С другой стороны, эти статьи — это скорее познавательные курьёзы для демонстрации этих самых трюков, не нужно рассматривать их столь уж серьёзно.
Потому единственный способ в современных условиях сделать язык «хорошим» — это сделать его медленным и жрущим ресурсы. Зато всегда одинаково. Без «протекающих абстракций».
Это — действительно то, что вы рекомендуете делать?
P.S. Всякие SIMD интринсики у компиляторов не просто так наружу торчат, и в том же benchmarks game программы на совершенно разных языках совершенно не стесняются ими пользоваться «по месту».
Ну вот поэтому иногда и приходится писать "на плюсах как на C", как в уже набившем оскомину примере с std::min и initializer_list. Никто же не отрицает, что такое бывает. Если вопрос важный, а место горячее, лучше уж гвоздями прибить.
Короче, зачем писать на плюсах?Зачем же, зачем и на любом другом языке программирования. На нём можно сделать максимально быстрый код (применив кодогенерацию если уж очень приспичит) — и при этом для написания остального кода вполне можно нанять достаточно программистов, чтобы судьба проекта не была под угрозой.
Тем не менее, зачем мне тут всё писать на С++?Вы хотите сказать, что если вы всё это напишите на Java или Python — будет лучше? Сомневаюсь: эти языки особо экономными никогда не были.
Я что-то всё более скептически отношусь к тому, что на C++ можно нанимать достаточно программистов, которые могут не сломать код, и не потратят уйму времени на написание кода, которому более-менее как-то можно доверять.Это в том случае если вам нужно, чтобы продукт был надёжен и всегда работал. Но нынче это мало кому нужно.
Ну вы прям выбрали альтернативы!Дык эта. Что там в пятёрке ещё осталось? C#/Visual Basic.Net/JavaScript/PHP? Они не сильно лучше…
А скорость тоже мало кому нужна примерно в таком же смысле.Ну не скажите. В том же tensorflow даже раскладку по испонительным блокам CPU прикидывают… разумеется не те, кто «творчески перерабатывают сетки», а те, кто пишут ядро этого самого tensorflow…
просто появляются библиотеки
Из воздуха появляются, наверное :) Самозарождаются, как мыши в грязном белье у ван Гельмонта, никто их разработкой не занимается, все только «пишут немного клея на питончике», и все работает :)
P.S. Сейчас ради интереса посмотрел — у того же TF почти 2.5K одних только прямых контрибуторов.
К счастью, мне никто не ставил условий «чтоб язык реализации был в топ N».Ну вам не ставили. А многим другим — ставят. Большинству причём. Как правило в компании есть вполне конечный набор языков, которые можно использовать (потому что HR знает как нанять разработчиков на этих языках). И расширить его непросто.
Но да, есть редкие исключения — там и Haskell можно и Scheme и даже Forth… но это редкость.
И таких инструментов становится всё больше, а потребности в умении (или возможности) писать жутко оптимизированный вычислительный код на местах — всё меньше.Тут есть некоторое противоречие — если «таких инструментов становится всё больше», то, очевидно, для их разработки требуется всё больше людей.
Пользователей этого всего — да, ещё больше… но это уже другая история.
Собственно отсюда и рождается ограничение на языки. Про то, что специалисты по Cobol, Fortran, C++ или даже Java лет через 20-30 будут в наличии — очевидно.
А вот со всякими модными, но молодыми языками — вопрос очень сложный…
Ой, вы не про этого гуся? А про того, которого на ферме не так далеко от того лесопарка откармливали? Ну так это другое дело!
</sarcasm>
Чтобы ваша аналогия с гусями чего-то стоила — нужно знать кто, где и как собирается «удушить» С++.
Вот в случае с взлётом и падением Pascal я могу всё описать легко. Turbo Pascal 1.0, в 1983м — это был офигительный прорыв, по сравнению с популярным тогда Microsoft Pascal — это был прорыв. Microsoft пытался с этим бороться (QucikBasic и QuickPascal, да) — но не смог.
Потому было принято решение Microsoft Pascal закорыть и кинуть все силы на Visual Studio. И это сработало: Delphi был популярен почти только на территории СНГ, а после того, как удалось сманить к себе ещё и разработчиков Borland C++… вопрос был закрыт.
Ахилессовой пятой Pascal оказалось то, что, фактически, популярность получил не Pascal как таковой, а один, конкретный (причём нестандартый) диалект…
А вот где вы видите кого-то, кто так же вот поступит с C++ (и, главное, почему это ему позволят сделать) — мне неясно.
Как, опять же, конкретный пример: на одной из прошлых работ было что-то вроде...
«вот был у нас проект на языке X, мы допустили типовую для этого языка ошибку Y и столкнулись с типовой проблемой Z, а вот если бы мы писали на языке A, то с проблемой Z мы бы точно не столкнулись (и давайте промолчим про проблему B)».
Пусть X = java, Z = потребление оперативки. Или X = python, Z = низкое быстродействие. Или X = rust, Z = отсутствие наследования. Или X = haskel, Z = отсутствие человека, способного выразить логику программы в функциональном стиле. При этом для таких проблем обычно существуют типовые решения. Например, в расте вместо ООП советуют использовать ECS. А в доброй половине комбинаций проблема/яп типовым решением будет переписать на плюсы.
И тут возникает резонный вопрос: почему для других языков нормально иметь типовые проблемы и типовые же методы их решения/предотвращения, а плюсам — нет?
Не могу назвать отсутствие наследования само по себе типовой проблемой.проблема возникает когда человек пытается свою ООП логику выразить в доступных расту терминах. И если делать это максимально в лоб, эмулируя наследование композицией, а не «мыслить иначе», получится очень много бойлерплейта и очень переусложненная архитектура.
Примерно то же самое мы наблюдаем в плюсах когда человек пытается архитектуру приложения сделать полностью шаблонной, там, где отлично бы справились старые добрые виртуальные классы (интерфейс + реализация).
А какие привычные паттерны из каких других языков перекладываются тут?в обоих случаях человек пытается решить задачу заведомо неоптимальным способом.
Нет, не справились бы. Диспатчинг в рантайме — слишком медленно, когда вам важны наносекунды.LTO и девиртуализация тоже будут работать. А если уже и их будет не хватать, то там, где именно, можно и на шаблонах. А если вы боретесь за наносекунды в масштабах всего проекта, то у вас не такой уж и большой выбор языков программирования чтобы привередничать.
Разве шаблоны и вот это всё не преподносятся в том числе как средство для эффективного решения подобных задач, требующих программирования во время компиляции?давайте вернемся чуть-чуть назад, к моему комментарию:
Примерно то же самое мы наблюдаем в плюсах когда человек пытается архитектуру приложения сделать полностью шаблонной, там, где отлично бы справились старые добрые виртуальные классыЯ говорил об общей архитектуре приложения. Когда мы начинаем шаблонизировать все каркассные объекты в программе, хедеры начинают сильно зависеть друг от друга, а время компиляции TU, их использующих, начинает взрываться. Отдельные горячие участки примерно всегда локальны, выносимы в отдельные же TU, и как бы вы в них не извращались с шаблонами, это будет усложнение лишь одного TU. А теперь вернемся к:
лучше написать код на чем-то другом, где это отдаётся на откуп программистувот это как раз относится скорее к отдельным TU, реализующим те самые горячие участки
Или X = rust, Z = отсутствие наследования.
А вы можете привести пример, когда использование наследования прям-таки необходимо? Потому что мне на ум приходит только GUI.
поэтому в итоге всё это выкинул и закодил самодельный велосипед с полунаркоманским недоjit'ом, но не суть.
Вот про это я бы почитал. Не планируете писать статью?
Анроллы можно делать в С++, я не знаю где они есть в таком же виде ещё. Теперь у вас тоже есть, это здорово. Интринзики это все же уровень выше чем асм и их часто хватает.
А по-поводу mov, дает ли это измеримую разницу?
Когда вы делаете шаг вперед — вы задумываетесь, какие мышцы бедра напрячь, какие силы приложить к каждой кости, какие углы должны быть между костями, учитываете массу надетой сейчас обуви и налипший на ней снег, и тысячу других мелочей,Нет — и именно поэтому я перемещаюсь несколько медленнее, чем, скажем, Усэ́йн Болт.
или все же просто берете, и шагаете?Всё зависит, как мы видим, от того, кто куда идёт. И зачем.
Вы же предлагаете постоянно держать эту чушь в голове, делая за компилятор его работу.Я предлагаю? Нет. Я просто констатирую факт — вы можете этим заниматься. Или не заниматься. Разница будет примерно раз в 5-10. Как и в случае с простым шагом (метр-полтора в секунду или около того) и забегом рекордсмена (10 метров секунду или около того).
На заре зарождения языков программирования вы вынуждены были нумеровать строки программы, чтобы иметь возможность к ним перейти с помощью GOTO.Серьёзно? Вот смотрю я на Fortran II 58го года — и чёт не вижу я таких требований. Потому смысл дальнейшей тирады, извините, от меня успользает.
Обязательная нумерация строк в Basic для мини-компьютеров появилась для удобства — и действительно, если у вас нет приличного экранного редактора — это удобнее, чем попытка рассчитать на какой строке у вас там что находится.
Когда текстовый редактор совместили с компилятором (Turbo Pascal 1.0), то стало понятно, что «есть решение получше».
А вот в случае с выбором между jump и cmov… нельзя сказать что будет лучше, если вы не знаете с какими данными собрались работать.
Само по себе добавление JIT-а или использование библиотек, написанных на другом языке, не делает ваш язык «плохим».Вы идиот? Или играете оного на TV? JIT — это протекающая абстракция. Библиотека, написанная на другом, гораздо более быстром языке — это тоже протекающая абстракция. Да даже банальный кеш процессора — это ещё одна протекающая абстракция.
Как только вы вносите в вашу систему протекающую абстракцию — вы тут же теряете ваше свойство «хорошести»:
Если на языке нельзя, пользуясь приемами, описанными в вводной книжке, которую можно прочитать за вечер, написать близкий к идеальному код — это плохой язык.Извините.
А мне казалось, что наиболее тупые языки (вроде ассемблера) как раз и являются самыми производительными.Это вам только так казалось. Программа 20-летней (или, ещё лучше, 50-летней) давности на ассемблере будет работать сильно медленнее, чем программа той же давности, написанная на C или Fortran. Потому что ассмеблер — он ни разу не исключение, каким вы хотите его представить. Он тоже развивается — и тоже примерно так же, как все остальные языки.
Ну или я не понял, что именно вы вкладываете с слово «тупой».Да всё вы понимаете. «Тупой» для ассмеблера — это без всяких movnti/prefetch2 и movaps/movdqu. И он таки медленее, чем более сложный ассемблер где все эти штуки имеются.
Если у вас слишком часто текут абстракции, то может проблема в языке с этими абстракциями? Иногда можно заменить протекшие абстракции менее текущими, иногда их вообще можно выкинуть.Всё может быть. Но вот мы тут с вами переписываемся на сайте с названием Хабр и вы тут толкаете речи в защиту «хорошего языка» под названием ассмеблер. Ну и где ваш хороший браузер, написанный на этом хорошем языке? Вы же им пользуетесь, правда?
Так что… или ссылку — или, извините, вы таки Гретый Туборг.
Нет — и именно поэтому я перемещаюсь несколько медленнее, чем, скажем, Усэ́йн Болт.
А живет он, наверное на стадионе и межкомнатные двери у него шириной с ворота самолетного ангара — с таким шагом нужно много места. Давайте не будем смешивать то самое оглядывание на JIT, попытку доказать, чей язык круче и решение повседневных задач.
Всё зависит, как мы видим, от того, кто куда идёт. И зачем.
Пока что в вашем примере я вижу одного тюнингованного человека для выполнения работки раз в… 1-3 года? Болид формулы 1 тоже один заезд ездит. Потом его выкидывают. Вы же, я надеюсь, пишите свои приложения несколько на иных принципах.
Разница будет примерно раз в 5-10. Как и в случае с простым шагом (метр-полтора в секунду или около того) и забегом рекордсмена (10 метров секунду или около того).
Но 100 метрах. На 1 километре разница тоже будет такая же, только участники местами поменяются. Все как я и говорил в самом начале — заточились на входные данные, на особенности железа, добавили мелких хаков, хотя задача была дойти из точки А в точку Б.
Вот смотрю я на Fortran II 58го года — и чёт не вижу я таких требований
А дальше в Basic увидели. Или вы зарей считаете только самый-самый первый язык программирования? А что тогда так поздно — википедия сообщает, что можно еще до 19 века начинать отсчет. На английской первый год другой, если вдруг русской не доверяете, но тоже до 1900 года.
Обязательная нумерация строк в Basic для мини-компьютеров появилась для удобства — и действительно, если у вас нет приличного экранного редактора — это удобнее, чем попытка рассчитать на какой строке у вас там что находится.
И правильно — расчетом должен заниматься компьютер. Для этого в более "хороших" языках придумали метки.
А вот в случае с выбором между jump и cmov… нельзя сказать что будет лучше, если вы не знаете с какими данными собрались работать
А я где-то утверждал обратное? Другое дело, что вы должны быть способны предсказать, что если вы используете эту конструкцию, то будет jump, а если эту — то cmov, а при использовании третьей вы сознательно отдаете решение на откуп компилятору. При этом, если от незначительного изменения входной программы результат меняется сильно (по аналогии с вычислением хеша), и это никак не отмечено явно, то такой язык "плохой". Вместо того, чтобы думать над алгоритмом вы вынуждены думать о побочных эффектах.
Вот на примере данный статьи у одного человека замена min({a, b, c}) на min(a, min(b, c)) приводит к сильным изменениям, а у другого нет, на одном компиляторе приводит, а на другом нет. Т.е. имеем вычислительную нестабильность не только от смены представления одного и того же алгоритма, но даже от версии компилятора/реализации стандартной библиотеки!
Как только вы вносите в вашу систему протекающую абстракцию — вы тут же теряете ваше свойство «хорошести»:
Я никаких свойств хорошести не приводил. Я их не знаю. У нас не бинарная логика "хороший — плохой". Я указал лишь факторы, делающие язык "плохим". Опять же, не в абсолютном смысле, а только по сравнению с другими языками (но это, надеюсь, и так понятно).
Это вам только так казалось. Программа 20-летней (или, ещё лучше, 50-летней) давности на ассемблере будет работать сильно медленнее, чем программа той же давности, написанная на C или Fortran. Потому что ассмеблер — он ни разу не исключение, каким вы хотите его представить. Он тоже развивается — и тоже примерно так же, как все остальные языки.
Да неужели? Программы на С или фортране, наверное, имеют самомодифицирующийся код и при запуске на новых процессорах сами себя перепишут под новые инструкции, а на тупом ассемблере не догадались так написать. Гм.
Вопросы же переносимости давайте оставим за кадром, мы не о них говорим
Хабр и вы тут толкаете речи в защиту «хорошего языка» под названием ассмеблер.
Если вы все же перечитаете мой комментарий, то вряд ли найдете там защиту хоть каких-то языков, а тем более определение каких-то языков в "хорошие".
Да всё вы понимаете. «Тупой» для ассмеблера — это без всяких movnti/prefetch2 и movaps/movdqu. И он таки медленее, чем более сложный ассемблер где все эти штуки имеются.
Ассемблер — это просто язык для записи опкодов. Добавление опкодов не делает сложнее язык, лишь процессор, их выполняющий. Усложнением языка будет добавление в него макросов.
Аналогией вашему высказыванию будет, что Си, поддерживающий в идентификаторах Юникод, сложнее, как язык, чем Си, их не поддерживающий.
И, наконец, последнее.
Вы идиот? Или играете оного на TV?
Но вот мы тут с вами переписываемся на сайте с названием Хабр
Именно что Хабр, а не базар. Поэтому у вашего комментарий, на который я отвечаю, минус от меня. Переходить на личности с оскорблениями… плохо
То есть у вас язык может быть одновременно и плохим и хорошим? Извините — но я не настолько гуманитарно одарён.Как только вы вносите в вашу систему протекающую абстракцию — вы тут же теряете ваше свойство «хорошести»:Я никаких свойств хорошести не приводил. Я их не знаю. У нас не бинарная логика «хороший — плохой». Я указал лишь факторы, делающие язык «плохим».
Да неужели? Программы на С или фортране, наверное, имеют самомодифицирующийся код и при запуске на новых процессорах сами себя перепишут под новые инструкции, а на тупом ассемблере не догадались так написать. Гм.Нет, программы на C всего лишь могу изменить своё поведение (и существенно так изменить), если их перекомпилировать. Программы на ассемблере — нет.
Но я боюсь если вам даже это нужно разжёвывать, то остальная дискуссия большого смысла не имеет.
Именно что Хабр, а не базар. Поэтому у вашего комментарий, на который я отвечаю, минус от меня. Переходить на личности с оскорблениями… плохоВозможно. Но изображать из себя дебильную девочку, не умеющую в логику — ещё хуже. Да, я знаю: для того, чтобы заниматься политикой нужно уметь в двоемыслие. Но вот ракету там или ядреный реактор так уже не сделать — физика в двоемыслие не умеет.
А Хабр — это скорее о ракетах, чем о том, как обвести толпу вокруг пальца и получит за это денег в свой карман…
То есть у вас язык может быть одновременно и плохим и хорошим? Извините — но я не настолько гуманитарно одарён.
Это из чего вы такой вывод сделали?! В небинарной логике хорошо != !плохо, из чего не следует, что хорошо = плохо. Хотя, вот как ни странно, некоторые качества могут быть одновременно хорошими и плохими. Возьмем шаблоны C++. Они Тьюринг-полны — это круто, можно выразить что угодно. Они Тьюринг-полны — это кошмар, как их отлаживать? На сегодняшний день даже интерпретатора шаблонов нет! Мало того, код шаблонов обычно никто не комментирует, что хотя бы изредка делают с обычным кодом. Вопрос даже шире — их в общем случае невозможно скомпилировать из-за проблемы останова.
Нет, программы на C всего лишь могу изменить своё поведение (и существенно так изменить), если их перекомпилировать. Программы на ассемблере — нет.
Кто ж с этим спорит. Для этого в C и вводились абстракции. Но это как раз вопрос переносимости на другие процессоры и архитектуры. И не всегда эти самые существенные изменения будут в лучшую сторону, кстати. А если вы будите компилировать новыми компиляторами под старые процессоры, то вы хоть извернитесь, новых команд в выхлопе не получите. Странно, что вам этого не понятно. Поэтому возвращаю вам ваше замечание про логику.
А если вы будите компилировать новыми компиляторами под старые процессоры, то вы хоть извернитесь, новых команд в выхлопе не получите.
Да, но новый компилятор может лучше оптимизировать код. Например, заменить деление на 3 на сдвиг и умножение.
Не важно на каком языке вы пишите. Важно какой компилятор вы используете.
То есть все языки по сути уравниваются. Классическое Нормально делай — нормально будет во всей красе.
И зачем продираться через муки С++, если можно не писать на нем и получать такую же производительность?
Осталось только уравнять компиляторы и вообще хорошо будет. Задачка сложная, но выглядит реально. И пиши вообще на чем удобнее. Все языки равны по производительности будут.
Во-первых не совсем на любом, но все что компилируется в натив через ллвм должно выдават то же самое. Тут ни ГЦ не будет, ни каких то интринзиков. Довольно простой код.
Простой это понятно. Сложный даже сравнивать бессмысленно. Там результаты могут оказаться вообще любыми. И споры будут бесконечны.
Надо рассматривать всесторонне. Так-то в этом коде никаких ужасов С++ нету.
Hot path пишем аккуратно и получается очень быстро, а остальное разворачиваемся и на том же языке пишем удобно. Никаких минусов межязыкового взаимодействия. Никаких ужасов плюсов. Красота же.
В идеале да, но пока всего один простой пример горячего кода. Я не утверждаю что дргуие получатся или нет. Скоро нам расскажут как симды подключить и наладить компайл тайм полиморфизм, и уже какая то часть сценариев покрыта.
Никаких минусов межязыкового взаимодействия. Никаких ужасов плюсова если не пугаться плюсов то вообще красота же?
И зачем писать на плюсах? Скорость это был непробиваемый агрумент. Но он начинает уходить. Все эти ABI и сопутствующая тормознутость стандартной библиотеки очень способсвуют.
И он слишком сложный. Я так и не придумал как культурно объяснить студенту почему в плюсах нет map.contains и надо помнить наизусть что надо писать вот так. А не как очевидно. И море подобных мест.
PS: Я учился писать по книжке Страуструпа. И за код на С++ получал деньги.
Все эти ABI...скажем, многие из-за ABI на плюсах и пишут. Точнее, не уходят с плюсов благодаря возможности поддерживать старые кодобазы
И на них сложнее (чем на любом другом современном языке) писать типовой код.проблемы с плюсами обычно начинаются когда на них пишут уже не типовой код.
И он слишком сложный. Я так и не придумал как культурно объяснить студенту почему в плюсах нет map.contains и надо помнить наизусть что надо писать вот так. А не как очевидно. И море подобных мест.map::count прям сильно не устраивает, да? Тем более что примерно в 100% случаев вы после проверки элемента на вхождение хотите либо нему обратиться, либо его удалить, а делать лукап дважды расточительно. В общем, лучше объясняйте.
И за код на С++ получал деньги.да, а я за код на джаваскрипте получал деньги. Предложите мне написать сайт — отправлю к профессионалам.
Поддержка старых это хорошо и полезно. Но что зачем начинать новый проект на плюсах? Вспомним Перл.
Но что зачем начинать новый проект на плюсах?простой пример: вот стартуете вы абстрактный сервис. Посчитали, прикинули, получилось что при реализации на плюсах вам потребуется 1000 облачных контейнеров по 8 ядер и 30 гб памяти. А при реализации на какой-нибудь джаве — 1500 контейнеров по 16 ядер и 100 гб памяти. Смотрите вакансии и видите, что джависты еще и больше денег за работу возьмут.
Собсвенно о чем и речь. Плюсы стараниями комитета жертвуют скоростью. Также как раньше пожертвовали простотой. И в итоге ни скорости ни простоты не будет. Останется куча легаси, и никаких новых проектов.
Людей меньше, они дороже, писать сложнее и дольше, ошибок большепо сравнению с чем? Джаваскриптом? Ну нанимайте их, пусть они вам бекенды держащие десятки тысяч rps пишут
Плюсы стараниями комитета жертвуют скоростьюнасколько вам будет важно быстродействие вашего приложения, если оно не будет работать?
Также как раньше пожертвовали простотойприведите конкретные примеры пожалуйста
по сравнению с чем? Джаваскриптом? Ну нанимайте их, пусть они вам бекенды держащие десятки тысяч rps пишут
Да в общем по сравнению с любым мейнстрим языком.
js не нравится? Ок, есть java, go, c# и иже с ними. На любом из них разработка будет быстрее и дешевле. 10к рпс любой из них выдержит, если нормально написать.
насколько вам будет важно быстродействие вашего приложения, если оно не будет работать?
Позволю себе процитировать недавнюю статью
«Новые программы должны собираться из исходного кода, нам нужны инструменты, построенные на сборке из исходников, а не коллекция библиотек, которые откуда-то достали и как-то вставили в проект.
Да, сборка из исходников — это то, чего не так просто достичь. Но нам нужно поощрять такой подход к продукту, регулярно обновлять компиляторы, чтобы люди получали пользу от новых введенных фич спустя месяц после релиза, а не через десять лет. Нужно поощрять правильные, надежные, масштабируемые и воспроизводимые решения, библиотеки с открытым исходным кодом и систему зависимостей.»
приведите конкретные примеры пожалуйста
Вот ranges из свеженького.
//
Пропустите первые два элемента диапазона и выведите только четные из следующих трех:
for (auto const i : v
| rv::drop(2)
| rv::take(3)
| rv::filter(is_even))
{
print_elem(i);
};Ок, есть java, go, c# и иже с ними. На любом из них разработка будет быстрее и дешевлеа вот это надо доказать
10к рпс любой из них выдержит, если нормально написать.а 20?
Новые программы должны собираться из исходного кодаа если вам приходится работать с проприетарными библиотеками? Ну вот не хотят авторы выкладывать открытый код, а с устройством работать надо. Реверс-инжинирить будете?
Вот ranges из свеженького.а что, код стал сложнее? Давайте для примера:
if (v.size() > 2) {
for (size_t i = 0; i < min<size_t>(v.size() - 2, 3); ++i) {
if (is_even(v[i+2])) {
print_elem(v[i+2]);
}
}
}
for_each(v | rv::drop(2) | rv::take(3) | rv::filter(is_even), print);
а вот это надо доказать
То что на плюсах типичный сервис перекладывающий джейсоны пишется дольше чем на любом другом мейнстрим языке надо доказывать? Вы это серьезно?
Все вот эти вот монстрики Питон + плюсы откуда по вашему появились? Писать 10500 ручек нужных каждом сервису с минимальным рпс на плюсах долго и сложно. И соответвенно дорого.
10к рпс и 20к рпс это просто х2 серверов. На таких маштабах все должно горизонтально маштабироваться. И важнее становятся другие вопросы. Типовые и стандартные: мониторинг, логи, деплой, тестирование. С ними у плюсов я бы тоже не сказал что все хорошо.
а если вам приходится работать с проприетарными библиотеками? Ну вот не хотят авторы выкладывать открытый код, а с устройством работать надо. Реверс-инжинирить будете?
Остаться на старой версии. И приложить усилия для ухода от проприетарной заброшенной библиотеки. Не стоит использовать заброшенные авторами библиотеки без исходников. Это никогда ни к чем хорошему не приводит.
а что, код стал сложнее? Давайте для примера:
а на нормальном языке это так пишется:
list.stream().skip(2).limit(3).filter(this::isOdd).forEach(System.out::println);Земля и небо же. Правда нет любимых плюсовщиками 5 разных варинатов написания одного и того же простейшего куска. Да и форматирование кода у всех одинаковое само собой.
Земля и небо же.
list.stream().skip(2).limit(3).filter(this::isOdd).forEach(System.out::println);for_each(v | rv::drop(2) | rv::take(3) | rv::filter(is_even), print);Правда, что ли? Потому что в одном случае через точку, а в другом — через палочку?
10к рпс и 20к рпс это просто х2 серверовво-первых, не любой сервис хорошо горизонтально масштабируется, особенно если нагрузка между машинками неравномерна. Как-то наверняка отмасштабируется, но вам могут понадобиться уже не 2 а 3 сервера. А во-вторых, это удвоение операционных расходов, которое с лихвой перебьет разработку.
Остаться на старой версиито есть всему миру остаться на с++17 потому что вы решили что ABI стоит постоянно ломать? А для кого тогда эти новые стандарты вообще будут?
И приложить усилия для ухода от проприетарной заброшенной библиотекипочему заброшенной? Может и поддерживаемой, просто авторы останутся на старой версии, и вы вместе с ними.
Не стоит использовать заброшенные авторами библиотеки без исходниковвот есть у вас абстрактный измерительный прибор и библиотека для работы с ним. Ну нет другой, прибор уже влетел вам в копеечку, а пытаться измерять вручную раз в 5 дольше. Ваши действия?
а на нормальном языке это так пишется:а теперь будьте добры скажите чем точка принципиально лучше вертикальной черты?
во-первых, не любой сервис хорошо горизонтально масштабируется, особенно если нагрузка между машинками неравномерна. Как-то наверняка отмасштабируется, но вам могут понадобиться уже не 2 а 3 сервера. А во-вторых, это удвоение операционных расходов, которое с лихвой перебьет разработку.
Софт работающий с десятком к рпс должен маштабироваться горизонтально и линейно. Это прям настолько типовое требование что даже не знаю кто еще не так пишет. Там уже не 2 или 3 сервера. Там пачка контейнеров должна быть. Оркестрирование и все что полагается.
то есть всему миру остаться на с++17 потому что вы решили что ABI стоит постоянно ломать? А для кого тогда эти новые стандарты вообще будут?
Почему заброшенной? Может и поддерживаемой, просто авторы останутся на старой версии, и вы вместе с ними.
Все живые мигрируют. Совместимость по апи естевенно должна быть полная. Смысл не мигрировать? Для старых клиентов оставить старую версию и не трогать ее. Для всех живых мигрировать и выпустить новую. Не так сложно.
вот есть у вас абстрактный измерительный прибор и библиотека для работы с ним. Ну нет другой, прибор уже влетел вам в копеечку, а пытаться измерять вручную раз в 5 дольше. Ваши действия?
Если все совсем запущенно, то сделать прибор as service. И писать весь остальной код на чем хочется. Json спасает.
а теперь будьте добры скажите чем точка принципиально лучше вертикальной черты?
Стандартностью? Разработчики всего привыкли жать точку и IDE им показывает что можно сделать с объектом.
Софт работающий с десятком к рпс должен маштабироваться горизонтально и линейнодолжен, ага. А в реальности у вас балансировка не идеальна и существуют перекосы нагрузки, которые приходится компенсировать дополнительным железом.
Совместимость по апи естевенно должна быть полнаяи какая разница, совместим ли API, если вы с бинарём линкануться не можете?
Если все совсем запущенно, то сделать прибор as service. И писать весь остальной код на чем хочется. Json спасает.посмотрел бы я как вы выхлоп промышленного векторного анализатора цепей будете в json'е гонять.
Стандартностью?будьте так любезны, дайте ссылку на ISO
должен, ага. А в реальности у вас балансировка не идеальна и существуют перекосы нагрузки, которые приходится компенсировать дополнительным железом.
И? Маштабируемся линейно, запас должен быть. Нагрузка увеличилась в 2 раза, надо в 2 раза больше ресурсов. А вот если увеличились в 2 раза, а железа надо в 10 раз больше тут что-то не так.
посмотрел бы я как вы выхлоп промышленного векторного анализатора цепей будете в json'е гонять.
А в чем проблема? Я понимаю там в лейтенси упереться можно, да и то маловероятно. А с объемами какие проблемы? Нынче 10g в пределах ДЦ это норма. Разделяем все по контейнерам как удобно, о сети в пределах ДЦ можно не беспокоится.
будьте так любезны, дайте ссылку на ISO
Ок, жать точку после имени объекта для получения списка возможных действий для программистов нестандартно и неестественно. Продолжайте есть кактус, я не против.
И? Маштабируемся линейно, запас должен быть. Нагрузка увеличилась в 2 раза, надо в 2 раза больше ресурсовповторюсь: проблема может быть в неравномерности нагрузки. Я сталкивался с тем, что перенарезание на меньшее число больших подов (с той же суммой ядер/памяти) давало прирост.
А в чем проблема? Я понимаю там в лейтенси упереться можно, да и то маловероятно. А с объемами какие проблемы? Нынче 10g в пределах ДЦ это нормавы как собрались конвертировать скажем гигабит бинарных данных в json и обратно?
… нестандартно и неестественно.допустим я согласен что пайп менее естественнен чем точка. Но я хоть убей не понимаю почему разница кажется вам существенной
повторюсь: проблема может быть в неравномерности нагрузки. Я сталкивался с тем, что перенарезание на меньшее число больших подов (с той же суммой ядер/памяти) давало прирост.
Есть у нас что-то работающее с рпс (а не считающий процессинг), то это все будет в пределах десятков процентов. Можно не обращать внимания.
вы как собрались конвертировать скажем гигабит бинарных данных в json и обратно?
Гигабит это примерно 100 мегабайт в секунду. Желательно быстрее секунды, мы тем же потоком хотим еще что-то делать.
Не будем гадать, а лучше напишем наивный тест. Никаких оптимизаций, никакой паралельности. Ничего. Прямо и в лоб. Сериализатор вот этот https://github.com/alibaba/fastjson
static class Data {
public byte[] val;
}
public static void main(String[] args) {
Random random = new Random();
List<Data> dataList = new ArrayList<>(); //100Mb will be here
for(int i=0; i<1000; ++i) {
Data data = new Data();
data.val = new byte[1024 * 100]; //100k bytes
random.nextBytes(data.val);
dataList.add(data);
}
long time = System.currentTimeMillis();
for(int i=0; i<100; ++i) { //10G total
dataList.stream().forEach(JSON::toJSONString);
}
long time2 = System.currentTimeMillis();
System.out.println(time2-time);
}
На jdk11 и моем стареньком i5 получилось 19767 миллисекунд. Или 19 секунд на 10 гигабайт. Или 0.2 секунды на 100 мегабайт. Пусть даже мои измерения неточные и ошибаются в пару раз времени у нас остается с запасом. И это всего лишь одно старенькое ядро. Вопросы?
Вы выразили недоумение как я собрался сериализовать гигабит двоичных данных. Я написал тест и показал что это всего лишь 0.2 цпу.
Мне написать тест перекладывающий флоат в 4 байтика? Или на слово поверите что там проблем с производительностью не будет?
Ок, жать точку после имени объекта для получения списка возможных действий для программистов нестандартно и неестественно.
Это естественно, но нерасширяемо. Идея-то была в том, что допустимые действия может "добавить" любая библиотека, а не только стандартная. С точкой так уже не получится.
10k, 20k… когда Pokemon Go запустили Google получил 700k «лишних», «нерасчётных» Qps. Ещё раз — это не то, что он обрабатывал, это сколько запросов было получено сверх того, что Niantic заказал и оплатил в предварительной заявке.10к рпс любой из них выдержит, если нормально написать.а 20?
Как результат — было принято решение всегда иметь «в запасе» мощности под лишние 1M qps…
Да вроде не такие рэнжи и страшные, по крайней мере этот пример. Через точку было бы проще конечно, но это долгая история, уже обсуждали на хабре.
map::count прям сильно не устраивает, да?
Да сильно. Ибо нелогично, а им и так сложно. Проверка наличия это типовой сценарий для хешмапы. Хешмапы, O(1), вот это вот все. Проверяй, получай, удаляй. Дешево. Пиши смело, софт будет работать хорошо. Студенты, закапываться в тонкости реализации нельзя.
Студенты, закапываться в тонкости реализации нельзя.Как у вас студенты сдают структуры данных и потом не понимают почему делать двойной лукап это плохо?
«если нет запускаем вот этот рассчет и кладем результат в мапу», то все равно экономия на спичках. Читаемость, простота и понятность важнее.
Если на каждое такое простое действие будет делать в два раза больше движений, то и вся программа будет работать в два раза дольше. А contains() можно было добавить, это сахар, кстати в C++20 добавили.
Синтаксический сахар это наше все. Все языки его вводят в оптовых количествах. Проще разработка, понятнее исходники, приятнее писать, меньше ошибок. Вот это вот все.
Ввели и хорошо. Всего-то лет 20 прошло от того момента когда надо было вводить. Пойду поищу следующую такую же очевидную вещь которую надо было лет 20 назад ввести в стандарт.
Два это контанта. Пофиг. Не из-за этого софт тормозит.Два это «не совсем константа» и тормзит именно из-за неё.
В развитой инжереной дисциплине улучшение в 12%, легко получаемое, никогда не рассматривается как несущественное — и я верю, что подобный же подход должен возобладать и в програмимровании.Это, собственно, цитата из той самой статьи откуда вырвали из контекста (и подняли на флаг, чтобы оправдать создание груды дерьма) цитату про «преждевременную оптимизацию».
Ну потому что Петя сделает два вызова вместо одного (два же — это константа, пофиг), Вася сделает на своём уровне то же самое, Таня и Коля… а когда у вас этих слоёв с десяток — получаем эффективность всей конструкции в 0.1%.
P.S. И да, конечно изначальное зло — это, собственно, наличие этого десятка уровней абстракции… но зачастую с этим ничего поделать нельзя: ну не умещается программа на миллион строк в голове у одного человека… ну никак.
Два для О(1) это всего лишь два. Чтобы получить 0.1% надо повторить много раз. Я с трудом представляю себе такую конструкцию. И скорее всего в ней будут гораздо более серьезные проблемы.
Я с трудом представляю себе такую конструкцию.Посмотрите на свой телефон. Или на свой веб-сайт. Запрос пары байт из базы проходит обычно от 20 до 30 «слоёв абстракции». И нет, там нет замедления в тысячу или в миллион раз… именно потому что авторы этого всего знают о том, что два — это не много, а очень много. 12%, указанные Кнутом — нормально.
По очереди. И после простейшей переделки на балк все начинает работать быстро.Если всё так чудесно, то почему больше нет веб-сайтов, которые бы не тормозили? Почему открытие документика на мегабайт в Google Docs на современном железе занимает столько же, сколько открытие такого же документа на эталонной IBM PC XT на 4.7Mhz в MIM (и да, я не издеваюсь: MIM вполне открывал такие файлы на IBM PC XT с 256Kb RAM)?
Да, я понимаю, новые возможности, коллаборация, всё такое… но машинка у нас даже не тысячу раз быстрее, а в десять тысяч раз быстрее сегодня!
Если всё так чудесно, то почему больше нет веб-сайтов, которые бы не тормозили? Почему открытие документика на мегабайт в Google Docs на современном железе занимает столько же, сколько открытие такого же документа на эталонной IBM PC XT на 4.7Mhz в MIM (и да, я не издеваюсь: MIM вполне открывал такие файлы на IBM PC XT с 256Kb RAM)?
Вы серьезно? На XT у вас не было возможностей сделать за пару нажатий кнопок документы с современным оформлением и форматированием. За эти возможности надо платить.
Быстродействия должно быть достаточно. Быстрее часто просто не надо. Средний пользователь на среднем компе доволен и хорошо. Зачем тратиться на дальнейшее ускорение? Лучше фичу запилить.
Если хочется тех интерфейсов и даже расширенных (по сравнению с теми временами) возможностей есть vim. Работает моментально на всем. Функционала гораздо больше чем тогда было. И он даже удобнее чем редакторы тех времен.
Выбор есть. Пользуйтесь чем хочется. Никто не принуждает же.
За эти возможности надо платить.Почему я должен платить за возможности, которые мне нафиг не нужны?
На XT у вас не было возможностей сделать за пару нажатий кнопок документы с современным оформлением.Была, конечно. Достаточно было использовать нужный
\documentclass. И при этом при переносе из издания в издание формат менялся автоматом.Выбор есть. Пользуйтесь чем хочется. Никто не принуждает же.Как мне с помошью VIM'а прочитать ваш и оставить свой оставить комментарий на Хабре?
Собственно всё, что нужно знать о современной разработке — это тот факт, что четверть века назад в журналах было полно статетей про то, что и как нужно сделать в системе, чтобы поставить новую версию Turbo Pascal или Windows… а сегодня — не меньшее число статей о том, как избежать обновлений. И огромное количество людей воспринимают информацию о том, что кто-то где-то выпустил обновление не как повод порадоваться новым возможностям, а как зло, с которым всё тяжелее и тяжелее бороться.
Отчасти это, конечно, обусловлено тем, что раньше те, кто обновляться не хотел могли ничего не делать, а теперь, наоборот им и приходится прилагать дикие усилия… но, с другой стороны, тот же Debian появился в 1993м году, автообновления там появяились примерно тогда же и, насколько я знаю, никогда такого потока статей в духе «как остановить этот беспредел, творимый Windows 10» он не вызывал…
Почему я должен платить за возможности, которые мне нафиг не нужны?
Потому что они сделаны для среднего пользователя. Он согласен. Мейнстрим всегда идет за массой. Для всех остальных есть разные варианты.
Как мне с помошью VIM'а прочитать ваш и оставить свой оставить комментарий на Хабре?
Какой Хабр. Во времена XT даже модемы были экзотикой. А тут и картинки, и автоподгрузка, и редактор. Не хотите не пользуйтесь. Ресурсы похожие на ресурсы тех времен (хотя опять таки гораздо лучше) и не требующие никакой производительности от клиентов живы. Кто хочет берет и пользуется ими. Выбор есть.
Судя по всем статистикам народ обновляется. Массово и без особых проблем. Отклонения есть, но достаточно незначительные чтобы ими пренебречь.
Win10 80% store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=combined
Win10 40% radar.yandex.ru/desktop?selected_rows=XtlYgg%252Cn2QA91
Доля везде растет. Все ок.
К чему приводят необновления все в it уже в курсе. Скоро каждая лампочка обновлятьcя начнет. И мир от этого станет только лучше.
www.forbes.com/sites/thomasbrewster/2016/09/25/brian-krebs-overwatch-ovh-smashed-by-largest-ddos-attacks-ever/#74c3f5855899
Во времена XT даже модемы были экзотикой.Не были. CBBS появилась в 1978м году, а XT, как бы, через 5 лет. Compuserve же поддерживал чаты и форумы с 70х — тоже всё до появления XT.
Не хотите не пользуйтесь.Это, кстати, неплохая идея — нужно будет обдумать.
Ресурсы похожие на ресурсы тех времен (хотя опять таки гораздо лучше) и не требующие никакой производительности от клиентов живы.О! Ну вот давайте обсудим «ресурс тех времён» — GO BPROGA (описанный, в частности, в README к Turbo Pascal 4.0 прямо в дистрибутиве, а появившийся ещё раньше). С форумами, где можно связаться с разработчиками прочим.
Что посоветуете? Ну, такого, чтобы «не требующие никакой производительности от клиентов»?
Судя по всем статистикам народ обновляется. Массово и без особых проблем.Масово обновляется — это когда через год после выхода Windos 95 уже больше половины пользователей работают с ней, а через две Windows 3.x уже не поддерживается почти никакими новыми программами.
А когда система, вышедшая более 10 лет назад, и более вообще официально не поддерживаемая, оказывается более популярна, чем вышедшая 4 года назда замена… то это не «массово обновляется», это «несмотря на все прилагаемые усилия производителям удаётся заставить пользователей обновиться… иногда… если повезёт».
К чему приводят необновления все в it уже в курсе.К тому, что моя мать может не тратить денег на новое железо и спокойно смотреть ролики на YouTube с помощью компьтера на Intel Atom десятилетней давности?
Скоро каждая лампочка обновлятьcя начнет.Это вряд ли. Для этого нужно будет, чтобы кто-то выпуска обновления для этих лампочек. А зачем это нужно если можно, вместо этого, продать вам новую?
И мир от этого станет только лучше.Это вы называете «мир стал лучше»? Что помешало сделать эти долбаные камеры не подверженными уязвимостям изначально? Новомодный принцип «хуя… и в продакшн» («хуя… — это потому что традиционный „хуяк-хуяк“ это нынче слишком дорого и сложно)?
www.forbes.com/sites/thomasbrewster/2016/09/25/brian-krebs-overwatch-ovh-smashed-by-largest-ddos-attacks-ever/#74c3f5855899
То, что нынче каждая лампочка норовит обновиться по поводу и без повода — сделало мир только хуже, на самом деле. И не потому, что сами по себе обновления — зло. А потому что это позволило разработчикам перестать думать о надёжности и безопасности. Лепи любое гавно, потом выпустим обнову, всё исправим!
О! Ну вот давайте обсудим «ресурс тех времён» — GO BPROGA (описанный, в частности, в README к Turbo Pascal 4.0 прямо в дистрибутиве, а появившийся ещё раньше). С форумами, где можно связаться с разработчиками прочим.
Что посоветуете? Ну, такого, чтобы «не требующие никакой производительности от клиентов»?
Предложу начать с мейл листов. Ну хотя бы вот отсюда https://lkml.org/ Клиента не требующего ресурсов сами найдете?
А когда система, вышедшая более 10 лет назад, и более вообще официально не поддерживаемая, оказывается более популярна, чем вышедшая 4 года назда замена… то это не «массово обновляется», это «несмотря на все прилагаемые усилия производителям удаётся заставить пользователей обновиться… иногда… если повезёт».
Софт стал настолько хорош что можно бежать чуть медленее. Геймеры бегут быстрее, все остальные медленее. Но бегут все. Ну и заодно стоит поблагодарить всех за совместимость. Много-много лет совместимости. Во времена win3.1 такой совместимости не было.
К тому, что моя мать может не тратить денег на новое железо и спокойно смотреть ролики на YouTube с помощью компьтера на Intel Atom десятилетней давности?
Это же ужастно. Могли бы и подарить чего посвежее. Атомы тормозили с момента выхода.
Это вряд ли. Для этого нужно будет, чтобы кто-то выпуска обновления для этих лампочек. А зачем это нужно если можно, вместо этого, продать вам новую?
Совместимость и стандарты. Всех заставят. Как продать новую маркетологи придумают, я за них вообще не переживаю.
А потому что это позволило разработчикам перестать думать о надёжности и безопасности. Лепи любое гавно, потом выпустим обнову, всё исправим!
Предлагаю начать с написания кода без багов. Вот заживем.
Предложу начать с мейл листов. Ну хотя бы вот отсюда lkml.org Клиента не требующего ресурсов сами найдете?LKML — это хороший пример старого проекта, сохранившего верность старым традициям. К сожалению это — скорее редкое исключение, чем правило. Новых проектов, появившихся в последние лет 10 и использующих списки рассылки для общения вместо веб-сайтов типа того же GitHub'а, я пожалуй, не назову ни одного.
Во времена win3.1 такой совместимости не было.Была, конечно. Почти все программы под DOS отлично работали на любой версии от 3.30 и новее. И программы для Windows 3.1 работают аж даже в Windows 10 (32-битной, правда).
Просто быстрый переход на Windows 95 позволил так же быстро отказаться от поддержки Windows 3.1. Несмотря даже на то, что ради этого перехода многим приходилось докупать память и иногда компьютеры целиком.
Это же ужастно. Могли бы и подарить чего посвежее. Атомы тормозили с момента выхода.Пробовал — не получается. Старые люди «прикипают» к вещам. Вот нравится ей вот конкретно этот моноблок (который моей сестре выдали на обанкротившейся фирме вместо зарплаты) — и хоть ты тресни. Собственно основная претензия — как у всех: у Windows 10 ну вот севершенно «неправильное» стартовое меню… и вообще все кнопочки. Когда YouTube перестанет поддерживать и Firefox 52… придётся что-то придумывать.
Всех заставят.Это кто и как их заставит? Пока что даже подавляющее большинство моделей смартфонов ни одной обновы за всю свою жизнь не получает, не говоря уже про роутеры, а вы хотите, чтобы лампочки кто-то вам обновлял…
Предлагаю начать с написания кода без багов. Вот заживем.Ну совсем без багов — это вряд ли. А без возможности удалённо взломать систему — можно железку сделать… только мало кому нужно.
LKML — это хороший пример старого проекта, сохранившего верность старым традициям. К сожалению это — скорее редкое исключение, чем правило. Новых проектов, появившихся в последние лет 10 и использующих списки рассылки для общения вместо веб-сайтов типа того же GitHub'а, я пожалуй, не назову ни одного.
Значит они не востребованны. Востребованные проекты делают и живут без проблем. Могу предложить пользоваться теми ресурсами которые нравятся ине пользоваться теми которые не нравятся. Выбор, пусть даже в некоторых случаях и не особо богатый, есть. В конце концов вы же программист. Контрибутить в проекты по своему вкусу это хорошо.
Просто быстрый переход на Windows 95 позволил так же быстро отказаться от поддержки Windows 3.1. Несмотря даже на то, что ради этого перехода многим приходилось докупать память и иногда компьютеры целиком.
Не. Вышло все не поддерживающее win3.1. Вот примерно вообще все. И у людей не было выбора. Пришлось обновляться. А сейчас все поддерживают старые версии очень долго.
Это кто и как их заставит? Пока что даже подавляющее большинство моделей смартфонов ни одной обновы за всю свою жизнь не получает, не говоря уже про роутеры, а вы хотите, чтобы лампочки кто-то вам обновлял…
Где вы такие телефоны берете? Даже более-менее приличные китайы обновляются минимум пару лет с даты выхода. Самсунги с Эплами получают обновления заметно долше.
Ну совсем без багов — это вряд ли. А без возможности удалённо взломать систему — можно железку сделать… только мало кому нужно.
Без багов и без возможности удаленного взлома это синонимы. Сейчас почти все смотрит в интернет. С приходом ipv6 вообще все будет смотреть в интернет. А баги в типовых библотеках и операционках находят регулярно.
Где вы такие телефоны берете?Я их нигде не беру. Но это не значит, что их нет.
Даже более-менее приличные китайы обновляются минимум пару лет с даты выхода.Что, собственно, и отличает их от «неприличных». Коих по количеству моделей (но не факт, что по продажам) — большинство.
Без багов и без возможности удаленного взлома это синонимы.Нет, не синонимы ни разу. Чтобы не было возможности удалённого взлома нужно не так много вещей: драйвер сетевой карты без уязвимости, да проверка сертификата без таких же проблем. И то и другое можно, при желании, сделать. Да, не совсем тривиально и обойдётся не совсем крошечные деньги — но это возможно.
А баги в типовых библотеках и операционках находят регулярно.Их там находят ровно потому что никому не нужно и неинтересно тратить время и силы на написание софта без багов.
Вот посмотрите сюда… ну или сюда. Вы хотите сказать, что MTA — более простая задача, чем прошивка, опрашивающая три датчика и рисующая три формочки (а это типичной объём функциональности в IoT лампочке)? Не смешите мои тапочки, пожалуйста.
Вся эта бесконечная истерия по поводу «борьбы за безопасность», одновления и прочее — это театр. Он призван обеспечить у людей ощущение того, что за их безопасность «усиленно борются». Если бы кому-то безопасность была реально интересна — её можно было бы обеспечить… но это — никому не нужно.
Вот посмотрите сюда… ну или сюда. Вы хотите сказать, что MTA — более простая задача, чем прошивка, опрашивающая три датчика и рисующая три формочки (а это типичной объём функциональности в IoT лампочке)? Не смешите мои тапочки, пожалуйста.
Лампочке надо слушать порт. Все же хотят ее с телефона включать. Значит ОС, http, json, пароли, сертификаты. И полный набор всего типового софта следом. Не писать же ради лампочки вот это вот все.
Вся эта бесконечная истерия по поводу «борьбы за безопасность», одновления и прочее — это театр. Он призван обеспечить у людей ощущение того, что за их безопасность «усиленно борются». Если бы кому-то безопасность была реально интересна — её можно было бы обеспечить… но это — никому не нужно.
Там где обновляют софт там проблем гораздо меньше.
Вспомним недавние эпидемии шифровальщиков. Обычное обновление полностью от них защищало.
Безопасность и обеспечили, утечки и взломы из-за 0day уязвимостей происходят гораздо реже чем из-за необновляемого софта или кривых рук настройщиков.
По сути нерешаемые дыры только во всяких iot остались. Компы, телефоны, да даже роутеры обновляются и проблем в среднем не имеют.
Дыр в китайских прошивок достаточно. И во многом потому что там какой то пхп веб морда на коленке с sql инекциями. Потому что фреймворки, которые позволяют не думать, не влазят в память роутера.
Вспомним недавние эпидемии шифровальщиков.Вспомним, да. И вспомним о том, что компьютер моей матери (XP, напоминаю) их не заметил. А обновления на него не приходили… давно, однако.
Обычное обновление полностью от них защищало.Если «обычное обновление» от них защищало — то откуда тогда взялись эпидемии?
Безопасность и обеспечили, утечки и взломы из-за 0day уязвимостей происходят гораздо реже чем из-за необновляемого софта или кривых рук настройщиков.Результат такой же, как если бы вы пришли куда-нибудь, сели посреди комнаты, оставили дурно пахнущую кучу — и повесили бы вентилятор, чтобы пахло чуть поменьше.
Компы, телефоны, да даже роутеры обновляются и проблем в среднем не имеют.Не знаю где вы обнаружили обновляемые роутеры. Не могу сказать, чтобы я роутеров видел уж сильно много, но ни одного, к которому выходили бы обновления прошивки больше одного-двух лет я не видел. А эксполуатируются они по 5-10 лет легко.
По сути нерешаемые дыры только во всяких iot остались.Ну если рассуждать как авторы статей This aggressive IoT malware is forcing Wi-Fi routers to join its botnet army (свежая статья, кстати, конец прошлого года) — то да, наверное. А если в IoT записать и датацентры Гугла и смартфоны с синхрофазотронами — то вообще ничего, кроме IoT уязвимостей не имеет…
Вспомним, да. И вспомним о том, что компьютер моей матери (XP, напоминаю) их не заметил. А обновления на него не приходили… давно, однако.
Я очень хочу верить что люди со статьями на Хабре способны настросить комьютеры и роутеры в своей эпсион окресности так чтобы их вирусы не касались. А вот всякие рабочие сети заражаются. Там всем пофиг. Особенно в гос и около гос конторах. Им тлько обновления помогут.
Не знаю где вы обнаружили обновляемые роутеры. Не могу сказать, чтобы я роутеров видел уж сильно много, но ни одного, к которому выходили бы обновления прошивки больше одного-двух лет я не видел. А эксполуатируются они по 5-10 лет легко.
Все не совсем ужастный китай вполне себе обновляются. Иногда надо приложить руки, но обновляются. Хочется верить что следующее поколение даже без прикладывания рук обновляться сможет.
Ну если рассуждать как авторы статей This aggressive IoT malware is forcing Wi-Fi routers to join its botnet army (свежая статья, кстати, конец прошлого года) — то да, наверное. А если в IoT записать и датацентры Гугла и смартфоны с синхрофазотронами — то вообще ничего, кроме IoT уязвимостей не имеет…
Да в общем тоже самое. В ДЦ Гугла нет проблем. Их БД никто не продает, значит инкто не сломал. Не ставишь обновления — у тебя проблемы. Нет обновлений — у тебя проблемы. Не надо покупать устройства которые не поддерживаются и не обновляются. Маркетологи скоро это поймут и начнут рекламировать соответвенно.
А вот всякие рабочие сети заражаются. Там всем пофиг. Особенно в гос и около гос конторах. Им тлько обновления помогут.Не помогут. Если бы помогало — никаких эпидемий WannaCry не было бы.
Их БД никто не продает, значит инкто не сломал.Странная логика. Не знаю — имеют ли спецслужбы их БД сейчас, но как история со Сноуденом показала — несколько лет назад у спецслужб базы были. А может и не только у спецслужб. А в переходах в метро — не продавались и на ThePirateBay не лежали.
Маркетологи скоро это поймут и начнут рекламировать соответвенно.Судя по тому, сколько усилий прилагается к противоположному (это и Project Treble и все эти все эти APEXы) — всё движется скорее в обратном направлении.
Не помогут. Если бы помогало — никаких эпидемий WannaCry не было бы.
Ровно от него обновления и помогали. По этой эпидемии очень хорошо стало понятно кто не обновляется.
Странная логика. Не знаю — имеют ли спецслужбы их БД сейчас, но как история со Сноуденом показала — несколько лет назад у спецслужб базы были. А может и не только у спецслужб. А в переходах в метро — не продавались и на ThePirateBay не лежали.
Логика простая. Кто что кому отдает добровольно в данном случае не очень интересно. А вот украть не могут. Иначе бы продавали. История со Сбером очень показательна. 2 доллара за полную историю транзакций любой карты.
Логика простаяИ неверная.
Кто что кому отдает добровольно в данном случае не очень интересноВот только Google никому ничего «добровольно» не отдавал. Вы бы почитали то, что Сноуден накопал перед тем, как в теории заговора удаляться.
Спецслужбы даже не стали взламывать ничего. А воспользовались тем, что в былые времена у Гугла не было шифрования данных внутри локальной сети и в эту сеть входили роутеры, арендуемые у магистральных провайдеров, больших и малых.
Спецслужбы тупо сломали один такой и получили возможность видеть всё, что происходит в сети.
Ошибка в дизайне и ваш любимый IoT, никакого заговора.
Шифровать внутрисетевой трафик надо. Никто с этим не спорит. Этим по сути недавно озаботились. Роутеры и прочее тут не причем. Ошибка дизайна большой системы. Бывает. Поправят.
В мега утечку из Гугла я все равно не верю. Такое всегда выплывает и продается. Спецслужбы первые идут продавать то что у них есть. Все базы всех госорганов продаются. Массово и недорого.
Это только пока вы не имеете дело ни с чем сложнее char'ов и int'ов.
Суть примерно такая — функциональщики мало внимания уделяют реальному миру и много виртуальным алгоритмам. Сишники много возятся с реальностью (процессоры, регистры, железные оптимизации) и мало с виртуальностью (математика вообще). В итоге два мира смотрят друг на друга свысока, но всё же сишники несколько завидуют функциональщикам, ведь те реально демонстрируют знание каких-то разделов математики, хоть и мало полезных, но не изученных оппонентами. И вот эта неизученность гложет. А тут повод — можно заткнуть за пояс «этих математиков». Отсюда серия статей.
На самом деле обе стороны ничуть не лучше в плане интеллекта, но просто у них разная специализация. А математическая «продвинутость» (как кажется функциональщикам) есть лишь следствие необходимости изучать подаваемый именно с математической точки зрения материал о своих любимых ЯП. При этом абстрактные высоты, естественно, затмевают низкий уровень, начинает казаться, что там внизу одни негры делают грязную работу. Ну и далее очень быстро возникает желание поучать негров, например бенчмарками ФП vs С. Только в данном случае, так сказать, нашла коса на камень.
И урок из данной темы, на мой взгляд, стоит в первую очередь извлекать именно функциональщикам. Чисто психологический — не зазнавайтесь. А вот сишникам (и прочим сторонникам низкоуровневых подходов) всё же стоит интересоваться альтернативными подходами к программированию, просто что бы не на случайном удачном примере о производительности рассуждать, а (по возможности) на равных отметать высокомерные заявления некоторых функциональщиков именно на их территории. Но для этого нужно изучать чужие подходы. И как раз такое занятие не нравится ни функциональщикам, ни сишникам.
Нужно учиться понимать друг друга. Банально, но пока оба мира не интересуются друг другом, будет только вот такая «мягкая» война, когда неудачный пример одной стороны вызовет бурю ликования с другой (ну ладно, не ликования, а разумеется, взвешенного анализа, но с целью показать, что оппоненты слабаки и не увидели того, что на самом деле нужно было увидеть).
Разрыв между двумя лагерями вроде бы очевиден, но оба лагеря не хотят этот разрыв ликвидировать. И потому война (в мягком виде) продолжается. Поэтому стоит подумать именно о психологических причинах происходящего. Ну и написать статью «Почему С лучше Хаскеля», но за авторством функционального сообщества, а потом «почему Хаскель лучше С», но за авторством сообщества низкоуровневой разработки. То есть честно признать плюсы оппонентов. Как бы психологически трудно это не было.
Ваша лирика это всё правильно, но как же статья не техническая? что ни одна из тех что были на хабре? Какой тех части вам не хватает? Проблема в том что в хаскель коде от фп остались только циклы через рекурсию. Конечно всё еще есть гарантии по поводу сайд эффектов, но в рамках одного куска кода это значения не имеет.
Я имел ввиду набор из map/filter/reduce и прочих штучек, которые теоретически можно было ожидать в подобной задаче. Мне комментатор выше предлагал познать высокие материи фп (ничего против них не имею), но они для моего сравнения не нужны. Они покажут себя только на более большой кодовой базе. Больше никакого подтекста.
В данной заметке мы рассмотрели способы оптимальной реализации алгоритма Вагнера-Фишера, который требует O(n*m) времени (два вложенных for). Хотя по ссылке выше есть и алгоритм Хиршберга, который работает за линейное время
Статья отличная, но вот в данном предложении, вроде бы, должна быть память, а не время, время и там, и там — квадрат.
Сравнивается в таких случаях естественно с неоспоримым лидером в производительности — С/C++Сильное заявление.
Лидерство С/C++ давно оспорено ЯП, не обладающими бременем совместимости ABI
habr.com/ru/company/yandex/blog/488588
habr.com/ru/post/480608
ABI это про стандартную библиотеку, тоже важно, но не так критично.
А про бенчмаркинг-гейм можно писать отдельно похожие разборы, хотя С там все ещё первый.
Если с ним сравнивают, и очень радуются когда удается его догнать, то утверждение косвенно подтверждается. Проверить утверждение полностью я действительно не могу.
Сравнивали Haskell и C++, а сравнили jump и cmov