Здравствуйте, merge, Вы писали:
M>Смотрю иногда пишут "знание С++ и желание выучить Go и на нем писать в дальнейшем". M>Область плюсов сужается или идет замена в принципе и нет областей где плюсы выглядели бы незаменимы?
Кстати, плюсовый userver в этом плане как раз является ответом гошечке, фреймворк делался с оглядкой на него в том числе. По вакансиям видно, что в Яндексе используется и userver, и Go. Значит, ни у одного из них нет явного преимущества в этих задачах.
M>Нафиг писать годами на асме то, что можно написать за недели на плюсах, и ещё и спортировать или даже просто взять код с больших систем?
незачем. тем более скорее всего компилятор куда лучше преуспеет с оптимизацией.
вопрос в другом — нужна ли экзотика типа го ) имхо поболит и отвалится. а классика никуда не денется. чисто мое имхо.
Здравствуйте, Философ, Вы писали:
Ф>Фиксированную точку вроде через BCD реализуют (реализовывали). Это вроде бы наиболее корректный и производительный путь.
Что за ерунда? Самый простой путь — берёшь uint32_t, и говоришь, что точка посередине, т.е. число с фикс точкой формата 16b.16b.
Сложение/вычитание — просто складываешь/вычитаешь, ничего больше делать не нужно (ну, только следить за переполнением, но это тоже элементарно).
Умножение — расширяешь множители до uint64_t, умножаешь, результат сдвигаешь на 16 бит вправо, усекаешь до uint32_t — всё, готово.
Деление — аналогично умножению, только сдвигать надо влево (или не нужно, сейчас что-то лень думать).
Здравствуйте, 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
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
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 — целые числа произвольного размера.
Не смейся — я впервые в эту тему полез. Про BCD знал из книжки Юрова "Ассемблер". Я по этой книжке асм учил, когда у меня ещё компа не было. Не надо было до этого момента.
Вот и посидел ночью с квеном пообщался. Разметку текста для цитаты, кстати, тоже он делал.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Marty, Вы писали:
Pzz>>Докеры всякие умеют грузить всякие запчасти по HTTP/HTTPS.
M>Эти дрова скорее всего в юзерспейсе пасутся, такая "системщина" ничем особым от обычных приложух не отличается
Мне не близка идея считать системным ПО, которое в именно вот в кернелспейсе.
А как быть с микроядрами? Там примерно всё в юзерспейсе.
Здравствуйте, Философ, Вы писали:
Ф>Я вообще не знаю ни одного языка общего назначения, который бы BCD знал и юзал. Неофиты даже не знают, что такое существует.
Ф>Например бэкап — оч. характерный пример IO-bound задачи с высокой степенью параллелилизма. Когда-то я таким занимался.
зачем в бэкапе параллелизм? наоборот же процесс тормозиться будет. ио-устройство ведь одно? или не одно? ну тогда да
Ф>Ещё примеры: Ф>Поиск по дискам — просто множество IO-операций. Ф>Инсталляция, апдейт, например — пакетные менеджеры очень много контрольных сумм считают, вычисления минимальны. Ф>Системы мониторинга, например — сбор метрик с множества источников, агрегация данных телеметрии, парсинг и индексация логов, поиск по логам Ф>Работа с периферийными устройствами, например — обработка данных с датчиков Ф>Облака, например — синхронизация данных между локальным диском и облачным хранилищем
ты считаешь высокоуровневый язык с этим лучше справится?
Здравствуйте, undo75, Вы писали:
U>зачем в бэкапе параллелизм? наоборот же процесс тормозиться будет. ио-устройство ведь одно? или не одно? ну тогда да
Это сильно зависит от диска (HDD/SSD), бэкап по сети, на один или несколько источников и т.д. и т.п. Он может быть инкрементальгый, например, или надо что-то заархивировать.
U>ты считаешь высокоуровневый язык с этим лучше справится?
Я слышал, что тот же Zabbix с С на Го переписывают.
