А в какой форме хранить погрешность? Либо в длинной арифметике, но тогда уж сразу нужно в ней считать, либо во флоатах, и тогда нам нужна будет погрешность на погрешность :)
Физики у погрешности пишут только первую цифру и порядок. Обычно цель - оценить порядок бедствия и понять, в каком месте теряется точность. Для этой цели вполне хорошо подходит пара float, где первый float это значение и второй это погрешность. Формулы для погрешности сложения/умножения/синусов/косинусов и сходны с теми, что получаются при вычислении производных, там ничего сложного нет. Из минусов только то, что арифметических операций будет больше.
Мне кажется, нет. Наоборот, здесь связь с аналогиями - внимание как консьерж на входе, ограниченное количество мест в баре, две руки у бармена (которые обе не могут делать что-то сложное), стресс как вышибала, убийства в отеле как забывание. Вначале сложно вникнуть, но как будто после всех усилий оно лучше отложилось в памяти.
Я попробовал как в статье декомпилировать, там куча файлов и некоторые на десятки тысяч строк. Для меня загадка как там можно ошибку найти без понимания, как такое пишется и как оно должно работать
Кстати такое тоже у меня было, но с ноутбуком asus, купленным в 2016 году. Причём это винда как-то хитро планировала включение ночью для обновлений. Я настройками винды это поправить не смог и перешёл на Linux (были и другие причины, это был один из факторов), больше ноутубок по ночам не просыпался.
Да. На самых первых андроидах байт-код вообще интерпретировался и скорость была ужасная. Да и потом, до ART был Dalvik и он тоже был медленным. И были жёсткие ограничения по памяти (порядка десятков мегабайт на всё приложение). И, к сожалению, рынок устройств у пользователей тоже на несколько лет отстаёт от новинок ОС/железа, поэтому разработчики извращались как могли, чтобы приложения хоть как-то работали сразу на всём. И вдобавок java в Андроиде на кучу лет застряла на 6-7 версии (они давно говорят, что поддерживают java 8, но если например подсунуть байт-код третьей скалы собранный под 1.8, то окажется что поддержка не такая уж и полная, работать оно не будет). И вот из тех дремучих времён идут всякие стереотипы и костыли.
Итератор - аллок на хипе, класс, который вполне мог бы быть обычной структурой - аллок на хипе, даже простые операции типа перемножения матриц это либо аллоки, либо кэшированные в виде полей класса инстансы
Нет, современная JVM хорошо справляется с короткоживущими объектами. Например, если временный объект не покидает функцию, его на хипе можно не создавать. И если даже надо, то у каждого потока есть свой собственный кусочек памяти, когда он быстро и легко может насоздавать временных объектов.
Я бы наоборот сказал, что в java начинаются проблемы, когда разработчики вспоминают всякие устаревшие мифы про производительность и извращаются без какой-либо необходимости. Примеры: сделать пул объектов. Ожидание - нет расходов на создание/удаление. Реальность - объекты постоянно занимают память, объекты раскиданы по памяти как попало, можно случайно использовать объекты два раза или забыть освободить объект в пуле и получить утечку в памяти. Вместо удобства java получается стрельба по ногам в стиле С++. Кэшированные в виде полей класса инстансы: отвратительное решение. Во-первых будут весёлые баги при многопоточности, во-вторых JVM не может производить оптимизации и вынуждена реально писать/читать в этот объект в куче, потому что он доступен всем потокам. Самый треш, когда в libgdx в промежуточном вычислении используется вектор из трёх чисел и не покидает функцию, JVM могла бы его вообще не создавать, если бы не горе-оптимизаторы.
Я написал физический движок на Scala с неизменяемыми объектами для векторов-кватернионов и прочего: https://github.com/Kright/ScalaGameMath/blob/master/pga3d/shared/src/main/scala/com/github/kright/pga3d/Pga3dMotor.scala Думал, потому перепишу классы на изменяемые. Но сначала померял производительность. Оказалось, что вообще не нужно, и производительность такая же. Буквально в паре мест поправил после профайлера. Новые объекты для векторов буквально при каждой арифметической операции "создаются" - по факту хоть бы хны, работает быстро. Вот демка с машинкой: https://www.youtube.com/watch?v=wqt0ylxBqnU Шаг физики для десятка тел, сотня пружин и прочих связей, интегрирование методом Рунге-Кутты четвёртого порядка (т.е., с вычислением сил в четырёх точках на шаг) занимает 60 микросекунд. Я могу хоть 10к шагов в секунду сделать и при этом код очень просто написан.
Я понимаю когда у людей есть необходимость типа недостаточной производительности и отдела тестирования Sony, но намного чаще, к сожалению, люди не понимают что делают и просто пишут кривой сложный код, который ни разу не быстрее, но намного хуже поддаётся рефакторингу и оптимизации.
У меня более новый dell, но он почему-то очень любит гудеть вентиляторами даже без нагрузки (и даже во время сна, из-за чего я сном на ноубуке не пользуюсь). Кажется, моя проблема тоже где-то рядом.
Прикольно, оказывается в х86 есть CMOVcc и SETcc, которые выполняются или нет в зависимости от сравнения, но не сбрасывают конвейер. Так что код вида cond ? a : b тоже так может.
Я почему-то раньше думал, что такое только в ARM есть.
К сожалению, почти все модели на английском/китайском работают заметно лучше, чем на русском (в зависимости от того, кто их учил).
Я был приятно удивлён, когда запустил 8B модельку от яндекса, в дооубчении которой 30% русского и токенайзер подогнанный под русский язык - не смотря на свой размер, она отвечала довольно складно. Но та модель маленькая, я бы от неё многого не ждал. (Яндекс вроде бы её в Алисе использует)
Это было в 2003 году. В современных языках, даже в мейнстримных и системы типов довольно продвинутые и ide поверх них работают на порядок лучше. Вместо динамического js сейчас вовсю используют ts, а Python обмазывают аннотациями (они там необязательные, и типизация в рантайме всё равно динамическая, но их активно добавляют и доделывают последние лет 10)
Кажется, на фоне расходов на сам системный вызов это мало. Тут мои знания очень поверхностные, но кажется что для обработки системного вызова надо ещё переключиться в контекст ядра, сохранить все регистры, переключить стек на ядерный, что-то сделать, а потом вернуть регистры обратно и переключиться обрано в юзерспейс. Ещё я знаю что есть TLB, но не знаю сбрасывают ли его внутри системного вызова или как-то обходятся без этого. Т.е. системный вызов сильно сложнее внутри, чем просто вызов функции.
Если при записи окажется открыто больше одного регистра, одинаковые данные попадут сразу во все. Еще хуже ситуация при чтении: ячейки из разных регистров начнут выставлять разные значения на одни и те же битовые шины. В результате возможна непредсказуемая перезапись — данные из одних ячеек могут затереть другие из-за технологического разброса параметров. Это приведет к повреждению информации в памяти, чего допускать нельзя.
А чем плохо, когда данные попадут сразу в несколько регистров? По-моему, это наоборот интересная возможность, например, можно одним махом занулить сразу несколько регистров. Разве так не делают? Из потенциальных проблем я вижу только то, что сигнал пойдёт в сразу несколько ячеек и будет нужен ток побольше.
В cps можно жонглировать и вести/приостанавливать сразу несколько потоков управления. Как с корутинами, но в языке без корутин. Ещё есть интересная идея, что contination можно несколько раз продолжить с одного и того же места. Тогда поток исполнения вместо линейного превращается в что-то типа дерева.
Были, но это не значит что они легко доставались. Вроде бы лошадь в день может есть порядка 10 кг сена и провести телегу на 25-50 км (+ оплата на еду и на жизнь кучеру. Лесоруб за день может заготовить порядка 1-3 кубометра дров. Железо, кстати, тоже очень интересно добывалось и обрабатывалось.
Меня в этом плане ещё развитие железных дорог в 19 веке очень впечатлило, когда я начал смотреть на цифры : во-первых, на рельсы понадилось огромное количество железа (в разы больше чем до железных дорог), во-вторых паровозы ели уголь/древесный уголь буквально тоннами за поездку, а в третьих несмотря на всю сложность задачи, это оказалось в разы быстрее и дешевле, чем более старые виды транспорта. Типа каретами путь из Москвы в Питер занимал несколько недель, а на поезде вроде получалось за сутки.
И до железных дорог задача перевозки была сильно сложнее и дороже.
Я подозревал, что когда-то давно соль ценилась, но что её настолько замороченно готовили/очищали и возили через пол-континента - не знал. И ещё легко сказать "мальчишка, который подбрасывал дрова в топку", но ещё кто-то эти дрова рубил и подвозил, и кажется, что расходовались они кубометрами.
Физики у погрешности пишут только первую цифру и порядок. Обычно цель - оценить порядок бедствия и понять, в каком месте теряется точность.
Для этой цели вполне хорошо подходит пара float, где первый float это значение и второй это погрешность.
Формулы для погрешности сложения/умножения/синусов/косинусов и сходны с теми, что получаются при вычислении производных, там ничего сложного нет.
Из минусов только то, что арифметических операций будет больше.
Мне кажется, нет.
Наоборот, здесь связь с аналогиями - внимание как консьерж на входе, ограниченное количество мест в баре, две руки у бармена (которые обе не могут делать что-то сложное), стресс как вышибала, убийства в отеле как забывание.
Вначале сложно вникнуть, но как будто после всех усилий оно лучше отложилось в памяти.
Кучу лет жду value classes (да и от vector api не откажусь), но складывается чувство что их если и добавят, то через очень много лет :(
Я попробовал как в статье декомпилировать, там куча файлов и некоторые на десятки тысяч строк. Для меня загадка как там можно ошибку найти без понимания, как такое пишется и как оно должно работать
Кстати такое тоже у меня было, но с ноутбуком asus, купленным в 2016 году. Причём это винда как-то хитро планировала включение ночью для обновлений. Я настройками винды это поправить не смог и перешёл на Linux (были и другие причины, это был один из факторов), больше ноутубок по ночам не просыпался.
Да. На самых первых андроидах байт-код вообще интерпретировался и скорость была ужасная. Да и потом, до ART был Dalvik и он тоже был медленным.
И были жёсткие ограничения по памяти (порядка десятков мегабайт на всё приложение).
И, к сожалению, рынок устройств у пользователей тоже на несколько лет отстаёт от новинок ОС/железа, поэтому разработчики извращались как могли, чтобы приложения хоть как-то работали сразу на всём.
И вдобавок java в Андроиде на кучу лет застряла на 6-7 версии (они давно говорят, что поддерживают java 8, но если например подсунуть байт-код третьей скалы собранный под 1.8, то окажется что поддержка не такая уж и полная, работать оно не будет).
И вот из тех дремучих времён идут всякие стереотипы и костыли.
Да и с неработающей ассоциативностью несложно привести пример
1е20 + (-1е20) + 1.
Нет, современная JVM хорошо справляется с короткоживущими объектами. Например, если временный объект не покидает функцию, его на хипе можно не создавать. И если даже надо, то у каждого потока есть свой собственный кусочек памяти, когда он быстро и легко может насоздавать временных объектов.
Я бы наоборот сказал, что в java начинаются проблемы, когда разработчики вспоминают всякие устаревшие мифы про производительность и извращаются без какой-либо необходимости.
Примеры: сделать пул объектов. Ожидание - нет расходов на создание/удаление. Реальность - объекты постоянно занимают память, объекты раскиданы по памяти как попало, можно случайно использовать объекты два раза или забыть освободить объект в пуле и получить утечку в памяти. Вместо удобства java получается стрельба по ногам в стиле С++.
Кэшированные в виде полей класса инстансы: отвратительное решение. Во-первых будут весёлые баги при многопоточности, во-вторых JVM не может производить оптимизации и вынуждена реально писать/читать в этот объект в куче, потому что он доступен всем потокам. Самый треш, когда в libgdx в промежуточном вычислении используется вектор из трёх чисел и не покидает функцию, JVM могла бы его вообще не создавать, если бы не горе-оптимизаторы.
Я написал физический движок на Scala с неизменяемыми объектами для векторов-кватернионов и прочего: https://github.com/Kright/ScalaGameMath/blob/master/pga3d/shared/src/main/scala/com/github/kright/pga3d/Pga3dMotor.scala
Думал, потому перепишу классы на изменяемые. Но сначала померял производительность. Оказалось, что вообще не нужно, и производительность такая же. Буквально в паре мест поправил после профайлера. Новые объекты для векторов буквально при каждой арифметической операции "создаются" - по факту хоть бы хны, работает быстро.
Вот демка с машинкой: https://www.youtube.com/watch?v=wqt0ylxBqnU
Шаг физики для десятка тел, сотня пружин и прочих связей, интегрирование методом Рунге-Кутты четвёртого порядка (т.е., с вычислением сил в четырёх точках на шаг) занимает 60 микросекунд. Я могу хоть 10к шагов в секунду сделать и при этом код очень просто написан.
Я понимаю когда у людей есть необходимость типа недостаточной производительности и отдела тестирования Sony, но намного чаще, к сожалению, люди не понимают что делают и просто пишут кривой сложный код, который ни разу не быстрее, но намного хуже поддаётся рефакторингу и оптимизации.
У меня более новый dell, но он почему-то очень любит гудеть вентиляторами даже без нагрузки (и даже во время сна, из-за чего я сном на ноубуке не пользуюсь). Кажется, моя проблема тоже где-то рядом.
Прикольно, оказывается в х86 есть CMOVcc и SETcc, которые выполняются или нет в зависимости от сравнения, но не сбрасывают конвейер. Так что код вида cond ? a : b тоже так может.
Я почему-то раньше думал, что такое только в ARM есть.
К сожалению, почти все модели на английском/китайском работают заметно лучше, чем на русском (в зависимости от того, кто их учил).
Я был приятно удивлён, когда запустил 8B модельку от яндекса, в дооубчении которой 30% русского и токенайзер подогнанный под русский язык - не смотря на свой размер, она отвечала довольно складно. Но та модель маленькая, я бы от неё многого не ждал. (Яндекс вроде бы её в Алисе использует)
Да нет, erlang и модель акторов вполне реальные и иногда используются.
И каналы в го - по-сути каналы для сообщений.
Это было в 2003 году. В современных языках, даже в мейнстримных и системы типов довольно продвинутые и ide поверх них работают на порядок лучше.
Вместо динамического js сейчас вовсю используют ts, а Python обмазывают аннотациями (они там необязательные, и типизация в рантайме всё равно динамическая, но их активно добавляют и доделывают последние лет 10)
Кажется, на фоне расходов на сам системный вызов это мало. Тут мои знания очень поверхностные, но кажется что для обработки системного вызова надо ещё переключиться в контекст ядра, сохранить все регистры, переключить стек на ядерный, что-то сделать, а потом вернуть регистры обратно и переключиться обрано в юзерспейс. Ещё я знаю что есть TLB, но не знаю сбрасывают ли его внутри системного вызова или как-то обходятся без этого. Т.е. системный вызов сильно сложнее внутри, чем просто вызов функции.
А чем плохо, когда данные попадут сразу в несколько регистров? По-моему, это наоборот интересная возможность, например, можно одним махом занулить сразу несколько регистров. Разве так не делают? Из потенциальных проблем я вижу только то, что сигнал пойдёт в сразу несколько ячеек и будет нужен ток побольше.
В cps можно жонглировать и вести/приостанавливать сразу несколько потоков управления. Как с корутинами, но в языке без корутин.
Ещё есть интересная идея, что contination можно несколько раз продолжить с одного и того же места. Тогда поток исполнения вместо линейного превращается в что-то типа дерева.
Спасибо, не знал :)
Были, но это не значит что они легко доставались.
Вроде бы лошадь в день может есть порядка 10 кг сена и провести телегу на 25-50 км (+ оплата на еду и на жизнь кучеру. Лесоруб за день может заготовить порядка 1-3 кубометра дров. Железо, кстати, тоже очень интересно добывалось и обрабатывалось.
Меня в этом плане ещё развитие железных дорог в 19 веке очень впечатлило, когда я начал смотреть на цифры : во-первых, на рельсы понадилось огромное количество железа (в разы больше чем до железных дорог), во-вторых паровозы ели уголь/древесный уголь буквально тоннами за поездку, а в третьих несмотря на всю сложность задачи, это оказалось в разы быстрее и дешевле, чем более старые виды транспорта.
Типа каретами путь из Москвы в Питер занимал несколько недель, а на поезде вроде получалось за сутки.
И до железных дорог задача перевозки была сильно сложнее и дороже.
Я подозревал, что когда-то давно соль ценилась, но что её настолько замороченно готовили/очищали и возили через пол-континента - не знал.
И ещё легко сказать "мальчишка, который подбрасывал дрова в топку", но ещё кто-то эти дрова рубил и подвозил, и кажется, что расходовались они кубометрами.
Я вообще не понимаю, зачем администрация хабра (компании, зарегистрированной на Кипре) транслирует нам этот бред.