LINUX.ORG.RU

Rust 1.24

 


3

9

Команда Rust рада сообщить о выпуске Rust 1.24.0. Rust — это системный язык программирования, нацеленный на безопасность, быстрое и параллельное исполнение программ.

Если у вас уже установлена предыдущая версия через rustup, для обновления просто выполните

$ rustup update stable

Для новой установки скачайте rustup и не забудьте прочитать примечания к выпуску 1.24.0 на GitHub.

Что нового в Rust 1.24.0?

rustfmt

Несколько лет мы ждали инструмент для автоматического приведения исходного кода на Rust в «стандартный вид». Встречайте предварительную версию rustfmt! Чтобы попробовать, просто выполните

$ rustup component add rustfmt-preview

Нужно отметить два важных момента: во-первых, вы должны использовать именно rustup component add, а не cargo install. Если вы ранее использовали rustfmt через cargo install, вам необходимо предварительно его удалить. Во-вторых, не забывайте о том, что rustfmt ещё не достиг версии 1.0. Некоторые детали пока в разработке, а баги в процессе исправления. Как только rustfmt достигнет версии 1.0, компонент rustfmt-preview будет объявлен устаревшим и заменён на rustfmt.

В ближайшее время мы планируем написать отдельный пост об этой стратегии выпусков. Для дополнительной информации смотрите страницу rustfmt на GitHub.

Пошаговая сборка

Ещё в сентябре 2016 года мы подробно писали об этом в нашем блоге. Идея пошаговой компиляции довольна проста: если поддерживается этот механизм, то пересобираться будет только тот код, который был изменён с момента предыдущей компиляции. Это намного быстрее, чем полностью собирать весь проект, даже если изменения исходного кода достаточно малы. Начиная с версии 1.24, пошаговая компиляция включена по умолчанию. Не забудьте о cargo check, если будете пытаться достигнуть минимально возможного времени сборки.

Важно отметить, что и работа над производительностью компилятора в целом, и над пошаговой сборкой в частности, будет продолжена. Кое-что доступно уже в этом выпуске 1.24.0 — значение codegen-units теперь 16 по умолчанию. Одно небольшое замечание об этом изменении: оно делает компиляцию быстрее, но исполняемый файл получается немного медленнее. Для максимальной скорости программы выставьте codegen-units в 1 в вашем Cargo.toml.

Другие изменения

Есть ещё одно изменение, о котором мы хотели бы поговорить: неопределённое поведение (undefined behavior). Как правило, Rust старается избегать неопределённого поведения, исключив его полностью из безопасного (safe) кода, и сведя к минимуму в небезопасном (unsafe) коде. Одним местом, где вы всё ещё могли получить неопределённое поведение, была ситуация, когда вызов panic! проходит через FFI.

extern "C" fn panic_in_ffi() {
        panic!("Test");
}

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

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

Стабилизация библиотек

Если вы любитель функции str::find, которая используется для нахождения char в &str, вы будете рады узнать, что она стала быстрее в 10 раз! Этого удалось достигнуть использованием memchr. [u8]::contains теперь также его использует, хотя прирост скорости оказался более умеренным.

Несколько новых API были стабилизированы в этом выпуске:

Следующие функции теперь могут быть использованы в постоянных выражениях (constant expressions), например при инициализации static:

  • new функции для Cell, RefCell и UnsafeCell
  • new функции для различных целочисленных Atomic типов
  • {integer}::min_value и max_value
  • size_of и align_of для mem
  • ptr::null и null_mut

Смотрите примечания к выпуску для более подробной информации.

>>> Подробности

★★★★★

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 1)

Ответ на: комментарий от tailgunner

Внезапно, он сравнивает одну функцию, которая работает со строкой, как с массивом слов, с другой функцией, которая работает со строкой, как с массивом слов...

блэкджека и шлюх в обеих реализациях не обнаружено, а размещение тестов в одном файле с реализацией - вопрос подхода к разработке.

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

The memchr crate is even faster because it links to glibc's memchr, which uses SIMD and other fancy stuff. libcore can't link to this so to get these wins we'll have to do a SIMD impl ourselves.

Нету никакой связи. Ноль. Прочитай еще раз что там в комментарии написано, а потом посмотри что в коммите сделано.

Их там нет? Ясно, понятно.

shkolnick-kun ★★★★★
()
Ответ на: комментарий от quantum-troll

Я бы не сказал, что webrender это совсем уж маленький и малоответственный участок.

Врунишка, хе-хе-хе. Обработка mp4-файлов на нем написана. Дело, конечно, нужное, немного порнухи на mp4 идет, но назвать webrender'ом это явное преувеличение.

Так ч0, servo взлетел? Детские болезни - вроде отъедания 16 Гб памяти и 1000 потоков на 2 сайтиках сумел перебороть? Вроде авторы решил забить на него и заняться каким-либо другим креативным творчеством.

Статистика на гитхабе с тобой не согласна.

Батюшки-святы, так когда мы будем иметь счастье лицезреть безопасный браузер, который всех порвет по производительности и надежности? Скоро(tm)?

anonymous
()
Ответ на: комментарий от shkolnick-kun

Внезапно, он сравнивает одну функцию, которая работает со строкой, как с массивом слов, с другой функцией, которая работает со строкой, как с массивом слов...

#ifdef WANT_WIDE
# define Wmemchr wmemchr
#else
# undef memchr
# define Wmemchr memchr
#endif

блэкджека и шлюх в обеих реализациях не обнаружено

Понт защитан.

а размещение тестов в одном файле с реализацией - вопрос подхода к разработке.

Еще раз, медленно: сравнивались два текста, ссылки на которые были приведены. И это не те ссылки, которые привел ты.

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

Обработка mp4-файлов на нем написана.

Как там в криокамере?

Врунишка, хе-хе-хе.

% cd firefox-58.0
% tokei .
-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
 C                    3761      2567789      1864705       402801       300283
 C Header            14258      3034591      1830137       782412       422042
 C++                 11055      5812799      4449762       607227       755810
 C++ Header             92        41014        32622         4627         3765
 Rust                 3250      1095452       833476       163020        98956
 ...
-------------------------------------------------------------------------------
 Total              175813     26621237     19845969      3667286      3107982
-------------------------------------------------------------------------------

Почти лям кода для mp4 парсера?

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

Я бы не сказал, что webrender это совсем уж маленький и малоответственный участок.

Врунишка, хе-хе-хе. Обработка mp4-файлов на нем написана.

Для протокола - одно другому не противоречит. И, по твоему же определению, ты сам - врунишка, потому что на Rust написан CSS engine.

Дело, конечно, нужное, немного порнухи на mp4 идет, но назвать webrender'ом это явное преувеличение.

А никто и не называл парсер mp4 WebRender-ом - ты просто не понял, что тебе написали.

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

Давай я для тебя и прочих «компетентных людей» переведу на русский:

«Крейт memchr еще быстрее [этой реализации], потому что он линкуется с memchr из glibc, которая использует SIMD [и написана на ассемблере]. libcore не может линковаться с библиотеками на C, поэтому для того чтобы получить такой же прирост [как у крейта memchr который использует glibc], нам придется написать SIMD реализацию самим [что мы делать не будем].»

Эта функция memchr из коммита была в libstd с декабря 2015 года А все что произошло сейчас это ее вырезали из libstd и поместили libcore что позволило воспользоваться ей в str::find и прочих местах.

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

Для протокола - одно другому не противоречит. И, по твоему же определению, ты сам - врунишка, потому что на Rust написан CSS engine.

CSS-engine - web-renderer? Хренассе, и я врунишка. Ты вообще понимаешь, о чем речь? Тебя бы сульфазином подколоть.

А никто и не называл парсер mp4 WebRenderer-ом - ты просто не понял, что тебе написали.

Аха, css-engine - это web-renderer, вы там в своем доме скорби голосованием так решили?

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

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

И, по твоему же определению, ты сам - врунишка, потому что на Rust написан CSS engine.

CSS-engine - web-renderer?

Тебе трудно будет это понять, но ты попробуй: в Firefox на Rust написаны более одного компонента. Парсер mp4, CSS engine, WebRender - это всё разные компоненты.

Аха, css-engine - это web-renderer

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

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

Virtuos86 В сущности вот задача: ...

Запутанно и непонятно. Поскольку ты упомянул динамическую типизацию, я так понимаю, ты пробовал задачу решить с применением Any? Что не срослось?

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

Давай, ты не будешь судить о чьей-либо компетентности?

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

Я имел ввиду, что твой товарищ по ~~несчастью~~ партии мог видеть это обсуждение и неправильно понял автора коммита...

shkolnick-kun ★★★★★
()
Ответ на: комментарий от tailgunner

Я бы не сказал, что webrender это совсем уж маленький и малоответственный участок.

Аха, css-engine - это web-renderer

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

Что там про божью росу?

CSS-engine - web-renderer?

Тебе трудно будет это понять, но ты попробуй: в Firefox на Rust написаны более одного компонента. Парсер mp4, CSS engine, WebRender - это всё разные компоненты.

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

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

Я немного в курсе. Автор вопроса хочет написать на Расте библиотеку, совместимую с классами Delphi (надо полагать бинарно).

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

Как мило - ты еще и цитаты подтасовываешь.

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

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

Вот исходный комментарий: Rust 1.24 (комментарий)

В нем ссылки на: https://github.com/kraj/uClibc/blob/master/libc/string/memchr.c#L17

и на https://github.com/rust-lang/rust/pull/46735/files#diff-69c293cdc7f454b8c690a...

Это именно то, что я сравнивал.

Кстати, если уж разговор о тестах, не подскажет ли местная публика:

  • сколько тестов нужно, чтобы покрыть memchr из uClibc, написанной на беспомощном говне мамонта (с) ?
  • сколько тестов нужно чтобы покрыть memchr из https://github.com/rust-lang/rust/blob/master/src/libcore/slice/memchr.rs ?
  • чем в современном языке, транслятор которого отлавливает многие ошибки во время трансляции, обусловлена необходимость кратного увеличения количества тестов?
shkolnick-kun ★★★★★
()
Ответ на: комментарий от quantum-troll

Ну, у меня firefox-esr, так что я просто судил со своей колокольни.

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

anonymous
()
Ответ на: комментарий от shkolnick-kun

В нем ссылки на: https://github.com/kraj/uClibc/blob/master/libc/string/memchr.c#L17

33 строки, тривиальный алгоритм поиска символа, нет тестов.

и на https://github.com/rust-lang/rust/pull/46735/files#diff-69c293cdc7f454b8c690a...

776 строк, нетривиальный алгоритм, тесты.

Это именно то, что я сравнивал.

Я начинаю думать, что анонимус, который путает парсер mp4 и WebRender -это твой виртуал. Он тоже закончил подтасовкой цитат.

чем в современном языке, транслятор которого отлавливает многие ошибки во время трансляции, обусловлена необходимость кратного увеличения количества тестов?

Твой вопрос нерелевантен. Больший размер кода на Rust обусловлен нетривиальным алгоритмом, больший объем тестов - 1) тем, что тесты есть (в отличие от uclibc) 2) тестами, нужными для поддержки строк, которых в Си просто нет.

tailgunner ★★★★★
()
Ответ на: комментарий от shkolnick-kun

чем в современном языке, транслятор которого отлавливает многие ошибки во время трансляции, обусловлена необходимость кратного увеличения количества тестов?

Не стоит смешивать логические ошибки, которые отлавливаются юнит-тестами, и порчу памяти, которая отлавливается рассматриванием логов valgrind'а и т.п., и для которой юнит-тесты не напишешь. А десяток юнит-тестов никому кажется ещё не вредил.

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

Я начинаю думать, что анонимус, который путает парсер mp4 и WebRender -это твой виртуал. Он тоже закончил подтасовкой цитат.

Ах, Гуня, Гуня, как же ты опустился до вранья обыкновенного? Жить-то как дальше будешь? Коллеги твои отвернутся и руки тебе подавать не будут.

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

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

Ну, у меня firefox-esr, так что я просто судил со своей колокольни.

Лол.

По ссылкам у меня какую-то хрень показывает

Буквально первая и вторая ссылка в гугле:
https://wiki.mozilla.org/Quantum/Stylo
https://wiki.mozilla.org/Platform/GFX/Quantum_Render
Stylo уже здесь, WebRender будет следующим.

quantum-troll ★★★★★
()
Ответ на: комментарий от anonymous

И да - жаловаться третьей стороне, что тебя обижают - некрасиво.

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

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

Ну, у меня firefox-esr, так что я просто судил со своей колокольни.

Лол.

Как скажешь.

Буквально первая и вторая ссылка в гугле:

Я про твои ссылки спрашивал, что там, причем здесь гугль? Ты с Гуней не молочный брат?

Stylo уже здесь, WebRender будет следующим.

Вот как будет, так и поговорим(tm), а пока его нет.

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

Вот как будет, так и поговорим(tm), а пока его нет.

Пусть так. Stylo, однако, тоже нетривиальный кусок кода в браузере.

quantum-troll ★★★★★
()
Ответ на: комментарий от tailgunner

И да - жаловаться третьей стороне, что тебя обижают - некрасиво.

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

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

anonymous
()
Ответ на: комментарий от quantum-troll

Пусть так. Stylo, однако, тоже нетривиальный кусок кода в браузере.

Еще бы. Я понимаю задачу. В rust'е удобные функции для работы со строками?

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

Да у вас там какой то другой мир

 clang5 main.c -O3 -march=native && time ./a.out > /dev/null
./a.out > /dev/null  4,05s user 0,44s system 99% cpu 4,504 total
gcc5 main.c -O3 -march=native && time ./a.out > /dev/null 
./a.out > /dev/null  5,01s user 0,51s system 99% cpu 5,538 total
gcc6 main.c -O3 -march=native && time ./a.out > /dev/null 
./a.out > /dev/null  5,08s user 0,45s system 99% cpu 5,534 total
gcc7 main.c -O3 -march=native && time ./a.out > /dev/null 
./a.out > /dev/null  4,94s user 0,39s system 99% cpu 5,343 total

Однозначно, заговор! Ну или у кого-то просто древний шланг:

clang34 main.c -O3 -march=native && time ./a.out > /dev/null                        
./a.out > /dev/null  6,49s user 0,41s system 99% cpu 6,912 total

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

Запутанно и непонятно.

Могу более подробно объяснить, если Вы скажете в чём возникает вопрос?

Что не срослось?

Пихал в Arc<Trait> объекты и пытался из Arc<Trait> получить объект и дёрнуть его метод.

Вот как раз с Any не пробовал. Может Вы подскажите на простом примере как дёрнуть метод типажа в данной ситуации? А то в русском сообществе Rust в gitter продвинутые ребята вечно заняты, а менее продвинутые не осилили помочь =\

Затык на 220 строке. Код: https://github.com/sinitcin/poll_engine

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

Я начинаю думать, что анонимус, который путает парсер mp4 и WebRender -это твой виртуал. Он тоже закончил подтасовкой цитат.

Он тоже закончил подтасовкой цитат.

подтасовкой цитат.

тоже

Ну и где я закончил подтасовкой цитат?

shkolnick-kun ★★★★★
()
Ответ на: комментарий от pftBest

А что мешало распаковать строку из UTF-8 в UTF-32 и работать быстро?

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

Ну и где я закончил подтасовкой цитат?

Вот здесь:

shkolnick-kun> он сравнивает одну функцию, которая работает со строкой, как с массивом слов, с другой функцией, которая работает со строкой, как с массивом слов...

Хотя linuhs_user сравнивал не «одну функцию», а два фрагмента текста (или, если тебе угодно, одну функцию и фрагмент текста, содержащий функцию и тесты).

А что мешало распаковать строку из UTF-8 в UTF-32 и работать быстро?

Тем, что распаковка - это выделение памяти, а время на распаковку съест выигрыш на быстром поиске?

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

а время на распаковку съест выигрыш на быстром поиске?

А зачем постоянно паковать-распаковывать?

UTF-8 придумали для передачи по сети и хранения на диске же!

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

А зачем постоянно паковать-распаковывать?

Ты спросил про распаковку - я ответил. Если ты считаешь, что строки в памяти нужно хранить в UTF-32, так и говори.

UTF-8 придумали для передачи по сети и хранения на диске же!

А используют для хранения в программах. Жизнь дерьмо.

tailgunner ★★★★★
()

Вопрос растоманам

Я скомпилировал на чистом Си и на Расте простейшую программу выводящую на консоль надписть «Welcome to the Game!».

Посмотрел командой

ls -lh
на размер получавишихся бинарников. У Си он составляет 15 Килобайт, у Раста 3,3 Мегабайт.

Насколько я понимаю, тут статически компонуются всего лишь библиотеки ввода и вывода, но почему компилятор раста создаёт бинарник, который весит в 6 раз больше?

И тут я конкретно призадумался. А если на Раст писать аппаратный драйвер, где конечно же не будет стандартных функций ввода и вывода, во сколько раз при трансляции в машинный код бинарники драйверов «раста» могут быть тяжелее «бинарников Си»?

anonymous
()
Ответ на: комментарий от shkolnick-kun

Школьник-кун переходи на Rust! Таилгуннера уже обратили в нашу веру.

Redox OS нуждается в тебе!

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

добавили unordered_map, но api спроектировали так, что вменяемая реализация невозможна

Можно чуть подробнее, о чем речь?

std::unordered_map в C++ сообщает наружу о бакетах, что сразу убирает возможность реализации через открытую адресацию ради сомнительной возможности итерации по бакету. Операции вставки/удаления гарантируют сохранность итераторов в случае, если после вставки не происходит перехэширование, причём условие для перехэширования прописано в стандарте. Следовательно, реализация бакета в виде массива (возможно разреженного) не катит, только список или дерево. Дерево внутри бакета могло бы сократить время поиска в случае коллизий хэша, но интерфейс unordered_map позволяет задать функцию хэширования и операцию равенства, но не адекватную им операцию сравнения, так что запихать дерево поиска внутрь бакета не выйдет.

В итоге получаем поиск по ключу (основная операция для хэштаблицы!) O(n), притом насилующий кэши.

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

Запутанно и непонятно.

Могу более подробно объяснить, если Вы скажете в чём возникает вопрос?

Без примерного кода я вообще плохо себе представляю задачи.
Например, этот момент:

типажи имеющие type в себе не могут быть получены из конструкций аля Arc<Trait<Type = xxx>>


Вот как раз с Any не пробовал. Может Вы подскажите на простом примере как дёрнуть метод типажа в данной ситуации? А то в русском сообществе Rust в gitter продвинутые ребята вечно заняты, а менее продвинутые не осилили помочь =\

Да нет. Я стрелял наугад, прочитав про «динамическую типизацию». Кроме Any я никакой поддержки динамической типизации в Расте не знаю. И боюсь, что я из категории «менее продвинутых» ребят). Ну да сегодня вечер свободен, поломаю голову во имя великого добра.

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

типажи имеющие type в себе не могут быть получены из конструкций аля Arc<Trait<Type = xxx>>

Ну типа:


use std::sync::Arc;

trait MyTrait {
  
  type MyType;

  fn my_func() -> self::MyType;
}

type MyType = Arc<MyTrait<MyType = i32>>;


fn main() {
}

Ну да сегодня вечер свободен, поломаю голову во имя великого добра.

Было бы круто, ибо инфы про это практически нет =(

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

Когда? Сравнил две функции memchr, и сказал что код в расте сложный.

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

Это статическая типизация же, а мне бы с динамической пример. Например, фабрика которая может рождать объекты разного типа

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

Там же в сообщении об ошибке говорится: трейт-объект не может быть создан, так как метод my_func() не имеет ресивера. Чтобы метод мог быть включен в таблицу виртуальных функций, у него первым параметром должен быть &self или &mut self.

Наличие ассоциированных типов в трейте не имеет к этому отношения.

red75prim ★★★
()
Последнее исправление: red75prim (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.