The OpenNET Project / Index page

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



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

Оглавление

Линус Торвальдс не исключил возможность интеграции поддержки Rust в ядро Linux 5.20, opennews (ok), 22-Июн-22, (0) [смотреть все]

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


333. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +2 +/
Сообщение от burjui (ok), 24-Июн-22, 02:24 
Конечно. Инициализация - для слабаков. Настоящие мужики пишут такой код, который правильно работает даже со случайным мусором через нулевые указатели.
Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

364. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от Аноним (209), 24-Июн-22, 20:32 
Обязательная инициализация означает необходимость тратить время процессора и память на ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт, она неприемлема.
Ответить | Правка | Наверх | Cообщить модератору

374. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от warlock66613email (ok), 24-Июн-22, 23:10 
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных. Для системного программирования, где важен каждый такт,
> она неприемлема.

И поэтому в Rust есть переменные типа `MaybeUninit`. (Для которых, разумеется, также обязательна инициализация, но она не тратит время процессора и память (если использовать для инициализации значение `MaybeUninit::uninit()`.)

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

388. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от Аноним (278), 25-Июн-22, 10:24 
Какой ужасный синтаксис
Ответить | Правка | Наверх | Cообщить модератору

398. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от warlock66613email (ok), 25-Июн-22, 16:53 
> Какой ужасный синтаксис

Именно синтаксис здесь плюсовый. И что в нюм ужасного? Двойное двоетчие? А `MaybeUninit`, `uninit` — это не синтаксис, это просто идентификаторы, имя типа и тмя метода.

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

510. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (509), 29-Июн-22, 11:33 
В плюсовом? Да примерно всё, если взять не самый простой для парсинга синтаксис C (потому что контекстно-зависимый и не всегда однозначный), щедро обмазать абсолютно ортогональным синтаксисом темплейтов, а сверху ляпнуть новых фич C++11 и далее, с, как обычно, изобретённым заново синтаксисом для конструкций - вряд ли найдутся люди, которые осознанно и добровольно будут на нём писать и не плеваться.

"Синтаксис не важен!", скажут многие, окей, если синтаксис неважен, то почему его нельзя было сделать проще?

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

385. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +1 +/
Сообщение от n00by (ok), 25-Июн-22, 07:29 
> Обязательная инициализация означает необходимость тратить время процессора и память на
> ненужную оптимизацию переменных.

Если переменная в памяти, память "потрачена" независимо от инициализации.
Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения, т.е. в общем случае работать будет быстрее.

> Для системного программирования, где важен каждый такт,
> она неприемлема.

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

440. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 26-Июн-22, 12:49 
> Если переменная в памяти, память "потрачена" независимо от инициализации.

А вот это - совсем не факт. Оптимизатор может все пох@рить в ноль если видит что side effects от этого ровно ноль. И кода не будет вообще. И данных тоже. С железным аргументом "а если не видно разницы, зачем генерить больше?"

> Инициализация гарантирует, что переменная окажется в кеше к моменту последующего чтения,
> т.е. в общем случае работать будет быстрее.

С чего бы это вдруг такие гарантии вот так безаппеляционно?

>> Для системного программирования, где важен каждый такт, она неприемлема.

С другой стороны факапнуться с uninitialized variable в нем тоже так себе радость. Особенно когда все работает но раз в месяц почему-то палка все же стреляет.

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

457. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 26-Июн-22, 13:37 
>> Если переменная в памяти, память "потрачена" независимо от инициализации.
> А вот это - совсем не факт. Оптимизатор может все пох@рить в
> ноль если видит что side effects от этого ровно ноль. И
> кода не будет вообще. И данных тоже. С железным аргументом "а
> если не видно разницы, зачем генерить больше?"

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

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

Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет прочитана), а потом кеш скидывается в ОЗУ. А если нет записи, тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе придётся ждать.

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

520. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 01-Июл-22, 00:09 
> Так я описал худший случай, поскольку отвечал на: "Обязательная инициализация означает
> необходимость тратить время процессора и память на ненужную оптимизацию переменных".

Не уверен что это настолько уж масштабная проблема.

> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет
> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи,
> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе
> придётся ждать.

У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой. Более того - при генерации кода компилер вообще может целиком заинлайнить все. При том возможно что 90% нужного уже было в других регистрах.

А с каким-нибудь LTO зависимость вообще нелинейная. Иногда казалось бы более плохой код генерит более короткий и резвый код. В чем прикол? А вон там глобальному оптимизатору константы лучше легли. С ним вообще приходится эмпирически, на конкретном коде подбирать :). Но он круто лишнее выпиливает. Может треть кода аннулировать без какого либо изменения скорости или логики. И вот тут оно стоит того чтобы погреть проц при компиле, как минимум релизной версии.

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

527. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от n00by (ok), 01-Июл-22, 10:28 
>> Потому что запись (инициализация переменной) происходит сначала в кеш (откуда и будет
>> прочитана), а потом кеш скидывается в ОЗУ. А если нет записи,
>> тогда чтение произойдёт неизвестно когда. В лучшем случае сработает предвыборка, иначе
>> придётся ждать.
> У нормальных людей инициализация переменных не настолько частая чтобы это было проблемой.

Это всё субъективно. Вон то про кеш - оно не зависит от наших убеждений. То есть инициализация переменных оправдана, как оптимизация по скорости. :)

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

511. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (509), 29-Июн-22, 11:36 
Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори лика, в Виллабаджо уже завезли многопроцессорность.
Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

521. "Линус Торвальдс не исключил возможность интеграции поддержки..."  +/
Сообщение от Аноним (-), 01-Июл-22, 00:10 
> Пока в Вилларибе дрочат на такты и дебажат код в поисках мемори
> лика, в Виллабаджо уже завезли многопроцессорность.

Если ты так развлечешься в кернеле, вероятно, ты еще и не так потом будешь др@чить в дебаге внезапно падающего кернела.

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

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

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




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

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