M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем".
Я бы лично такое написал, подразумевая, что с сишной/плюсовой базой человек элементарно более скилловый и понимая разработку на низком уровне (хотя плюсы — ЯВУ), с легкостью освоит и Го. Ну и в целом с такой базой проще работать на любом языке (за минусом экзотики) и фреймворке.
M>Область плюсов сужается
да
M>идет замена в принципе
да
M>нет областей где плюсы выглядели бы незаменимы?
такие области есть, но их все меньше
Тут основной критерий: стоимость разработки. А он включает в себя: стоимость специалистов, скорость найма, скорость написания кода, время на поддержку (maintenance), затраты на баги. И в большинстве своем (а сейчас 90% — это стандартный CRUD) плюсы ну очень сильно проигрывают всем другим языкам (питон, Шарп, джава, пхп, JS/TS и т.д.) в этом аспекте.
При всем при этом, да, есть области, где без него никуда: требуется скорость, низкоуровневое взаимодействие, есть много старых либ на плюсах и Си, с которыми надо интегрироваться, много кодовой базы на плюсах, ну и люди — хранители доменных знаний, которые знают лучше всего плюсы.
Из примеров: игровые движки, CAD, все что касается сети, эмбеддед, ессно, ну и мультимедиа на низком уровне. Есть и еще — это что навскидку вспомнил.
Здравствуйте, undo75, Вы писали:
U>а так — немецкий значительно лучше для ругани, например подходит, чем французский. и т.д. и т.п.
У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
M>>Они замечательно пишутся и на плюсах, и получается гораздо лучше. Ну, если, конечно, под железку есть плюсовый компилятор
U>всегда думал что под ембеддед на асме пишут. нафиг на высокоуровневом языке. даже с?
Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой. Табличное решение с интерполяцией. Я сразу же взялся за ассемблер, а вариант писать на C я даже не рассматривал. После того как реализовал и всё это успешно взетело, мне мой тогдашний руководитель предложил реализовать то же самое на Сях, благо это было не сложно. Когда же я сделал это и посмотрел в сгенерированный код, я прозрел. И навсегда потерял желание состязаться с компилером в оптимизациях. Компилер меня уделал и по памяти, и по производительности.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Философ, Вы писали:
M>>Что за ерунда? Самый простой путь — берёшь uint32_t, и говоришь, что точка посередине, т.е. число с фикс точкой формата 16b.16b.
Ф>Да, ты прав — я тут посовещался с qwen'ом на эту тему. BCD действительно сильно медленее. Квэн говорит, что именно твой подход использовался в игровых движках. Ф>Однако, похоже, всё определяют цели.
Да ты мыслитель
Ф>Я всякие чаты вот таким вопросом мучал: Ф>
Действительно ли ручная реализация fixed-point арифметики может привести к потере точности. Приведи примеры, где ручная реализация fixed-point приведёт к потере точности, а использование BCD — нет.
Ф>
Когда лучше использовать BCD
Ф>
Ф> Бухгалтерские программы Ф> Кассовые аппараты Ф> Системы учёта налогов Ф> Встроенные терминалы Ф>
Ф>📌 BCD позволяет точно представлять такие числа, как `0.1`, `0.01`, `0.001` и т.д., без ошибок округления.
Да, фиксед поинт не позволяет точно хранить десятичные числа с дробной частью. Собственно, как и floating point числа — там мантисса и экспонента всё равно по основанию 2, но десятичные числа для бухгалтерии можно хранить не в целых рублях и дробных копейках, а в целых копейках или даже в долях копеек, и тогда ничего не потеряется.
Или, если очень нужно точное представление дробных десятичных чисел, можно использовать что-то типа marty::Decimal (если что, точка там плавает). Точность у меня может теряться только при делении (по умолчанию для деления используется точность 18 знаков после точки).
А если нужны целые большой размерности, то можно глянуть в буст, или посмотреть на marty::BigInt — целые числа произвольного размера.
Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем".
Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Здравствуйте, Pzz, Вы писали:
M>>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы? Pzz>А в какой области плюсы были бы незаменимы?
Из очевидного — браузеры?
ТАкже библиотеки со всякой математикой, параллельные вычисления, СУБД, сетевые приложения с видеокодеками и всякой обработкой. Короче, там где надо писать производительный код одновременно на разных уровнях абстракции: и ближе к железу, и оптимизации, и логику.
Здравствуйте, Нomunculus, Вы писали:
Н>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Здравствуйте, Философ, Вы писали:
Ф>Фиксированную точку вроде через BCD реализуют (реализовывали). Это вроде бы наиболее корректный и производительный путь.
Что за ерунда? Самый простой путь — берёшь uint32_t, и говоришь, что точка посередине, т.е. число с фикс точкой формата 16b.16b.
Сложение/вычитание — просто складываешь/вычитаешь, ничего больше делать не нужно (ну, только следить за переполнением, но это тоже элементарно).
Умножение — расширяешь множители до uint64_t, умножаешь, результат сдвигаешь на 16 бит вправо, усекаешь до uint32_t — всё, готово.
Деление — аналогично умножению, только сдвигать надо влево (или не нужно, сейчас что-то лень думать).
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем".
У меня такое впечатление, что на Go пишут в основном бакенд и прочие микросервисы.
M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Здравствуйте, Nuzhny, Вы писали:
M>>>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы? Pzz>>А в какой области плюсы были бы незаменимы?
N>Из очевидного — браузеры?
Ну, если учесть, что их ровно два, оба написаны на плюсах и вот так вот взять, и написать с нуля новый независимый третий — занятие малореальное, то...
N>ТАкже библиотеки со всякой математикой, параллельные вычисления, СУБД, сетевые приложения с видеокодеками и всякой обработкой. Короче, там где надо писать производительный код одновременно на разных уровнях абстракции: и ближе к железу, и оптимизации, и логику.
По моим наблюдениям, библиотеки со всякой математикой сейчас всё больше на питоне пишут. Я понимаю, что у неё внутри неонка реальный код на C/C++, а питон этим всем только дерижирует, но тем не менее.
Насчет СУБД и сетевых приложений я бы поспорил. В основном этот код говорит, где взять и куда положить, а остальную работу делают даже не драйвера накопителей и сетевых карт, а их контроллеры, если уж мы говорим о реально высокой производительности.
Видеокодеки, опять же, их мало кто пишет, остальные в основном используют. И пишут их нередко на Си, не на C++. Там же из высокоуровневых абстракций, в основном, массив чисел или матрица их же. С другой стороны, я не вижу причин, почему бы и на Rust-е не написать...
M>>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Pzz>А в какой области плюсы были бы незаменимы?
automotive, биржа?
вся низкоуровневая логика машинного зрения?
железное оборудование типа касс, бензоколонок?
то что я слышал лет 10 назад, как сейчас не в курсе
Здравствуйте, Pzz, Вы писали:
N>>Из очевидного — браузеры? Pzz>Ну, если учесть, что их ровно два, оба написаны на плюсах и вот так вот взять, и написать с нуля новый независимый третий — занятие малореальное, то...
Подожди, а Сафари? Получается, что три.
И ещё был один от Майкрософт а, который после IE, но до текущего. Его писали, писали, пальчики устали и забросили. К этому времени, C# был уже хорошей взрослой технологией. Был Rust. Но нет же.
Pzz>По моим наблюдениям, библиотеки со всякой математикой сейчас всё больше на питоне пишут. Я понимаю, что у неё внутри неонка реальный код на C/C++, а питон этим всем только дерижирует, но тем не менее.
Не тем не менее, а так и есть. От низкого уровня до прикладного написано на C++. Конечный код математики и дата саентимты уже на Питоне. Но его же можно свободно писать и на C++, потому что API для него присутствует параллельно с питоновским.
Pzz>Насчет СУБД и сетевых приложений я бы поспорил. В основном этот код говорит, где взять и куда положить, а остальную работу делают даже не драйвера накопителей и сетевых карт, а их контроллеры, если уж мы говорим о реально высокой производительности. Pzz>Видеокодеки, опять же, их мало кто пишет, остальные в основном используют. И пишут их нередко на Си, не на C++. Там же из высокоуровневых абстракций, в основном, массив чисел или матрица их же. С другой стороны, я не вижу причин, почему бы и на Rust-е не написать...
То есть ты отрицаешь тот факт, что системное ПО тоже кто-то пишет? Или что? Да, понятно, что ниша плюсов сузилась, но вопрос же был в том, где он незаменим, а не в том насколько эта ниша широка.
Здравствуйте, Nuzhny, Вы писали:
N>>>Из очевидного — браузеры? Pzz>>Ну, если учесть, что их ровно два, оба написаны на плюсах и вот так вот взять, и написать с нуля новый независимый третий — занятие малореальное, то...
N>Подожди, а Сафари? Получается, что три. N>И ещё был один от Майкрософт а, который после IE, но до текущего. Его писали, писали, пальчики устали и забросили. К этому времени, C# был уже хорошей взрослой технологией. Был Rust. Но нет же.
Сафари — близкий родсвенник гуглохрому. Можно сказать, дядя. Который ит MS, тот умер и больше уже ни на чём не пишется.
N>То есть ты отрицаешь тот факт, что системное ПО тоже кто-то пишет? Или что? Да, понятно, что ниша плюсов сузилась, но вопрос же был в том, где он незаменим, а не в том насколько эта ниша широка.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем".
Я так пишу. Мне нравится Go своей еб*****стью (не такой как все). Появляется мотивация пошевелить мозгами в другую сторону — дофамин. Но думаю, что если писать на ставке каждый день, то надоест так — же, как и всё C-подобное.
M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Так сравнивать Go с плюсами, думаю, не корректно. Go — это сборщик мусора. Сборщик мусора — это вмешательство в работу твоего кода. В плюсах такого нет. Драйвер со сборщиком мусора писать неприятно. Встойку — тоже.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Ничего общего.
Тут дело в другом. Часто учат студентов именно по классическим языкам — как С++. Другого они тупо не знают пока.
А реальная жизнь требует более приземленных языков, которые решают более простые задачи — ведь не всем компиляторы да движки браузеров писать. Вот и приходится приглашать таким образом.
Здравствуйте, Shmj, Вы писали:
S>Тут дело в другом. Часто учат студентов именно по классическим языкам — как С++. Другого они тупо не знают пока.
S>А реальная жизнь требует более приземленных языков, которые решают более простые задачи — ведь не всем компиляторы да движки браузеров писать. Вот и приходится приглашать таким образом.
Эдсгер Дейкстра считал, что сложные задачи требуют простых языков. Но нонешнее поколение решателей сложных задач, наверное, круче Дейкстры...
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Мне предлагали работу по переписыванию сервисов с cpp на go. Наверное, просто хотели отрефакторить старое и сделать более поддерживаемым и начальство почему-то посчитало что одновременный переход на go имеет смысл. Сам я go знаю поверхностно, не могу сказать, насколько это хорошая идея
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Областью плюсов и так уже сузилась.
А в чём собственно вопрос ?
Когда можно писать на Go проще и быстрее, то логичным будет вопрос, а для чего выбирать плюсы.
В области бэкэнда гораздо больше библиотек для Go и интеграций с различными сервисами.
У Go есть определённые преимущества ну и конечно недостатки в виде недоязыка (кхе-кхе ).
Здравствуйте, Pzz, Вы писали:
Pzz>Сафари — близкий родсвенник гуглохрому. Можно сказать, дядя. Который ит MS, тот умер и больше уже ни на чём не пишется.
То есть браузеры, раз возражений нет.
Pzz>Что есть системное ПО?
Ты знаешь ответ на этот вопрос.
Pzz>docker — это системное ПО?
Конечно системное. Но много ли написано докеров? Или его написали один раз и все пользуются.
Здравствуйте, Pzz, Вы писали:
Pzz>Эдсгер Дейкстра считал, что сложные задачи требуют простых языков. Но нонешнее поколение решателей сложных задач, наверное, круче Дейкстры...
Что-то мне подсказывает, что Дейкстра писал совсем другое ПО с другими требованиями
Здравствуйте, Nuzhny, Вы писали:
Pzz>>Эдсгер Дейкстра считал, что сложные задачи требуют простых языков. Но нонешнее поколение решателей сложных задач, наверное, круче Дейкстры...
N>Что-то мне подсказывает, что Дейкстра писал совсем другое ПО с другими требованиями
Ну я и говорю, ношнешнее поколение круче Дейкстры.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, merge, Вы писали:
M>>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы? __>Мне предлагали работу по переписыванию сервисов с cpp на go. Наверное, просто хотели отрефакторить старое и сделать более поддерживаемым и начальство почему-то посчитало что одновременный переход на go имеет смысл. Сам я go знаю поверхностно, не могу сказать, насколько это хорошая идея
видимо очередному менеджеру требуется в достижениях за год написать "переписали старый говносервис на новый которые быстрее и легче поддерживать"
Здравствуйте, Pzz, Вы писали:
Pzz>А system-config-printer?
Не знаю, что это такое, но по названию явно оно. Там тоже много математики, которую можно и нужно переносить на GPU?
Pzz>А много ли написано ядер операционных систем, которыми люди пользуются?
Явно не много. И они написаны не только на С. Значит ли это, что С не нужен?
Здравствуйте, Nuzhny, Вы писали:
Pzz>>А system-config-printer?
N>Не знаю, что это такое, но по названию явно оно. Там тоже много математики, которую можно и нужно переносить на GPU?
Это — стандартная прогдамма настройки принтеров для Linux.
Pzz>>А много ли написано ядер операционных систем, которыми люди пользуются?
N>Явно не много. И они написаны не только на С. Значит ли это, что С не нужен?
Тезис, который я оспариваю, заключается в незаменимости C++ для системного программирования.
system-config-printer так ваще на питоне написан.
Но конечно, если что-то уже написано на C++, то оно так и будет по наследству тянуться до бесконечности.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
С какой-то точки зрения все языки "заменяют С++".
Ну, просто потому, что на C++ можно написать вообще всё.
Значит, всякий раз, когда кто-то выбирает для проекта X язык Y, он (осознанно или неосознанно) делает выбор между Y и С++. Не в пользу С++.
И либо этот выбор оказывается ошибкой (ой, мы так и не смогли написать прошивку для bluetooh-метки автосигнализации на питоне), либо приводит к успеху проекта.
Если проекты в какой-то нише при реализации на Y оказываются успешными достаточно часто, значит можно говорить о том, что Y заменяет C++ в этой нише.
Вот в нише "RESTful web-services" С++ заменяется на примерно любой язык, от Перла и Лиспа до JavaScript.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали:
Pzz>Тезис, который я оспариваю, заключается в незаменимости C++ для системного программирования.
Я этот тезис и не выдвигал, кстати. Исходный посыл:
Из очевидного — браузеры?
ТАкже библиотеки со всякой математикой, параллельные вычисления, СУБД, сетевые приложения с видеокодеками и всякой обработкой. Короче, там где надо писать производительный код одновременно на разных уровнях абстракции: и ближе к железу, и оптимизации, и логику.
Если какое-то ПО является системным, но его пофиг на каком языке и писать, то пусть и пишут.
Переход на системное ПО был в свете: Pzz>Видеокодеки, опять же, их мало кто пишет, остальные в основном используют
Мы же не говорим о том, что много пишут, а что мало. Понятно, что чем дороже разработка, тем меньше народа такое пишет. И что ниша С++ сжимается. Но тут также как с браузерами — пока никто и не пытается, хотя и возможности, и шанс у той же Майкрософт были. Ну и что, что кодеков пишут мало? Их же пишут. Вот, нейросети 99% пишут на Питоне на PyTorch, но ядро его libTorch написано на С++. Ну и что, что на С++ мало — пишут же, тут Питон его заменить не может, Go тоже, Rust не пытается. И таких системных библиотек, новых и свежих, довольно много. Могу ссылок накидать, если хочешь.
Здравствуйте, Nuzhny, Вы писали:
N>Мы же не говорим о том, что много пишут, а что мало. Понятно, что чем дороже разработка, тем меньше народа такое пишет. И что ниша С++ сжимается. Но тут также как с браузерами — пока никто и не пытается, хотя и возможности, и шанс у той же Майкрософт были. Ну и что, что кодеков пишут мало? Их же пишут. Вот, нейросети 99% пишут на Питоне на PyTorch, но ядро его libTorch написано на С++. Ну и что, что на С++ мало — пишут же, тут Питон его заменить не может, Go тоже, Rust не пытается. И таких системных библиотек, новых и свежих, довольно много. Могу ссылок накидать, если хочешь.
Я тут выяснил случайно, что задача:
1. Прочитать PNG-файл размером 5100x7016, цветной, 8-битный
2. Смасштабировать в два раза в любую сторону методом билинейной интерполяции
2. Записать в виде PNG-файла
требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Здравствуйте, Pzz, Вы писали:
Pzz>требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
О, на Go уже свои libpng есть? Круто
Pzz>Так что я не вижу таких уж особых проблем в написании кодеков на Go. Не скинешь ссылку? Интересно
Здравствуйте, Nuzhny, Вы писали:
Pzz>>требует примерно одинакового времени CPU, как в реализации на чистом Go, так и в реализации с помощью ImageMagic (на чём он там написан? C или C++, не помню точно).
N>О, на Go уже свои libpng есть? Круто
Здравствуйте, Pzz, Вы писали:
N>>О, на Go уже свои libpng есть? Круто Pzz>Даже прям в стандартной библиотеке.
Пишут, что в быстродействии очень много зависит от zlib. Видимо, много библиотек уже используют многопоточные версии всех стандартных библиотек, в отличие от классических на С, поэтому так хорошо и выступают. Но круто, да.
Видеокодеки для видео сильно сложнее, их разрабатывают отдельные команды конкретно под устройство обычно (наряду с ванильными версиями, да). Не уверен, что у Го получится так просто ворваться.
Здравствуйте, Nuzhny, Вы писали:
N>>>О, на Go уже свои libpng есть? Круто Pzz>>Даже прям в стандартной библиотеке.
N>Пишут, что в быстродействии очень много зависит от zlib. Видимо, много библиотек уже используют многопоточные версии всех стандартных библиотек, в отличие от классических на С, поэтому так хорошо и выступают. Но круто, да.
Не, он однопоточный, насколько я понимаю.
N>Видеокодеки для видео сильно сложнее, их разрабатывают отдельные команды конкретно под устройство обычно (наряду с ванильными версиями, да). Не уверен, что у Го получится так просто ворваться.
Здравствуйте, Pzz, Вы писали:
Pzz>Я тут выяснил случайно, что задача... Pzz>Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Гошка плохо подходит для задач нагруженных вычислениями — её для другого делали: гошка — превосходный инструмент для задач, сильно нагруженных I/O операциями.
В гошке управление планировщиком скрыто от программиста — нет возможности "привязать" горутину к конкретному ядру. Это мешает оптимизации кэширования: непредсказуемость попадания горутин на потоки OS приводит к "cache coherence overhead". Тащемта это одна из основных причин, по которым в игровых двужках прибивают отдельные потоки к ядрам с помощью CPU affinity mask.
Вторая причина — в гошке нет штатных способов контроля за расположением полей в памяти — это чрезвычайно важно, например для того, чтобы избежать false-sharing. Из-за этого там используют вот такие уродские решения:
type PaddedShared struct {
A int64
_ [56]byte // Заполнение до размера кэш-линии (64 байта)
B int64
}
Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
Не надо писать на гошке вычислительные задачи!
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Pzz>>Я тут выяснил случайно, что задача... Pzz>>Так что я не вижу таких уж особых проблем в написании кодеков на Go.
Ф>Гошка плохо подходит для задач нагруженных вычислениями — её для другого делали: гошка — превосходный инструмент для задач, сильно нагруженных I/O операциями.
В принципе, да. В корпусе — не такая уж она и медленная, как выясняется.
Ф>В гошке управление планировщиком скрыто от программиста — нет возможности "привязать" горутину к конкретному ядру. Это мешает оптимизации кэширования: непредсказуемость попадания горутин на потоки OS приводит к "cache coherence overhead". Тащемта это одна из основных причин, по которым в игровых двужках прибивают отдельные потоки к ядрам с помощью CPU affinity mask.
runtime.LockOSThread — привязывает гороутинку к нити операционной системы.
Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
Ф>Вторая причина — в гошке нет штатных способов контроля за расположением полей в памяти — это чрезвычайно важно, например для того, чтобы избежать false-sharing. Из-за этого там используют вот такие уродские решения:
Ну, примерно как и в Си
Недавно появились маркеры раскладки структур. Пока только struct.HostLayout
Ф> Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
Здравствуйте, Pzz, Вы писали:
Pzz>runtime.LockOSThread — привязывает гороутинку к нити операционной системы. Pzz>Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
не знал! Спасибо.
Погуглил про этот вызов — похоже на поход по минному полю: https://github.com/golang/go/issues/21827
Сейчас на скорую руку попробовал оригинальный код из гугловой группы — использование этого вызова похоже на хождение по минному полю, оно и понятно: он в общем-то не для этого делался.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф> Третья — поддержка SIMD ограничена: пакет simd появился и существует именно потому, что мы до сих пор не можем положиться на автовекторизацию — вынуждены распространённые операции над массивами векторизовать руками. По крайней мере в марте в документации об этом было написано прямо.
А в каком ЯП (ну кроме ассемблера) можно _полагаться_ на автовекторизацию?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А в каком ЯП (ну кроме ассемблера) можно _полагаться_ на автовекторизацию?
А что не так с C/C++? Говорят, -O3 чудеса творит, особенно с укзанием целевой архитектуры. Говорят, что GCC может автоматически векторизировать циклы
Говорят, что LLVM — один из самых продвинутых компиляторов с т.з. оптимизаций и векторизации.
Я не плюсовик, если что.
Насчёт ассемблера ты круто пошутил конечно Где автоXXXX и где ассемблер...
Мои эксперименты с плюсами регулярно упирались в то, чтобы как-нибудь сделать так, чтобы компилятор не выкинул мой код и время выполнения не было равно нулю. Сломать это поведение было не так то и просто.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Pzz>>runtime.LockOSThread — привязывает гороутинку к нити операционной системы. Pzz>>Ну а дальше можно системно-зависимыми способоами приделять нить к ядру.
Ф>не знал! Спасибо. Ф>Погуглил про этот вызов — похоже на поход по минному полю: https://github.com/golang/go/issues/21827
Не очень понятно с первого прочтения, чего у них там происходит. Может и правда хождение по минному полю, а может у граждан руки-крюки.
Я использовал этот вызов, когда надо было кое-какой гошный код на венду перенести. У венды встречается API, в котором надо сделать серию вызовов, и все должны быть на контексте одного и того же потока операционной системы. Иначе венде плохеет.
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
языки лишь инструменты. не знаю го, но уверен, что какой-нить квейк написать на с++ куда проще чем на бейсике через поук.
сильно сомневаюсь, что на го системные задачи проще решать, чем на с++.
а так — немецкий значительно лучше для ругани, например подходит, чем французский. и т.д. и т.п.
Здравствуйте, undo75, Вы писали:
U>языки лишь инструменты. не знаю го, но уверен...
Сильно советую с ним познакомиться — ты его ещё не раз увидишь, это годный инструмент. Ну а так — да, молотком гвозди забивать удобнее чем гаечным ключом.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, undo75, Вы писали:
U>сильно сомневаюсь, что на го системные задачи проще решать, чем на с++.
Смотря какие задачи.
Например, если задача включает в себя много HTTP и много работы с TLS-сертификатами, то ее значительно проще делать на Go. Благодаря первоклассной поддержке того и другого в стандартной библиотеке.
А много HTTP и много TLS — не редкость для определенного класса системных задач.
Здравствуйте, Нomunculus, Вы писали:
Н>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Нomunculus, Вы писали:
Н>>У меня впн иногда через Германию подключает. И ютуб крутит мне немецкую рекламу. Это жесть. Они даже про туалетную бумагу говорят, как будто на расстрел тебя ведут.
Pzz>Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
Разумеется поэтому. Я ж просто свои ощущения описал
Pzz>Это не потому, что в нас с детства заложена ассоциация между немцами и фашистами?
Джером К. Джером в трое в лодке писал даже) цитата совершенно не точная — по памяти. гуглить лень.
там эпизод был на каком-то приеме. исполнял кто-то песню на немецком. их разыграли, мол вы не знаете немецкого, но на самом деле это очень смешная песня и для этикета надо ржать. что они и делали. певец негодовал. на самом деле это была какая-то грустная драматическая песня, полная скорби.
в конце он ополчился на ржущих и выдал тираду ругани в их адрес на немецком. "мне кажется немецкий язык специально предназначен для ругательств!"
Pzz>А много HTTP и много TLS — не редкость для определенного класса системных задач.
блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка.
тут и шарп и ява бы справились вполне
Pzz>>А много HTTP и много TLS — не редкость для определенного класса системных задач. U>блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка. U>тут и шарп и ява бы справились вполне
Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
вопрос конечно холивора и закостенелости. но повод ли для этого изучать что-то, если инструмент прекрасно справляется с задачей?
п.с. всегда бесили вот названия и картинки типа dbeaver. бобер. сразу ларри вспоминаются с пасхалками. а конкретно в русификации надо было написать "подоить бобра" = "подрочить" ) короче по возможности только хардкор — mssms и pgadmin для постгря...
Ф>>Тут речь не только про HTTP — про любой IO. Если тебе надо делать множество чтений или записей (откуда угодно и куда угодно) с небольшой обработкой прочитанного, то гошка будет хорошим выбором.
U>вопрос конечно холивора и закостенелости. но повод ли для этого изучать что-то, если инструмент прекрасно справляется с задачей?
Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания. Заметь, программист, который понимает как работают async/await — редкий зверь. Но это было бы половина беды: для IO-bound приложений тебе придётся что-то явно городить с размером стека — твои потоки сожрут всю доступную память под свои стеки и проблема встанет в полный рост.
Попытка уложить число потоков в кол-во ядер ОС на шарпе — задача в общем случае не решаемая, а значит твоя программа будет жрать System Time на переключение контекстов.
ЗЫ: гаечный ключ всё же нужен для закручивания, для забивания молоток лучше подходит
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания.
Как и в хаскеле. Все стандартное IO там асинхронное из коробки, и потоки там по умолчанию зеленые (прибитые к системным тоже есть). И нативный код создается со встроенным сборщиком мусором. Вообще, голанг местами очень и очень сильно смахивает на хаскель, кроме следующего пункта, очень важного:
"Заметь, программист, который понимает как работают async/awaitписать на хаскеле — редкий зверь."
Прощу прощения за почти дословное использование твоей фразы.
Здравствуйте, undo75, Вы писали:
Pzz>>А много HTTP и много TLS — не редкость для определенного класса системных задач. U>блин. хттп и тлс это все же не уровень драйверов и высокопроизводительного графического движка. U>тут и шарп и ява бы справились вполне
Современные принтеры, сканеры разговаривают по HTTP/HTTPS.
Докеры всякие умеют грузить всякие запчасти по HTTP/HTTPS.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
DSP алгоритмы вообще пишутся на Си, особенно в области embedded
Ф>Если ты про шарп, то он с такими задачами справляется хуже: конкурентность в шарпе явная (я про async/await), а в гошке она из коробки — у тебя простой линейный стиль написания. Заметь, программист, который понимает как работают async/await — редкий зверь. Но это было бы половина беды: для IO-bound приложений тебе придётся что-то явно городить с размером стека — твои потоки сожрут всю доступную память под свои стеки и проблема встанет в полный рост. Ф>Попытка уложить число потоков в кол-во ядер ОС на шарпе — задача в общем случае не решаемая, а значит твоя программа будет жрать System Time на переключение контекстов.
а можно пример задач таких? фантазии что-то не хватает
R>Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой. Табличное решение с интерполяцией. Я сразу же взялся за ассемблер, а вариант писать на C я даже не рассматривал. После того как реализовал и всё это успешно взетело, мне мой тогдашний руководитель предложил реализовать то же самое на Сях, благо это было не сложно. Когда же я сделал это и посмотрел в сгенерированный код, я прозрел. И навсегда потерял желание состязаться с компилером в оптимизациях. Компилер меня уделал и по памяти, и по производительности.
понятно, что сейчас на асме писать смысла нет. в каноны уже даже вошло "писать функцию извлечения квадратного корня" синоним "изобретать велосипед". а например алгоритм поиска кратчайшего пути — уже под вопросом что лучше будет в итоге
Здравствуйте, undo75, Вы писали:
U>а например алгоритм поиска кратчайшего пути — уже под вопросом что лучше будет в итоге
Ну, для меня это вообще не вопрос. В определенный период я написал такое количество версий поиска пути, что даже не смогу припомнить все варианты. Взвешенные, невзвешенные, с квадратной волной, с круглой волной, с одним источником, с двумя и с множеством, с различным числом и схемами распространения волны, с Бразенхамом, без него, с собственными примочками сглаживания... И всё это ещё и в различных комбинациях. При этом я постоянно мониторил сгенерированный код. В те поры я вообще был зациклен на производительности. Времена были такие. Визуализация FPS в реалтайме была неотъемлемым атрибутом разработки. Могу сказать с полной уверенностью, что, если бы я писал это на асме, то просто угробил бы кучу времени, но результат лучше не был бы. А вот хуже — легко.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, undo75, Вы писали:
M>>Они замечательно пишутся и на плюсах, и получается гораздо лучше. Ну, если, конечно, под железку есть плюсовый компилятор
U>всегда думал что под ембеддед на асме пишут. нафиг на высокоуровневом языке. даже с?
Нафиг писать годами на асме то, что можно написать за недели на плюсах, и ещё и спортировать или даже просто взять код с больших систем?
U>а можно пример задач таких? фантазии что-то не хватает
Например бэкап — оч. характерный пример IO-bound задачи с высокой степенью параллелилизма. Когда-то я таким занимался.
Ещё примеры:
Поиск по дискам — просто множество IO-операций.
Инсталляция, апдейт, например — пакетные менеджеры очень много контрольных сумм считают, вычисления минимальны.
Системы мониторинга, например — сбор метрик с множества источников, агрегация данных телеметрии, парсинг и индексация логов, поиск по логам
Работа с периферийными устройствами, например — обработка данных с датчиков
Облака, например — синхронизация данных между локальным диском и облачным хранилищем
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rg45, Вы писали:
R>Как сейчас помню, 98-й год, Visual Studio 5.0. Нам понадобилось реализовать вычисление квадратного корня для чисел с фиксированной точкой.
Фиксированную точку вроде через BCD реализуют (реализовывали). Это вроде бы наиболее корректный и производительный путь.
ЕМНИП, Си не умеет в BCD и никогда не умела. Даже некоторые битовые операции — только асм.
Я вообще не знаю ни одного языка общего назначения, который бы BCD знал и юзал. Неофиты даже не знают, что такое существует.
Поправь, если ошибаюсь.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Кстати, плюсовый userver в этом плане как раз является ответом гошечке, фреймворк делался с оглядкой на него в том числе. По вакансиям видно, что в Яндексе используется и userver, и Go. Значит, ни у одного из них нет явного преимущества в этих задачах.
M>Нафиг писать годами на асме то, что можно написать за недели на плюсах, и ещё и спортировать или даже просто взять код с больших систем?
незачем. тем более скорее всего компилятор куда лучше преуспеет с оптимизацией.
вопрос в другом — нужна ли экзотика типа го ) имхо поболит и отвалится. а классика никуда не денется. чисто мое имхо.
Здравствуйте, Marty, Вы писали: M>Что за ерунда? Самый простой путь — берёшь uint32_t, и говоришь, что точка посередине, т.е. число с фикс точкой формата 16b.16b.
Да, ты прав — я тут посовещался с qwen'ом на эту тему. BCD действительно сильно медленее. Квэн говорит, что именно твой подход использовался в игровых движках.
Однако, похоже, всё определяют цели. Я всякие чаты вот таким вопросом мучал:
Действительно ли ручная реализация fixed-point арифметики может привести к потере точности. Приведи примеры, где ручная реализация fixed-point приведёт к потере точности, а использование BCD — нет.
здесь часть ответа
Когда лучше использовать BCD
Бухгалтерские программы
Кассовые аппараты
Системы учёта налогов
Встроенные терминалы
📌 BCD позволяет точно представлять такие числа, как `0.1`, `0.01`, `0.001` и т.д., без ошибок округления.
---
Когда выгоднее использовать Fixed-Point
Игровые движки (до FPU)
Графические системы
Аудио/видео кодирование
Микроконтроллеры
Быстрые математические библиотеки
📌 Fixed-point эффективен по скорости и памяти, но требует аккуратности при умножении и делении.
---
Как избежать потери точности в fixed-point?
Используйте большие типы (`int64_t`) для промежуточных вычислений
Добавляйте округление перед сдвигами:
int32_t result = (temp + (1 << 15)) >> 16; // +0.5 перед сдвигом
Избегайте деления, используйте предвычисленные значения
Храните деньги в целых копейках, а не в долях
---
Итог
Задача
Fixed-Point
BCD
Финансовые расчёты
⚠️ Может давать ошибки
✅ Точные
Графика/физика
✅ Отлично подходит
❌ Неэффективно
Вывод на экран
⚠️ Нужны преобразования
✅ Легко выводить
Вычисления
✅ Быстро, но с ошибками
✅ Точно, но медленно
📌 Fixed-Point — это компромисс между скоростью и точностью.
📌 BCD — это выбор, когда точность важнее производительности.
Fixed-point арифметика может привести к потере точности, особенно при работе с числами, которые не представимы точно в двоичном виде BCD обеспечивает абсолютную десятичную точность, но менее эффективен по памяти и скорости
Для финансовых систем: либо BCD, либо fixed-point, работающий только с копейками (целые числа)
Для высокопроизводительных вычислений: fixed-point или float/double/SIMD
Всё сказанное выше — личное мнение, если не указано обратное.
Не смейся — я впервые в эту тему полез. Про BCD знал из книжки Юрова "Ассемблер". Я по этой книжке асм учил, когда у меня ещё компа не было. Не надо было до этого момента.
Вот и посидел ночью с квеном пообщался. Разметку текста для цитаты, кстати, тоже он делал.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Marty, Вы писали:
Pzz>>Докеры всякие умеют грузить всякие запчасти по HTTP/HTTPS.
M>Эти дрова скорее всего в юзерспейсе пасутся, такая "системщина" ничем особым от обычных приложух не отличается
Мне не близка идея считать системным ПО, которое в именно вот в кернелспейсе.
А как быть с микроядрами? Там примерно всё в юзерспейсе.
Здравствуйте, Философ, Вы писали:
Ф>Я вообще не знаю ни одного языка общего назначения, который бы BCD знал и юзал. Неофиты даже не знают, что такое существует.
Ф>Например бэкап — оч. характерный пример IO-bound задачи с высокой степенью параллелилизма. Когда-то я таким занимался.
зачем в бэкапе параллелизм? наоборот же процесс тормозиться будет. ио-устройство ведь одно? или не одно? ну тогда да
Ф>Ещё примеры: Ф>Поиск по дискам — просто множество IO-операций. Ф>Инсталляция, апдейт, например — пакетные менеджеры очень много контрольных сумм считают, вычисления минимальны. Ф>Системы мониторинга, например — сбор метрик с множества источников, агрегация данных телеметрии, парсинг и индексация логов, поиск по логам Ф>Работа с периферийными устройствами, например — обработка данных с датчиков Ф>Облака, например — синхронизация данных между локальным диском и облачным хранилищем
ты считаешь высокоуровневый язык с этим лучше справится?
Здравствуйте, undo75, Вы писали:
U>зачем в бэкапе параллелизм? наоборот же процесс тормозиться будет. ио-устройство ведь одно? или не одно? ну тогда да
Это сильно зависит от диска (HDD/SSD), бэкап по сети, на один или несколько источников и т.д. и т.п. Он может быть инкрементальгый, например, или надо что-то заархивировать.
U>ты считаешь высокоуровневый язык с этим лучше справится?
Я слышал, что тот же Zabbix с С на Го переписывают.
).
