CERN именно в БД результаты и загоняет. Потому что обрабатывать их в реальном времени невозможно физически.
Это обработка результатов измерений, я про теоретические расчёты.
Для того и есть числа с фиксированной запятой, точность которых ограничена лишь объемом памяти.
При этом и сложность той же операции сложения двух чисел будет расти пропорционально. Возможно, в каких то ситуациях тратить гигабайты на одно число имеет смысл, но чаще есть компромисс между точностью и скоростью, так что в зависимости от ситуации может просто хватить float или double, можно запользовать float128, можно явно отслеживать ошибки округления в алгоритме (как при сложении Кэхена). Фиксированная точка тоже имеет право на жизнь, но про широкое использование в HPC не слышал.
Т.е. мир там описывался до изобретения интернета, компьютеры 70-х годов (и ранее)
Фантастика с современными компьютерами и интернетом - это по сути и есть киберпанк, который я упомянул.
если его посмотрит кто-то впервые, стильности уже не увидит. Только клоунскоть.
И молодую Анджелину Джоли )
хорошо приходится в год выхода, но быстро стареет
Логинов подобное называл "тусовочной литературой" - нацеленное на определённый круг лиц с общими интересами и цепляющее в основном отсылками к каким то "своим" реалиям.
фантастику как раз только начали активно писать и печатать
Если говорить о фантастике в целом - задолго до того были Стругацкие, Ефремов, Варшавский и многие другие. Вот киберпанк да, пришёл примерно тогда же, а тут ещё
с упоминанием современного времени, современного железа, отсылок к современным (тогда) программам и событиям
Вне контекста да, наверное сложно (и не факт что стоит) воспринимать.
Так по любому миллиарды чисел в оперативку не влезут.
Берём, скажем, такую машинку - https://www.alcf.anl.gov/aurora - 512 Gb обычной DRAM на узле плюс ещё сколько то HBM, вполне хватит для миллиардов чисел.
переходя от суммирования очень длинного вектора к совсем другим расчетам?
Понятно, что суммирование вектора - только одна из промежуточных подзадач в сложном расчёте (скажем, получить общую энергию на сетке после нескольких шагов для проверки, что считаем правильно).
Точные вычисления - это не про дифуры, где исходные данные хорошо, если шесть точных знаков имеют.
Так речь не об абсолютной точности, а чтобы не получить ошибку в разы, которую может дать сложение в лоб.
Тут вопрос как на мир смотреть, для меня большие объёмы действительных чисел - это в первую очередь HPC и сложные расчёты.
На таких объемах эти миллисекунды все рано роли не сыграют.
Смотря насколько часто эти вычисления проделываются и сколько раз, миллисекунды могут и в часы сложиться (хотя и просто пробежаться по нескольким сотням гигабайт - уже не миллисекунды).
BLAS - это просто библиотека. Как Вы в ней будете хранить
Мы вроде про стоимость вычислений говорим, а не про хранение.
512-битное число с фиксированной запятой, вполне умещающееся в регистр ZMM
То есть целый регистр (и соответствующее число операций) тратится на одно число вместо восьми даблов - причём явных операций для сложения 512-битных чисел нет, придётся ещё вручную с переносами разбираться.
А больше и не надо, так как это намного больше количества элементарных частиц в видимой части вселенной.
Если у нас исходно целые числа - да, если какой нибудь дифур считаем, разброс порядков никак не связан с числом чего бы то ни было.
В аналитике и моделировании (когда дело не касается реальных сумм на счетах) FP там всё таки уместен - скажем, классическая модель Блэка-Шоулза на float/double считается (хотя я сталкивался только с бенчмарками, а не реальным применением). А с выбором базы в целочисленных расчётах тоже надо действовать аккуратно, особенно если обрабатываются разные валюты, акции и т.д. - навскидку в официальных курсах ЦБ четыре знака после запятой.
Во первых, оно уже давно не развивается и с точки зрения поддержки стоит в лучшем случае на втором месте (после CUDA у NVIDIA, oneAPI/sycl у Интел, HIP у AMD) - сомневаюсь, что Микрософт решил откопать эту стюардессу. Во вторых, не уверен что оно в принципе поддерживается на NPU и может запользовать специфичные для AI блоки на GPU.
Описанные проблемы всплывут и с этими типами, особой разницы нет. Но вообще позиция автора близка к параноидальной
только в самых ограниченных ситуациях при вычислениях суммы мы знаем, что все входные числа являются конечными и что их сумма не может привести к переполнению.
На мой взгляд это скорее common case.
Если вы используете в качестве целевой платформы для своего языка LLVM, то избегайте флагов fast-math nnan и ninf
При расчёте параметров ядерного реактора или ракетного двигателя - однозначно. В игрушках и подобном софте можно и пожертвовать корректной обраткой nan/inf.
Это обработка результатов измерений, я про теоретические расчёты.
При этом и сложность той же операции сложения двух чисел будет расти пропорционально. Возможно, в каких то ситуациях тратить гигабайты на одно число имеет смысл, но чаще есть компромисс между точностью и скоростью, так что в зависимости от ситуации может просто хватить float или double, можно запользовать float128, можно явно отслеживать ошибки округления в алгоритме (как при сложении Кэхена). Фиксированная точка тоже имеет право на жизнь, но про широкое использование в HPC не слышал.
Фантастика с современными компьютерами и интернетом - это по сути и есть киберпанк, который я упомянул.
И молодую Анджелину Джоли )
Логинов подобное называл "тусовочной литературой" - нацеленное на определённый круг лиц с общими интересами и цепляющее в основном отсылками к каким то "своим" реалиям.
Амбер периодически перечитываю, вполне нормально воспринимается.
Если говорить о фантастике в целом - задолго до того были Стругацкие, Ефремов, Варшавский и многие другие. Вот киберпанк да, пришёл примерно тогда же, а тут ещё
Вне контекста да, наверное сложно (и не факт что стоит) воспринимать.
Для расчёта, скажем, термоядерной реакции?
Если добавили пять - то так и будет 2e8. Если моделируем динамику на миллиард лет - таки надо будет сложить единички )
Подозреваю, что имелось в виду "не cкладывайте" - но и с даблом накопленная погрешность может быть больше, чем устраивает.
Помню, в третьем классе с нас просили изложение по прочитанным летом книгам, писал подобный текст по "Острову сокровищ".
А так то в 90е Лукьяненко читали все знакомые фидошники...
Берём, скажем, такую машинку - https://www.alcf.anl.gov/aurora - 512 Gb обычной DRAM на узле плюс ещё сколько то HBM, вполне хватит для миллиардов чисел.
Понятно, что суммирование вектора - только одна из промежуточных подзадач в сложном расчёте (скажем, получить общую энергию на сетке после нескольких шагов для проверки, что считаем правильно).
Так речь не об абсолютной точности, а чтобы не получить ошибку в разы, которую может дать сложение в лоб.
Тут вопрос как на мир смотреть, для меня большие объёмы действительных чисел - это в первую очередь HPC и сложные расчёты.
Смотря насколько часто эти вычисления проделываются и сколько раз, миллисекунды могут и в часы сложиться (хотя и просто пробежаться по нескольким сотням гигабайт - уже не миллисекунды).
Это могут промежуточные результаты вычислений в памяти (тот же дифур на большой сетке).
Sorry, по основанию 2 считал )
Мы вроде про стоимость вычислений говорим, а не про хранение.
То есть целый регистр (и соответствующее число операций) тратится на одно число вместо восьми даблов - причём явных операций для сложения 512-битных чисел нет, придётся ещё вручную с переносами разбираться.
Если у нас исходно целые числа - да, если какой нибудь дифур считаем, разброс порядков никак не связан с числом чего бы то ни было.
А вот 1E30 - повлияют, а это не такой уж большой размер данных, на одну ноду влезет.
Странный референс, я бы скорее на BLAS (или его аналоги и оптимизированные реализации от вендоров железа) смотрел.
Спецификации процессоров с вами не согласны. И не очень понимаю, как за один такт обработать операцию с фиксированной запятой с сотнями порядков.
Одна единица на результат не влияет, если их много - см. текст статьи )
Что при этом с производительностью?
Если обрабатываемые числа отличаются на десятки порядков, никуда не денешься.
В аналитике и моделировании (когда дело не касается реальных сумм на счетах) FP там всё таки уместен - скажем, классическая модель Блэка-Шоулза на float/double считается (хотя я сталкивался только с бенчмарками, а не реальным применением). А с выбором базы в целочисленных расчётах тоже надо действовать аккуратно, особенно если обрабатываются разные валюты, акции и т.д. - навскидку в официальных курсах ЦБ четыре знака после запятой.
Отказ от -ffast-math - это ни разу не даром.
Подозреваю, что процент собирающих комп самостоятельно из комплектующих заметно меньше, чем в 90х.
Для тяжёлых приложений типа САПР с физическим моделированием хватает? Мне интересно, идёт ли Qualcomm в эту область (конкурируя с Intel Xeon W и т.п.)
Во первых, оно уже давно не развивается и с точки зрения поддержки стоит в лучшем случае на втором месте (после CUDA у NVIDIA, oneAPI/sycl у Интел, HIP у AMD) - сомневаюсь, что Микрософт решил откопать эту стюардессу. Во вторых, не уверен что оно в принципе поддерживается на NPU и может запользовать специфичные для AI блоки на GPU.
Описанные проблемы всплывут и с этими типами, особой разницы нет. Но вообще позиция автора близка к параноидальной
На мой взгляд это скорее common case.
При расчёте параметров ядерного реактора или ракетного двигателя - однозначно. В игрушках и подобном софте можно и пожертвовать корректной обраткой nan/inf.
Пока скорее раскладывают яйца по разным корзинам.