The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для Linux и Redox представлена реализация Libc на языке Rust, opennews (??), 09-Мрт-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


23. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/–
Сообщение от Аноним (-), 09-Мрт-18, 12:38 
Даже для динамических массивов? :) Ну, ребята, ну что же это такое. Почему не разбирающиеся в чем либо лезут комментировать?
Ответить | Правка | Наверх | Cообщить модератору

32. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/–
Сообщение от VladSh (?), 09-Мрт-18, 14:54 
То есть проверок для динамических массивов в рантайме лучше не делать?
Ответить | Правка | Наверх | Cообщить модератору

33. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от Аноним (-), 09-Мрт-18, 15:07 
Мы же про статический анализатор динамических массивов разве нет? :)
Ответить | Правка | Наверх | Cообщить модератору

35. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от pda (?), 09-Мрт-18, 15:08 
Иногда и для них. Rust предоставляет достаточно информации llvm, чтобы тот мог удалять проверку диапазона в некоторых случаях. Например (насколько я помню), когда вы делаете цикл по неизменяемому объекту (например неизменяемой ссылке) и только что получили длину массива, llvm может понять, что вы никогда не выйдите за границу диапазона и удалить проверку.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

53. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от angra (ok), 09-Мрт-18, 21:12 
А если я в цикле присвою счетчику другое значение? А если обращусь к a[i+1] на последней итерации?
Ответить | Правка | Наверх | Cообщить модератору

60. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от Аноним (-), 09-Мрт-18, 22:31 
Дада, это всё очень просто отлавливается компилятором.
Ответить | Правка | Наверх | Cообщить модератору

63. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от angra (ok), 10-Мрт-18, 00:53 
Разве что в самых простейших случаях, типа тела цикла из одного выражения. При наличии других переменных, ветвлений и вызовов функций всё становится совсем не простым для компилятора.
Ответить | Правка | Наверх | Cообщить модератору

65. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/–
Сообщение от Orduemail (ok), 10-Мрт-18, 01:58 
> А если я в цикле присвою счетчику другое значение?

    for mut i in 0..10 {
        println!("{}", i);
        i += 1;
    }
результат компиляции:
warning: value assigned to `i` is never read
--> tmp.rs:4:9
  |
4 |         i += 1;
  |         ^
  |
  = note: #[warn(unused_assignments)] on by default

Я поясню на всякий случай: изменение i на итерации цикла никак не влияет на то, с какими значениями i будет вызвано тело цикла.

> А если обращусь к a[i+1] на последней итерации?

И как это будет выглядеть? Может так?

for i in 0..a.len() {
    if i == a.len() - 1 {
        println!("{}", a[i+1]);
    }
}

Или как-то интереснее? В приведённом варианте, компилятор, раскрывая a[i+1], заинлайнит метод a.index(i+1), и таким образом вставит в код проверку i+1<a.len(), а дальше llvm, найдя эту проверку, заметит, что проверка не нужна, потому что если выполняется i==a.len()-1, то i+1<a.len() гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов.

Если мы просто будем обращаться к a[i+1], без всяких условий, то тут есть два варианта. Если цикл пойдёт по диапазону 0..a.len()-1, то проверка внутри цикла будет выкинута оптимизатором как ненужная. Если цикл пойдёт по большему диапазону, то проверка останется, потому что оптимизатор не сможет доказать, что она не нужная, и в этом случае мы собственно и получим панику на этапе выполнения.

А если компилятор для цикла 0..a.len() сможет вычислить точный размер a на этапе компиляции, то, я подозреваю, он сделает цикл по диапазону 0..a.len()-1, который не будет содержать проверок, а после цикла вызовет panic! (тот который должен был случится, в силу выхода индекса за границы массива). То есть там будет одна проверка на весь код, и эта проверка будет связана с организацией цикла. Если конечно компилятор не развернёт этот цикл, так чтобы он превратился бы в линейный код.

Все эти вещи компиляторы C тоже умеют делать не хуже чем компилятор rust'а, вы можете поизучать эти возможности оптимизаторов даже не связываясь с rust'ом, для этого достаточно освоить опции -S, -fverbose-asm, и ещё полезно подчастую -Os вставлять вместо -O2 -- так ассемблерный выхлоп получается понятнее человеку, правда это искажает результаты оптимизации. И я очень рекомендую поизучать их, потому что использование C без знания того, как компилятор генерит код -- это... я не знаю, как это назвать, но это совершенно неправильно. Так не выйдет писать хороший код на C, можно писать что-нибудь в стиле exim, но не хороший код.

Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

67. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от angra (ok), 10-Мрт-18, 04:43 
Ох уж эти титеретики
fn main() {
    let a: [i32;5]=[1,2,3,4,5];
    for i in 0..a.len() {
        if i == a.len() - 1 {
            println!("{}", a[i+1]);
        }
    }
}

Compiling playground v0.0.1 (file:///playground)
    Finished release [optimized] target(s) in 0.59 secs
     Running `target/release/playground`
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', /checkout/src/libcore/slice/mod.rs:830:10
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Ответить | Правка | Наверх | Cообщить модератору

72. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/–
Сообщение от Orduemail (ok), 10-Мрт-18, 12:09 
И? Вы хотите сказать, что проверка осталась и выполнялась на каждой итерации цикла? Что вызов panic! не был вынесен за пределы цикла? Или что вы хотите этим сказать?
Ответить | Правка | Наверх | Cообщить модератору

73. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/–
Сообщение от Orduemail (ok), 10-Мрт-18, 12:23 
    .type    _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
    ud2
.Lfunc_end0:
    .size    _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
    .cfi_endproc

Я даже не поленился и посмотрел. С -C opt-level=2 (в коде приведённом выше) цикл был выкинут вообще, и вся функция была оптимизирована к вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники был вынесен за пределы.

Ответить | Правка | Наверх | Cообщить модератору

80. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от Vkni (ok), 10-Мрт-18, 21:38 
> и вся функция была оптимизирована к
> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
> был вынесен за пределы.

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

Ответить | Правка | Наверх | Cообщить модератору

85. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/–
Сообщение от Orduemail (ok), 10-Мрт-18, 23:00 
>> и вся функция была оптимизирована к
>> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
>> был вынесен за пределы.
> С одной стороны это круто,

Сегодня это уже не круто, это нормальное поведение для любого уважающего себя компилятора. Собственно всё это даже не столько заслуга rust, сколько llvm. Я говорю: и clang, и gcc проворачивают то же самое с C'шным кодом. Если этот код переписать на C, добавив туда явную проверку на выход за границы массива и вызов функции panic, если это случается, то и clang, и gcc сгенерят практически такой же код, может быть даже ровно такой же байт в байт.

> с другой - компилятор явно недоделан,

Я бы сказал, что язык недоделан, а не компилятор. Но, может быть, это без разницы.

> с третьей, получается, можно статически анализировать не только исходный код, но
> и сгенерированный машинный код (это может дать доп. результаты, особенно с
> LTO).

Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?

Ответить | Правка | Наверх | Cообщить модератору

86. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от Vkni (ok), 11-Мрт-18, 02:24 
> Собственно всё это даже не столько заслуга rust, сколько llvm.

Ох.

> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?

После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция редуцируется до panic, как тут, что довольно неприятно.

Ответить | Правка | Наверх | Cообщить модератору

91. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от Orduemail (ok), 11-Мрт-18, 10:25 
>> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?
> После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция
> редуцируется до panic, как тут, что довольно неприятно.

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

Ответить | Правка | Наверх | Cообщить модератору

82. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от Аноним (-), 10-Мрт-18, 22:21 
>  .type _ZN3tmp4main17hd307395e913df02cE,@function
> _ZN3tmp4main17hd307395e913df02cE:

О да. Вот что они взяли из плюсов - так это вот это. А в сях таки в этих случаях нормальные названия функций вместо этого птичьего чирикания. Что сиииильно упрощает разборку с программой :). Как угодно но читать в инстурментах вот такое птичье чирикание - желания никакого.

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

101. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от Iaaa (ok), 12-Мрт-18, 13:13 
> Как угодно но читать в инстурментах вот такое птичье чирикание -
> желания никакого.

Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить имена?

Ответить | Правка | Наверх | Cообщить модератору

107. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/–
Сообщение от Аноним84701 (ok), 12-Мрт-18, 15:29 
>> Как угодно но читать в инстурментах вот такое птичье чирикание -
>> желания никакого.
> Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить
> имена?

c++filt вполне себе справляется;
(Код из #73)


% cat /tmp/tst
   .type    _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
    ud2
.Lfunc_end0:
    .size    _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
    .cfi_endproc


% c++filt < /tmp/tst
   .type    tmp::main::hd307395e913df02c,@function
tmp::main::hd307395e913df02c:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    core::panicking::panic_bounds_check::ha7f06c957d05f2e3@PLT
    ud2
.Lfunc_end0:
    .size    tmp::main::hd307395e913df02c, .Lfunc_end0-tmp::main::hd307395e913df02c
    .cfi_endproc

Ответить | Правка | Наверх | Cообщить модератору

108. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/–
Сообщение от Iaaa (ok), 12-Мрт-18, 16:37 
Не пользуюсь, но все равно - большое спасибо. Когда-нибудь точно пригодится.
Ответить | Правка | Наверх | Cообщить модератору

77. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/–
Сообщение от angra (ok), 10-Мрт-18, 18:10 
Я хочу сказать ровно одно, сказанное титеретиком не выдержало проверки практикой. Но так как ты страдаешь избирательной амнезией, то я процитирую, что именно ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов."
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

78. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/–
Сообщение от Orduemail (ok), 10-Мрт-18, 18:32 
> Но
> так как ты страдаешь избирательной амнезией, то я процитирую, что именно
> ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и
> вышвырнуть из кода println!, а затем и весь if тоже, а
> затем ещё и цикл, потому что это код не имеющий побочных
> эффектов."

А, ну да, я там ошибся -- я всё ж не компилятор. Но давай вернёмся тогда чуть назад: мы ведь говорим о лишних проверках в рантайме нет? Я тебе дал ассемблерный листинг, в нём нет ни одной проверки. Немного не по тем причинам как я ошибочно описал: условие цикла гарантированно выполняется на последней итерации и гарантированно не выполняется на предыдущих, компилятор может это доказать, что позволяет ему оторвать последнюю итерацию от цикла статически и реализовать её отдельно. При таком подходе ни одна проверка не нужна, и поэтому ни одной проверки в коде нету.

Ещё какие-нибудь возражения у "практика" есть?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру