Но это ведь не так работает. Чтобы опровергнуть теорию достаточно одного непредсказанного результата эксперимента. Правда с экспериментами в астрофизике сложновато.
Так никто не говорит, что это хорошая замена или даже адекватная. Но есть свершившийся факт - есть очень много инфы, которую найти можно только вручную на таких вот дискорд-серверах или каналах в телеге.
Я думаю речь была про то, что планировщик винды до сих пор не починили для гетерогенных процессоров, хотя что у амд, что у интел такие есть достаточно давно. Под линуксом хотя-бы с этим нет проблем, даже если ядро малость протухшее.
Во первых borrow checker не имеет отношения к проверкам границ. Во вторых borrow checkerу это и не нужно - он полагается на сигнатуры функций/структур, чтобы проверить все свои правила.
Я уточнил, что это не оптимизируют только компиляторы до 1.73, более свежие это видят. Но речь не про конкретный пример, а о том, что проверки не такие бесплатные и простые для удаления, как о них говорят.
struct Holder {
data: [u8; 1024]
}
impl Holder {
fn some_check(&self, u: u8) -> bool {
self.data.contains(&u)
}
fn index(&mut self) {
for i in 0..self.data.len() {
if self.some_check(self.data[i]) {
self.data[i] = 0;
}
}
}
fn iter(&mut self) {
for num in &mut self.data {
if self.some_check(*num) {
*num = 0;
}
}
}
}
Метод с итератором не может одновременно взять ссылку на self и оставить ссылку на массив в итераторе
По поводу третьего случая. К сожалению, всё это хорошо звучит только в теории. На практике паттерны доступа так легко не прослеживаются и в скомпилированный код попадает куча проверок, которые потом приходится ловить чтением бинаря.
Например, вот такой кусочек не оптимизировался до rust 1.73, причём проверки оставались для двух доступов
pub fn foo(a: &[i32], b: &[i32]) -> i32 {
let len = a.len().min(b.len());
let mut r = 0;
for i in 0..len {
r = r * a[i] + b[i];
}
r
}
Более свежий я не использовал, но уверен, что таких случаев там остаётся ещё масса.
P.S. Да, в этом случае можно было использовать итераторы, но там где я на это наткнулся - было нельзя.
Такое же происходило ещё задолго до 2010. Я там жил. Было лето, когда за все 3 месяца не было ни одного дождя и пекло непрерывное. Весь урожай тогда погиб
Я бы сказал за гранью. В рабочем чате я бы такое видеть точно не хотел
Но это ведь не так работает. Чтобы опровергнуть теорию достаточно одного непредсказанного результата эксперимента. Правда с экспериментами в астрофизике сложновато.
Тогда гугл начнёт целенаправленно саботировать работу по поддержке такого браузера если он получит хоть сколько-то заметную долю
Они людей за идиотов что ли держат? Налог в 20% и пошлина в 10% должны объяснить розничную цену в 1380$ по сегодняшнему курсу?
Так никто не говорит, что это хорошая замена или даже адекватная. Но есть свершившийся факт - есть очень много инфы, которую найти можно только вручную на таких вот дискорд-серверах или каналах в телеге.
Я думаю речь была про то, что планировщик винды до сих пор не починили для гетерогенных процессоров, хотя что у амд, что у интел такие есть достаточно давно. Под линуксом хотя-бы с этим нет проблем, даже если ядро малость протухшее.
И, судя по тестам, снизили этим же апдейтом производительности в синтетике/играх. Видимо cross-ccd задержки получались не просто из-за ошибки.
Слухи о "провальности" 9 серии сильно преувеличены
Которое, например, на windows не заработает. Или заработает с clang-cl, но так, что лучше бы не работало
Во первых borrow checker не имеет отношения к проверкам границ. Во вторых borrow checkerу это и не нужно - он полагается на сигнатуры функций/структур, чтобы проверить все свои правила.
Я уточнил, что это не оптимизируют только компиляторы до 1.73, более свежие это видят. Но речь не про конкретный пример, а о том, что проверки не такие бесплатные и простые для удаления, как о них говорят.
Метод с итератором не может одновременно взять ссылку на self и оставить ссылку на массив в итераторе
Всё ещё привязан, просто не так явно. И может заработать на других платформах, где соглашение о вызовах совпадает с таковым в линуксе.
Как посчитать эффективность сжирания электричества? Чем ниже кпд тем эффективнее т.к. выше отношение сожранного к полезной работе?
По поводу третьего случая. К сожалению, всё это хорошо звучит только в теории. На практике паттерны доступа так легко не прослеживаются и в скомпилированный код попадает куча проверок, которые потом приходится ловить чтением бинаря.
Например, вот такой кусочек не оптимизировался до rust 1.73, причём проверки оставались для двух доступов
Более свежий я не использовал, но уверен, что таких случаев там остаётся ещё масса.
P.S. Да, в этом случае можно было использовать итераторы, но там где я на это наткнулся - было нельзя.
Так блокировки и нет. Оно прекрасно работает, просто со скоростью 10bps. А называть вещи своими именами вообще может стать уголовно наказуемым
Такое же происходило ещё задолго до 2010. Я там жил. Было лето, когда за все 3 месяца не было ни одного дождя и пекло непрерывное. Весь урожай тогда погиб
Смотрел. Но я-то про реальный мир говорю
Всегда можно гвозди заменить на что-нибудь похуже. Всё-таки 21 век на дворе
В особо тяжёлом - уже без гвоздей
Ну, конкретно о моём существовании, майор, скорее всего, даже не подозревает