Языкам программирования с развитой семантикой очень сложно придумать простой и эффективный механизм ручного контроля алиасинга. Это пробовали делать в Fortran — консервативно, но пробовали. Это пробовали в языке C, это пробуют сейчас в C++ и в Rust.
А разве нельзя сказать, что в Rust проблема решена? Через проверку заимствования в обычном коде, и через проверки miri в ансейфе.
А разве С\С++ компилятор не умеет выкидывать инициализацию если видит, что дальше память переписывается другим значением, и на этом протяжении не читается?
Сдаётся мне, что все эти приседания с инициализацией переменных - наследие былых времён, когда оптимизация "dead store elimination" отсутствовала.
Окончательное вылизывание кода просто позволит выйти на уровень насыщения количества неустранимых ошибок, количество которых зависит от используемой технологии/языка. И то это если функционал не добавляется/убавляется, компилятор не меняется и код идеально изолирован по инвариантам от зависимостей .
Есть подозрение, что у Rust это насыщение происходит быстрее, так ещё и уровень количества неустранимых ошибок ниже чем в С/С++. Это конечно можно будет подтвердить только со временем, но по крайне мере нет доводов для противоположного утверждения.
Родители/супруги кормить будут. Мы же не спрашиваем кто врачей кормить будет пока они 7 лет учатся, или инженеров пока они 5 лет свои корочки получают.
Да и вы преувеличиваете, в посте тем месяца на 3 от силы. С ИИ-шкой как с репетитором пролетите это на одном дыхании. Особенно если опыт уже есть.
Всё с ним норм, явно же написано что unsupported operation - miri не может проверить системный вызов времени. Miri с выключенным isolation требует детерминизма в коде.
И я не совсем понимаю почему вы используете SystemTime::now(), а не Instant::now() для отсчёта временных интервалов. Но скорее всего последний поддерживается в Miri.
В старых терминалах не было юникода, эмождей/лигатур, столько цветов, rich-text, огромных scrollback, множества alt-screen и всё это должно рендериться через композитор(или самостоятельно) в 140+ герц на 4k.
И да в 90х и 2000х терминалы ещё как тупили, вы просто забыли.
Этот пример чуть больше проливает свет на причину происходящего, А то у неподготовленного читателя может появится мысль, что компиляторы тупые, или ещё более крамольная мысль - что Rust не блейзенгли =)
Да, борьба с накоплением ошибки происходит в основном за счёт этого куска:
let t = sum + y;
c = (t - sum) - y;
И если бы мы разрешили ассоциативность для float, то компилятор посмотрел бы и такой “бро, ща я оптимизирую твой код”:
c = (sum + y - sum) - y; // c = 0 <- компилятор выкидывает "с" и ломает нашу задумку.
И чтобы компиляторы не портили наш численно устойчивый код им запрещено его неявно оптимизировать.
Вот ещё более быстрый и более точный вариант и без unsafe из одноимённого блога.
#![allow(internal_features)]
#![feature(core_intrinsics)]
use std::intrinsics::fadd_algebraic;
fn sum_block(arr: &[f32]) -> f32 {
arr.iter().fold(0.0, |x, y| fadd_algebraic(x, *y))
}
pub fn sum_orlp(arr: &[f32]) -> f32 {
let mut chunks = arr.chunks_exact(256);
let mut sum = 0.0;
let mut c = 0.0;
for chunk in &mut chunks {
let y = sum_block(chunk) - c;
let t = sum + y;
c = (t - sum) - y;
sum = t;
}
sum + (sum_block(chunks.remainder()) - c)
}
Представьте, что вы — директор аэрокосмического агентства. У вас есть 5 миллионов строк Fortran-кода, который 40 лет считает аэродинамику крыла. Он проверен в десятках тысяч лётных часов, и в нём нет ни одной математической ошибки. Вам предлагают переписать это на Rust. За 3 года, командой из 50 человек, с бюджетом в 100 миллионов долларов. Вы согласитесь?
А чё, у нас на хабре много директоров аэрокосмических агенств захаживает?) Если смотреть с точки зрения исполнителя, то конечно лучше на Rust всё переписать за 5кк/месяц, чем "седеть" в пропёрженном НИИ и за 150к ковырять Fortran на поддержке.
А разве нельзя сказать, что в Rust проблема решена? Через проверку заимствования в обычном коде, и через проверки miri в ансейфе.
А разве С\С++ компилятор не умеет выкидывать инициализацию если видит, что дальше память переписывается другим значением, и на этом протяжении не читается?
Сдаётся мне, что все эти приседания с инициализацией переменных - наследие былых времён, когда оптимизация "dead store elimination" отсутствовала.
Окончательное вылизывание кода просто позволит выйти на уровень насыщения количества неустранимых ошибок, количество которых зависит от используемой технологии/языка. И то это если функционал не добавляется/убавляется, компилятор не меняется и код идеально изолирован по инвариантам от зависимостей .
Есть подозрение, что у Rust это насыщение происходит быстрее, так ещё и уровень количества неустранимых ошибок ниже чем в С/С++. Это конечно можно будет подтвердить только со временем, но по крайне мере нет доводов для противоположного утверждения.
"Лес рубят - щепки летят".
Помню как все посмеивались, когда пару лет назад, DARPA начала заниматься проектом TRACTOR (автоматический переписывальщик с С ни Rust).
На примере Bun будет интересно понаблюдать, насколько текущий уровень науки и техники уже позволяет это делать.
Родители/супруги кормить будут. Мы же не спрашиваем кто врачей кормить будет пока они 7 лет учатся, или инженеров пока они 5 лет свои корочки получают.
Да и вы преувеличиваете, в посте тем месяца на 3 от силы. С ИИ-шкой как с репетитором пролетите это на одном дыхании. Особенно если опыт уже есть.
Пока нельзя, но и zed-агент/ACP там не очень. Лучше использовать "дискретные" агенты в своём отдельном окне/терминале.
Всё с ним норм, явно же написано что
unsupported operation- miri не может проверить системный вызов времени. Miri с выключенным isolation требует детерминизма в коде.И я не совсем понимаю почему вы используете
SystemTime::now(), а неInstant::now()для отсчёта временных интервалов. Но скорее всего последний поддерживается в Miri.Notepad++ и Emeditor только для виндузятников же?
В старых терминалах не было юникода, эмождей/лигатур, столько цветов, rich-text, огромных scrollback, множества alt-screen и всё это должно рендериться через композитор(или самостоятельно) в 140+ герц на 4k.
И да в 90х и 2000х терминалы ещё как тупили, вы просто забыли.
Затем же зачем делают терминалы(kitti, alacritty, foot) с GPU рендерингом - ниже задержки и статтеры.
Экосистема? Чтобы редактировать код и писать промты?)
Не понимаю зачем для держателей старого железа обновлять ядро? Разве в этой среде не распространён девиз: "работает - не трогай" ?
del
Этот пример чуть больше проливает свет на причину происходящего, А то у неподготовленного читателя может появится мысль, что компиляторы тупые, или ещё более крамольная мысль - что Rust не блейзенгли =)
Да, борьба с накоплением ошибки происходит в основном за счёт этого куска:
И если бы мы разрешили ассоциативность для float, то компилятор посмотрел бы и такой “бро, ща я оптимизирую твой код”:
И чтобы компиляторы не портили наш численно устойчивый код им запрещено его неявно оптимизировать.
Вот ещё более быстрый и более точный вариант и без unsafe из одноимённого блога.
Я без претензий к Mozilla, я больше про саму новость (тема нераскрыта).
Наверное потому что оно мне ну нужно? обычно скриптов вокруг curl было достаточно.
Зачем? Будет ли он блэйзенгли фаст по сравнению с uBlock Origin?
А чё, у нас на хабре много директоров аэрокосмических агенств захаживает?) Если смотреть с точки зрения исполнителя, то конечно лучше на Rust всё переписать за 5кк/месяц, чем "седеть" в пропёрженном НИИ и за 150к ковырять Fortran на поддержке.