LINUX.ORG.RU

Rust 1.91.0

 ,


0

5

Представлена новая версия языка программирования Rust. Rust – язык программирования общего назначения, который освобождает программиста от ручного управления памятью благодаря механизму владения, без использования сборщика мусора.

Список изменений:

  • aarch64-pc-windows-msvc теперь является платфомой первого уровня поддержки (ранее было второго уровня). По сравнению со вторым уровнем поддержки, первый уровень подразумевает обязательное успешное прохождения всех тестовых наборов на платформе.

  • Добавлена проверка линтера при возвращении из функции «висячего» указателя. Встроенный в компилятор Borrow Checker уже имеет проверку на тот случай, когда возвращается «висячая» ссылка, но это не работало при использовании сырых указателей. Теперь будет сгенерировано предупреждение:

fn f() -> *const u8 {
    let x = 0;
    &x
}
warning: a dangling pointer will be produced because the local variable `x` will be dropped
 --> src/lib.rs:3:5
  |
1 | fn f() -> *const u8 {
  |           --------- return type of the function is `*const u8`
2 |     let x = 0;
  |         - `x` is part the function and will be dropped at the end of the function
3 |     &x
  |     ^^
  |
  = note: pointers do not have a lifetime; after returning, the `u8` will be deallocated
    at the end of the function because nothing is referencing it as far as the type system is
    concerned
  = note: `#[warn(dangling_pointers_from_locals)]` on by default

В разряд стабильного API было переведено:

  • Path::file_prefix
  • AtomicPtr::fetch_ptr_add
  • AtomicPtr::fetch_ptr_sub
  • AtomicPtr::fetch_byte_add
  • AtomicPtr::fetch_byte_sub
  • AtomicPtr::fetch_or
  • AtomicPtr::fetch_and
  • AtomicPtr::fetch_xor
  • {integer}::strict_add
  • {integer}::strict_sub
  • {integer}::strict_mul
  • {integer}::strict_div
  • {integer}::strict_div_euclid
  • {integer}::strict_rem
  • {integer}::strict_rem_euclid
  • {integer}::strict_neg
  • {integer}::strict_shl
  • {integer}::strict_shr
  • {integer}::strict_pow
  • i{N}::strict_add_unsigned
  • i{N}::strict_sub_unsigned
  • i{N}::strict_abs
  • u{N}::strict_add_signed
  • u{N}::strict_sub_signed
  • PanicHookInfo::payload_as_str
  • core::iter::chain
  • u{N}::checked_signed_diff
  • core::array::repeat
  • PathBuf::add_extension
  • PathBuf::with_added_extension
  • Duration::from_mins
  • Duration::from_hours
  • impl PartialEq<str> for PathBuf
  • impl PartialEq<String> for PathBuf
  • impl PartialEq<str> for Path
  • impl PartialEq<String> for Path
  • impl PartialEq<PathBuf> for String
  • impl PartialEq<Path> for String
  • impl PartialEq<PathBuf> for str
  • impl PartialEq<Path> for str
  • Ipv4Addr::from_octets
  • Ipv6Addr::from_octets
  • Ipv6Addr::from_segments
  • impl<T> Default for Pin<Box<T>> where Box<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Rc<T>> where Rc<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Arc<T>> where Arc<T>: Default, T: ?Sized
  • Cell::as_array_of_cells
  • u{N}::carrying_add
  • u{N}::borrowing_sub
  • u{N}::carrying_mul
  • u{N}::carrying_mul_add
  • BTreeMap::extract_if
  • BTreeSet::extract_if
  • impl Debug for windows::ffi::EncodeWide<'_>
  • str::ceil_char_boundary
  • str::floor_char_boundary
  • impl Sum for Saturating<u{N}>
  • impl Sum<&Self> for Saturating<u{N}>
  • impl Product for Saturating<u{N}>
  • impl Product<&Self> for Saturating<u{N}>

Признак const добавлен к следующим функциям:

  • <[T; N]>::each_ref
  • <[T; N]>::each_mut
  • OsString::new
  • PathBuf::new
  • TypeId::of
  • ptr::with_exposed_provenance
  • ptr::with_exposed_provenance_mut

>>> Подробнее

★★★

Проверено: hobbit ()
Последнее исправление: Wizard_ (всего исправлений: 2)
Ответ на: комментарий от mittorn

написал же, берёшь ссылку на объект, для редких специфичных случаев указатель

zurg
()
Ответ на: комментарий от tinykey

Думаю, под непрерывным объектом подразумевается всё же непрерыаный участок памяти

mittorn ★★★★★
()
Ответ на: комментарий от Darfin

и тесты с растовскими мьютексами стали рвать сишные на 10%-12%

?

use std::sync::Mutex;
use std::thread;
fn main() {
    let counter: Mutex<i32> = Mutex::new(0);
    thread::scope(|s| {
        for _ in 0..4 {
            s.spawn(|| {
                for _ in 0..1_000_000 {
                    *counter.lock().unwrap() += 1;
                }
            });
        }
    });
    println!("counter = {}", counter.into_inner().unwrap());
}
hyperfine -w 20 -r 50  ./rustmut ./cmut
Benchmark 1: ./rustmut
  Time (mean ± σ):     232.4 ms ±  22.5 ms    [User: 677.9 ms, System: 162.7 ms]
  Range (min … max):   153.7 ms … 269.6 ms    50 runs
 
Benchmark 2: ./cmut
  Time (mean ± σ):     138.0 ms ±   9.8 ms    [User: 208.6 ms, System: 269.3 ms]
  Range (min … max):   108.1 ms … 151.2 ms    50 runs
 
Summary
  ./cmut ran
    1.68 ± 0.20 times faster than ./rustmut

у меня стандартный мутекс и правда стабильно тяжелее, но больше озадачивает огроменный разброс (~100 мс) растового мутекса. Вот мутекс из parking_lot в обратном соотношении к pthread-у :

 use parking_lot::Mutex;
use std::thread;
fn main() {
    let counter: Mutex<i32> = Mutex::new(0);
    thread::scope(|s| {
        for _ in 0..4 {
            s.spawn(|| {
                for _ in 0..1_000_000 {
                    *counter.lock() += 1;
                }
            });
        }
    });
    println!("counter = {}", counter.into_inner());
}
hyperfine -w 20 -r 50  ./rustmut_pl ./cmut
Benchmark 1: ./rustmut_pl
  Time (mean ± σ):      78.6 ms ±   5.2 ms    [User: 147.0 ms, System: 124.2 ms]
  Range (min … max):    66.0 ms …  89.7 ms    50 runs
 
Benchmark 2: ./cmut
  Time (mean ± σ):     139.6 ms ±   7.9 ms    [User: 210.6 ms, System: 278.7 ms]
  Range (min … max):   114.3 ms … 150.3 ms    50 runs
 
Summary
  ./rustmut_pl ran
    1.78 ± 0.15 times faster than ./cmut
zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от zurg

Хм. Я не смог повторить сейчас своих прежних результатов. И сишные мьютексы и растовские работают примерно одинаково. Как так получилось в тот день, я не знаю.

Разрыв с parking_lot более чем в два раза выше в пользу parking_lot

Benchmark 1: rustmut_parking/target/release/rustmut_parking
  Time (mean ± σ):      78.7 ms ±   3.6 ms    [User: 175.4 ms, System: 93.4 ms]
  Range (min … max):    64.2 ms …  84.8 ms    50 runs

Benchmark 2: rustmut/target/release/rustmut
  Time (mean ± σ):     181.8 ms ±   5.0 ms    [User: 421.8 ms, System: 256.6 ms]
  Range (min … max):   167.2 ms … 189.4 ms    50 runs

Benchmark 3: ./cmut
  Time (mean ± σ):     187.0 ms ±   6.5 ms    [User: 421.6 ms, System: 275.4 ms]
  Range (min … max):   168.8 ms … 195.4 ms    50 runs

Summary
  rustmut_parking/target/release/rustmut_parking ran
    2.31 ± 0.12 times faster than rustmut/target/release/rustmut
    2.37 ± 0.14 times faster than ./cmut

gcc 13.3.0 rust 1.91.0

Darfin
()
Ответ на: комментарий от unC0Rr

Ну я открыл github tokio и сделал поиск по Arc<. Если нельзя реализовать не хелловорлдный проект без подсчёта ссылок, значит язык не функционален без подсчёта ссылок.

То что в примерах из документации длинной в 10 строчек можно обойтись без rc я не сомневаюсь.

ox55ff ★★★★★
()
Ответ на: комментарий от tinykey

Боров контрлирует что ты берешь ссылки где надо, он же никуда не девается

Если боров контролирует, то зачем в стандартной(!) либе языка есть RefCell, который множит борова на ноль. Зачем делать борова, а потом делать инструмент обхода борова? Может боров тогда совсем не нужен? Смекаешь?

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Если нельзя реализовать не хелловорлдный проект без подсчёта ссылок

Само собой, фреймворк для асинка не может обойтись без подсчёта ссылок, у него нет в компайл-тайме информации, когда какой поток закончится. То же самое можно сказать про практически любой проект с многопотоком.

Вопрос в другом: много ли Rc или Arc в сигнатурах функций? Потому что хранить объект в нём нормально, ненормально - таскать счётчики ссылок через всю программу. И я уверяю, типичные функции в расте либо принимают обычную ссылку, либо сам объект.

unC0Rr ★★★★★
()
Ответ на: комментарий от mittorn

Примитивные реализации предсказателя переходов дают 80+%. В little ядрах вполне нормальный предсказатель.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Если боров контролирует, то зачем в стандартной(!) либе языка есть RefCell, который множит борова на ноль. Зачем делать борова, а потом делать инструмент обхода борова? Может боров тогда совсем не нужен? Смекаешь?

Без борова грустно, с боровом тоже грустно, но меньше. С боровом и refcell может быть дозированно грустно в зависимости от потребностей.

tinykey
()
Ответ на: комментарий от ox55ff

Ну я открыл github tokio и сделал поиск по Arc<. Если нельзя реализовать не хелловорлдный проект без подсчёта ссылок, значит язык не функционален без подсчёта ссылок.

Любой проект где у объектов есть связи M:N будет обмазан счетчиками ссылок. Будет ли их делать GC, Arc или страдалец с ручным kref_get()/kref_put() – уже детали.

tinykey
()
Ответ на: комментарий от ox55ff

либе языка есть RefCell, который множит борова на ноль

нет не множит, ссылочные правила никуда не деваются только их проверка в рантайм уезжает, в расте боров обходится только сырыми указателями или ассемблерными вставками.

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от ox55ff

Например на cortex-a53 и cortex-a7 нет спекулятивного исполнения, хоть и какой-то базовый предиктинг есть. И шаредпоинтеры там будут забивать кэш и каналы памяти ненужным мусором

mittorn ★★★★★
()
Ответ на: комментарий от unC0Rr

То же самое можно сказать про практически любой проект с многопотоком

Это просто смешно. Rust начал пиарится под крики, что сложно написать многопоточный парсер css для firefox. Т.е. многопоточность должна быть родной средой раста.

А тут выясняется, что все его рекламные фичи только для однопоточных хелловорлдов, на которых даже сишка не сильно ломается. А как дело заходит за многопоток, то раст использует те же инструмениы, что и дедовский c++.

ox55ff ★★★★★
()
Ответ на: комментарий от tinykey

Любой проект где у объектов есть связи M:N будет обмазан счетчиками ссылок

Ну т.е. любой крупный проект

ox55ff ★★★★★
()
Ответ на: комментарий от zurg

только их проверка в рантайм уезжает

Это уже что-то вроде rw-lock и реализуется на дедовском c++ без пердолинга с боровом и ручными лайфтаймами.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Так оно все хоть на сишке реализуется, вопрос исключительно в том что боров не дает тебе облажаться и ссылку не взять, а значение использовать

tinykey
()
Ответ на: комментарий от ox55ff

нет не реализуется, растовский мутекс на плюсах не шмогли повторить, это не возможно, именно потому что нет борова.

без пердолинга с боровом и ручными лайфтаймами.

будет многократно более худший долгий и дорогой пердолинг с отладкой

zurg
()
Ответ на: комментарий от mittorn

Например на cortex-a53 и cortex-a7 нет спекулятивного исполнения

Предсказание переходов и спекулятивное исполнение это ортогональные понятия. Предсказатели есть даже на примитивных процессорах. Если в процессоре есть конвейер, то 99,99% будет и предсказатель.

Чтобы кэш не ломался его делают ассоциативным, а не прямым.

ox55ff ★★★★★
()
Ответ на: комментарий от unC0Rr

Механизм владения можно ввести в АПИ с помощью правильных типов умных указателей. Зачем программисту выкручивать руки и вводить это в язык?

Reset ★★★★★
()
Ответ на: комментарий от unC0Rr

А теперь покажи правильный код на Си и на расте. Без рейса

Reset ★★★★★
()
Ответ на: комментарий от iron

вот из-за таких с позволения сказать конструктов раст и является какахой:

let counter = Arc::new(Mutex::new(0)); let counter = Arc::clone(&counter); *counter.lock().unwrap() += 1;

Reset ★★★★★
()
Ответ на: комментарий от zurg

растовский мутекс на плюсах не шмогли повторить,

Потому на c++ что получается более удобный и без пердолинга вариант api? )

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

И где он? Почему его не показывают/не применяют, тот что в стандартной библиотеке детский сад штаны на лямках на фоне растового. Вот реально, какой-то хернёй мракобесной страдаете, но расклад сейчас такой - нужна корректная эффективная многопоточка на «системном уровне» и именно с минимальным пердолингом - берём раст, без вариантов.

zurg
()
Последнее исправление: zurg (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Я вот не профессионал вообще ни разу, но я пока не встречал программ на си, которые бы не текли и не встречал программ на раст, которые бы текли.

Я понимаю, что и то и другое теоретически возможно, но практика такая вот. А это уже интересно. По крайней мере для меня.

LightDiver ★★★★★
()
Ответ на: комментарий от Reset

Механизм владения можно ввести в АПИ с помощью правильных типов умных указателей. Зачем программисту выкручивать руки и вводить это в язык?

Чтобы не думать каждый раз «а правильно ли я сделал инварианты или опять все свалится в панику и придется разбирать coredump на 400 гигабайт».

tinykey
()
Ответ на: комментарий от ox55ff

Чтобы защитить их от датарейсинга, твой КО, реально защитить, с автоматической проверкой компилятором а не под честное хакирско-пионерское -«бл.. буду не буду дергать данные вне лока, чесслово прослежу, может даже коментарий не забуду про это написать»

zurg
()
Последнее исправление: zurg (всего исправлений: 2)
Ответ на: комментарий от ox55ff

RefCell может уронить программу в панику. Это другое?

Есть ли разница между RCE и падением приложения с трейсами? Есть.

tinykey
()
Ответ на: комментарий от mittorn

А я понял, родной GL же GLIBC’овый. Да и причём тут musl, если cargo вещь в себе и не тащит миллионы зависимостей снаружи.

Понятно, что внешние зависимости будут вызывать проблемы.

steemandlinux ★★★★★
()
Ответ на: комментарий от Reset

Почему у меня в панику ничего не валится?

Не знаю, у меня вот регулярно все валится. Ядро регулярно падает из-за багов в AMD, какой-то KDE’шный софт падает, GTK софт падает, на работе люди баги пишут. Вы с @Iron_Bug, похоже, единственные программысты, у которых все прекрасно и с первого раза получается. Остальные так не умеют, поэтому приходится обращаться к более продвинутым языкам.

tinykey
()
Ответ на: комментарий от Reset

Может руки надо выпрямлять? Ну и kde’шный софт ставить не надо. Я пишу без багов

А больше так никто не умеет, вы единственные. Хочешь медальку вам сделаем?

tinykey
()
Ответ на: комментарий от zurg

нет не множит, ссылочные правила никуда не деваются только их проверка в рантайм уезжает

И прощай производительность и здравствуйте множественные unwrap().unwrap().unwrap().use() -> crash

Какое только говно не придумают вместо того чтобы научиться программировать :)

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Reset

И прощай производительность и здравствуйте множественные unwrap().unwrap().unwrap().use() -> crash

А зачем так делать? Выше все правильно заметили, это просто RwLock.

tinykey
()
Ответ на: комментарий от tinykey

Когда то и у меня был АМД и падало. Я отказался от АМД, гнома и теперь даже кде если падает, то как то неуверенно и очень очень редко - раз в два года. А ядро последний раз падало лет 20 назад, когда у меня было АМД.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Когда то и у меня был АМД и падало. Я отказался от АМД, гнома и теперь даже кде если падает, то как то неуверенно и очень очень редко - раз в два года. А ядро последний раз падало лет 20 назад, когда у меня было АМД.

У меня был баг в amdgpu, кажется его уже починили. Но да, ядро падает регулярно, количество багов с памятью там просто конское.

tinykey
()
Ответ на: комментарий от steemandlinux

То есть, в процессе будет смесь двух libc? Даже в случае линковки хостового gl это не решает проблемы, т.к тогда вероятно прилинкуются версии символов от других хостовых библиотек, да и разные libgl несовсем совместимы между собрй (спасибо glvnd за несовместимое с mesa-gl ABI)

mittorn ★★★★★
()
Ответ на: комментарий от ox55ff

Если боров контролирует, то зачем в стандартной(!) либе языка есть RefCell, который множит борова на ноль.

Ну, внезапно, RefCell и Mutex в связке с Rc и Arc на голову выше по удобству, чем возня с ссылками. И если есть желание, можешь полностью ими обмазать все свое приложение. В итоге получится что-то типа пародии на свифт, где все построено на подсчете ссылок.

Можно пойти дальше и добавить механизм, который будет в рантайме маркировать объекты, чтобы вычислять циклы внутри ссылок. Это будет называться сборщик мусора. Говорят, есть несколько популярных языков с таким подходом.

Боров чеккер работает в компайл тайме, не имеет оверхеда в рантайме и все ошибки показывает при компиляции. RefCell делает проверки в рантайме и в случае каких-то ошибок владения, о них ты узнаешь тоже в рантайме, ну и плюс некоторый оверхед на проверки.

Darfin
()
Ответ на: комментарий от zurg

под честное хакирско-пионерско

Почему? В цпп есть инкапсуляция. Можешь спрятать данные вместе с мьютексом внутрь типа, а наружу выставить thread safe api. Для этого создавать новый язык не нужно.

ox55ff ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.