В идеале в UI вообще не должно быть состояния, они должны быть прямым отображением некоторой модели данных, уметь ее изменять и уметь апдейтится при ее изменении.
А так да, как выше сказали, "разрыв" это классика асинхронщины, решается либо машиной состояний, либо корутиной/отдельным синхронным(возможно "зеленым") потоком.
Да смоделируйте простейший аттрактор Лоренца, https://en.wikipedia.org/wiki/Lorenz_system и изменить младший разряд, и увидите как траектории разлетятся. Вы тут не со мной спорите, а с целой отраслью науки исследующей "динамический хаос" и его проявления с 60-х. Простейший доступный пример это турбулентность и погода.
"small errors" означает, что сколь угодно маленькая ошибка, при экспоненциальном разбегании, проявит себя довольно быстро.
Дело не в точности, а в том что с какой точностью не считай, сколь угодно близкие результаты все равно будут разбегаться, экспоненциально. В широких массах это известно как "эффект бабочки". Расскажите про бессмысленность расчета тем, кто численно считает погоду.
"A more fundamental problem lies in the chaotic nature of the partial differential equations that govern the atmosphere. It is impossible to solve these equations exactly, and small errors grow with time (doubling about every five days). Present understanding is that this chaotic behavior limits accurate forecasts to about 14 days even with accurate input data and a flawless model."
Теория динамического хаоса началась с этого, что погрешность в младших разрядах приводила к совершенно разным прогнозам в простейших численных моделях погоды, которыми занимался Лоренц. Экспоненциальное разбегание сколь угодно близких траекторий, это широко известный постулат, для систем с динамическим хаосом, и турбулентности в частности. Так что да, в этих моделях даже одного флипа бита достаточно, чтобы получить абсолютно разные траектории результата.
Инструкции rsqrtss, для которой черным по белому написано approximate, и соответственно сколь угодное отклонение от стандарта? И которую не один компилятор даже со стандартной агрессивной оптимизацией(-O3) не использует, именно из-за проблем с детерминированностью?
К примеру, я знаю кучу софта для научных вычислений, которые выдают одинаковые результаты на amd и intel, в которых очевидно любое отклонение от детерминированности привело бы к существенным изменениям результата, те же расчеты турбулентности.
PS: а так да, согласен, какие-то инструкции, могут давать разный результат, только если нужна воспроизводимость нормальные люди их не используют.
Давайте вы мне покажете инструкции которые заявлены IEEE-754 complaint и которые дадут разные значения экспоненты и мантисы, и тогда мы продолжим разговор, что кто-то читал или нет. В данном случаи rsqrtss не является IEEE-754 complaint инструкцией, там даже в описании написано aproximate.Именно поэтому даже с агрессивной оптимизацией (-O3) компилятор ее не использовал, и пустился во все тяжкие лишь когда ему сказали "можешь ломать что хочешь" (-Ofast)
В общем случаи, не могут. Rsqrtss это совершенно отдельная инструкция, не прописанная ни в одном стандарте на плавучку. Которая дает аппроксимацию, а какой она будет это совершенно отдельный вопрос.
Центральная предельная теорема(ЦПТ), для достаточно большой суммы независимо распределенных случайных величин(с конечной дисперсией), со средним U и дисперсией D(sigma^2), результирующее распределение будет нормальным с со средним U*n, и дисперсией D*n. Биномиальное распределение можно представить как сумму бернулливских (выпадение 0 или 1 c вероятностью p и 1-p) и применив ЦПТ получить нормальное.
Вообще рассказывать про нормальное распределение и забыть про ЦПТ, как по мне довольно странно.
Так прошивка, ME модуля где хранится? В той же spi-флэшке, так же как и вся не тривиальная криптография которая на этом модуле выполняется. Раньше насколько я помню, проблема подмены была в том, что таблицы Хафмана для декодирования были прошиты прямо в железке ME.
Процессор ничего не считывает, он просто запускается и начинает выполнять инструкции по адресу 0xFFFFFFF0. Ровно эта область и отображается в "память" посредством трансляции SPI-флэшки(ROM), через чипсет(или сейчас уже есть этот блок прямо в CPU). После инициализации контроллера памяти, происходит "bios shadowing", то есть его копирование в RAM.
По поводу того, что написано в статье про какие-то различные отображения регионов фирмвари в память, по моему это ни так. То есть есть биос, как поставляемый бинарный файл, и биос как прошивка лежащий в SPI-флэшки это разные вещи. В последнем случаи "флэшка" просто отображается как линейный кусок соответствующего размера начиная от 0xFFFF FFFF, больше никакой трансляции там нет.
Кстати, синтезировать сверх-опасный вирус который выкосит человечество, кажется мне более реализуемой и опасной целью, но языковая модель, до этого не особо додумалась, пока что.
Если переписать нативно под e2k, улучшить скорее всего можно, вопрос насколько. Вообще нейросетки с минимум ветвлений, должны относительно хорошо ложиться на VLIW.
Один из плюсов VLIW и Эльбруса в том, что векторные интрисинки(SSE/AVX) достаточно напрямую транслируются в систему комманд, и их "реализация" поставляется с компилятором. В результате "векторный код" довольно не плохо компилируется по производительности.
Для чисто линейных многофакторных моделей, есть прекрасный scikit-learn, где есть регуляризация и различные cost function. Вообще если факторов относительно много то без регуляризации никуда, странно что вы об этом не написали.
К слову, это достаточно просто оценивается. Даже если медленное процессорное ядро и не самая оптимальная реализация, парсер json все равно линейный, с небольшой константой. Реалистично, даже в худшем случаи там будет 10 такт на байт входного текста, то есть для 50К, это максимум 0.5 M тактов. Даже если промахнуться на порядок, все равно ни о чем.
В идеале в UI вообще не должно быть состояния, они должны быть прямым отображением некоторой модели данных, уметь ее изменять и уметь апдейтится при ее изменении.
А так да, как выше сказали, "разрыв" это классика асинхронщины, решается либо машиной состояний, либо корутиной/отдельным синхронным(возможно "зеленым") потоком.
Изменил, и она практически ушла. Еще добавил к N, нолик чтобы стабилизировать разброс. То есть это типичный эффект от прогрева кэшей.
Да смоделируйте простейший аттрактор Лоренца, https://en.wikipedia.org/wiki/Lorenz_system и изменить младший разряд, и увидите как траектории разлетятся. Вы тут не со мной спорите, а с целой отраслью науки исследующей "динамический хаос" и его проявления с 60-х. Простейший доступный пример это турбулентность и погода.
"small errors" означает, что сколь угодно маленькая ошибка, при экспоненциальном разбегании, проявит себя довольно быстро.
Дело не в точности, а в том что с какой точностью не считай, сколь угодно близкие результаты все равно будут разбегаться, экспоненциально. В широких массах это известно как "эффект бабочки". Расскажите про бессмысленность расчета тем, кто численно считает погоду.
https://en.wikipedia.org/wiki/Numerical_weather_prediction
"A more fundamental problem lies in the chaotic nature of the partial differential equations that govern the atmosphere. It is impossible to solve these equations exactly, and small errors grow with time (doubling about every five days). Present understanding is that this chaotic behavior limits accurate forecasts to about 14 days even with accurate input data and a flawless model."
Теория динамического хаоса началась с этого, что погрешность в младших разрядах приводила к совершенно разным прогнозам в простейших численных моделях погоды, которыми занимался Лоренц. Экспоненциальное разбегание сколь угодно близких траекторий, это широко известный постулат, для систем с динамическим хаосом, и турбулентности в частности. Так что да, в этих моделях даже одного флипа бита достаточно, чтобы получить абсолютно разные траектории результата.
Так на чем основан данный эмпирический факт?
Инструкции rsqrtss, для которой черным по белому написано approximate, и соответственно сколь угодное отклонение от стандарта? И которую не один компилятор даже со стандартной агрессивной оптимизацией(-O3) не использует, именно из-за проблем с детерминированностью?
К примеру, я знаю кучу софта для научных вычислений, которые выдают одинаковые результаты на amd и intel, в которых очевидно любое отклонение от детерминированности привело бы к существенным изменениям результата, те же расчеты турбулентности.
PS: а так да, согласен, какие-то инструкции, могут давать разный результат, только если нужна воспроизводимость нормальные люди их не используют.
Потому что маленькие ошибки накапливаются, что приводит к расхождениям при длительных вычислениях, именно об этом и шла речь.
Давайте вы мне покажете инструкции которые заявлены IEEE-754 complaint и которые дадут разные значения экспоненты и мантисы, и тогда мы продолжим разговор, что кто-то читал или нет. В данном случаи rsqrtss не является IEEE-754 complaint инструкцией, там даже в описании написано aproximate.Именно поэтому даже с агрессивной оптимизацией (-O3) компилятор ее не использовал, и пустился во все тяжкие лишь когда ему сказали "можешь ломать что хочешь" (-Ofast)
Нет это совершенно не эмпирический факт, когда последний раз плавучка отклонялась от стандарта, меняли целый выпуск процессоров. https://en.wikipedia.org/wiki/Pentium_FDIV_bug
И плавучка прописана в стандартах как минимум https://en.wikipedia.org/wiki/IEEE_754
и здесь обсуждение вопроса с совместимостью https://stackoverflow.com/questions/2234468/do-any-real-world-cpus-not-use-ieee-754
Извините, но с чего бы ей выглядеть хуже? И когда LCG(https://en.wikipedia.org/wiki/Linear_congruential_generator) прямо таки стали "тяжелой операцией"(учитывая что в большинстве имплиментаций там и модуль по степени двойке)?
В общем случаи, не могут. Rsqrtss это совершенно отдельная инструкция, не прописанная ни в одном стандарте на плавучку. Которая дает аппроксимацию, а какой она будет это совершенно отдельный вопрос.
То есть почитав стэковерфлоу и написав основываясь на этом код, вы и его должны выложить под CC-BY-SA?
Центральная предельная теорема(ЦПТ), для достаточно большой суммы независимо распределенных случайных величин(с конечной дисперсией), со средним U и дисперсией D(sigma^2), результирующее распределение будет нормальным с со средним U*n, и дисперсией D*n. Биномиальное распределение можно представить как сумму бернулливских (выпадение 0 или 1 c вероятностью p и 1-p) и применив ЦПТ получить нормальное.
Вообще рассказывать про нормальное распределение и забыть про ЦПТ, как по мне довольно странно.
Так прошивка, ME модуля где хранится? В той же spi-флэшке, так же как и вся не тривиальная криптография которая на этом модуле выполняется. Раньше насколько я помню, проблема подмены была в том, что таблицы Хафмана для декодирования были прошиты прямо в железке ME.
Процессор ничего не считывает, он просто запускается и начинает выполнять инструкции по адресу 0xFFFFFFF0. Ровно эта область и отображается в "память" посредством трансляции SPI-флэшки(ROM), через чипсет(или сейчас уже есть этот блок прямо в CPU). После инициализации контроллера памяти, происходит "bios shadowing", то есть его копирование в RAM.
По поводу того, что написано в статье про какие-то различные отображения регионов фирмвари в память, по моему это ни так. То есть есть биос, как поставляемый бинарный файл, и биос как прошивка лежащий в SPI-флэшки это разные вещи. В последнем случаи "флэшка" просто отображается как линейный кусок соответствующего размера начиная от 0xFFFF FFFF, больше никакой трансляции там нет.
Кстати, синтезировать сверх-опасный вирус который выкосит человечество, кажется мне более реализуемой и опасной целью, но языковая модель, до этого не особо додумалась, пока что.
Если переписать нативно под e2k, улучшить скорее всего можно, вопрос насколько. Вообще нейросетки с минимум ветвлений, должны относительно хорошо ложиться на VLIW.
Один из плюсов VLIW и Эльбруса в том, что векторные интрисинки(SSE/AVX) достаточно напрямую транслируются в систему комманд, и их "реализация" поставляется с компилятором. В результате "векторный код" довольно не плохо компилируется по производительности.
Для чисто линейных многофакторных моделей, есть прекрасный scikit-learn, где есть регуляризация и различные cost function. Вообще если факторов относительно много то без регуляризации никуда, странно что вы об этом не написали.
К слову, это достаточно просто оценивается. Даже если медленное процессорное ядро и не самая оптимальная реализация, парсер json все равно линейный, с небольшой константой. Реалистично, даже в худшем случаи там будет 10 такт на байт входного текста, то есть для 50К, это максимум 0.5 M тактов. Даже если промахнуться на порядок, все равно ни о чем.