Здравствуйте, Shtole, Вы писали:
S>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару). S>А вот в экономии энергии путём переписывания на Rust'е…
Сейчас вот вообще на JS переписывают, много ль в том смысла?
Здравствуйте, Shtole, Вы писали:
vsb>>Я считаю, что это пример экошизы. Из разряда дня земли.
S>Гораздо хуже.
S>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).
Проблема Часа Земли в том, что резкое понижение потребления легко может привести к авариям в энергосети. И уж точно приводит к незапланированным затратам (ну может уже и планируют под дурачков). В сети нельзя просто так выключить лампочку. Генератор крутится и энергия выделяется и она должна где-то рассеяться. Потихоньку генератор остановится, но это занимает время, для разных электростанций по-разному.
S>А вот в экономии энергии путём переписывания на Rust'е…
Экономия может и будет. Но она будет слишком мала, чтобы на что-то повлиять. Подавляющее большинство того, что может тормозить, уже давно написано на быстрых языках. А какой код будет ждать прихода очередного TCP-пакета, Rust или Python, процессору без разницы, он в любом случае спит.
Я вот только что написал программку, которая перекачивает гигабайты из одного S3-хранилища в другое. Написал на ноде. Потребление процессора у неё во время работы около 1% (думаю, меньше, просто так показывает). Ибо она тупо перекладывает байты из сокета в сокет, а остальное время ждёт, пока придут новые. Ну перепишу я её на расте. И что, будет она потреблять не 1%, а 0.1%. Какая разница, что там, что там копейки.
Ну и конечно никто в реальности не будет переписывать на расте то, что пишется на языках более высокого уровня, так же, как никто не будет слазить с автомобиля, если не ущемлять, а в программировании вроде ущемлять ещё не научились.
Здравствуйте, T4r4sB, Вы писали:
TB>Про скорость — да гонево, неотрубаемые проверки при индексации массива, при обращении к RefCell итд. Только на ансейфе Раст может вытащить. Ну либо это синтетический тест.
В идиоматичном коде компилятор обычно может убрать все или большинство проверок.
Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.
Здравствуйте, vsb, Вы писали:
vsb>Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.
Ты хочешь сказать, что предсказать ветвлений позволяет тратить 1 такт при виде инструкции перехода, если по ней ни разу не было перехода во вторую ветку? Я просто не очень в теме, потому и спрашиваю
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
vsb>>Ну и вообще проверки не такие уж и страшные, когда они никогда не срабатывают. Процессор просто их игнорирует и считает дальше. Если сработают — будет медленно. Пока не срабатывают — вообще пофиг, 1 такт это ничто.
TB>Ты хочешь сказать, что предсказать ветвлений позволяет тратить 1 такт при виде инструкции перехода, если по ней ни разу не было перехода во вторую ветку? Я просто не очень в теме, потому и спрашиваю
Я могу ошибаться, но моё понимание такое, что компилятор может "подсказать" процессору путь, по которому программа пойдёт с большей вероятностью. И ничего тут предсказывать не придётся. Если предсказание было неверное, то конвеер остановится, откатится и тд, но пока оно верное, всё будет быстро. тут немного написали, в gcc для этого есть макрос __builtin_expect
На самом деле современные процессоры содержат в себе всякие эвристики и скорей всего такие вещи даже без подсказок будут выполнять быстро. AMD там чуть-ли не простейшие нейросети засовывает.
Здравствуйте, vsb, Вы писали:
S>>В Часе Земли смысл есть — привлечь внимание. (Считать, что это способ экономии, всё равно, что считать Ice Bucket Challenge способом охладиться в жару).
vsb>Проблема Часа Земли в том, что резкое понижение потребления легко может привести к авариям в энергосети. И уж точно приводит к незапланированным затратам (ну может уже и планируют под дурачков). В сети нельзя просто так выключить лампочку. Генератор крутится и энергия выделяется и она должна где-то рассеяться. Потихоньку генератор остановится, но это занимает время, для разных электростанций по-разному.
Идея Часа Земли не в том, чтобы снизить ж-ж-ж в трансформаторе, а в том, чтобы повысить ж-ж-ж в Интернете. Хотя если подумать, и с Rust'ом, наверно, та же в точности фигня в данном случае
Здравствуйте, T4r4sB, Вы писали:
TB>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, T4r4sB, Вы писали:
TB>>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять
DE>Например?
borrow_mut
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>>>Реальная проблема Раста это неотрубаемые проверки, в том числе в местах, которые С++ и в голову не придёт проверять
DE>>Например?
TB>borrow_mut
RefCell? Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.
Здравствуйте, DarkEld3r, Вы писали:
DE>Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.
Зачем использовать unsafe? Тогда весь смысл rust-а теряется. Лучше уж родные проверенные плюсы ))
Здравствуйте, vsb, Вы писали:
vsb>Я считаю, что это пример экошизы. Из разряда дня земли.
Оплата электроэнергии — чуть ли не основная статья расходов дата-центров. И это не считая затрат на охлаждение. Поэтому это очень выгодно. А не бросаются всё переписывать видимо потому, что это чревато ошибками, что для дата-центра критично.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, DarkEld3r, Вы писали:
DE>RefCell? Если сильно надо, то можно использовать as_ptr — проверок не будет. Тут в теме ещё про массивы проскакивало — на всякий случай, для них есть get_unchecked.
А, то есть грязь с ансейфом.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, ArtDenis, Вы писали:
AD>Он тоже убирается оптимизатором в некоторых случаях, когда оптимизатор уверен, что флаг заимствования не задействован: AD>https://godbolt.org/z/bWs95sx7T
Полагаю, что эти случаи — примерно те, в которых и человек изначально не будет городить RefCell.
Речь идёт о более сложных примерах, когда без RefCell не обойтись
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, ArtDenis, Вы писали:
AD>Причём тут верификатор, если человек предлагает использовать unsafe? А рантайм-проверки в простых случаях и так убираются оптимизатором.
В непростых случаях верификатор позволит либо явно убрать рантайм-проверки, когда оптимизатор сам не справляется, либо написать unsafe, который однако же будет верифицированным и безопасным.
Здравствуйте, T4r4sB, Вы писали:
TB>Речь идёт о более сложных примерах, когда без RefCell не обойтись
Согласен. В сложных случаях RefCell добавляет несколько процессорных инструкций. Но всё равно не понятно почему тут обсуждается именно borrow_mut(), потому что его вызовы в реальных среднестатистических программах происходят на порядки реже, чем обращение к элементу массива по индексу, в особенности, если на расте пишут не в стиле раста ))
Здравствуйте, ArtDenis, Вы писали:
AD>Здравствуйте, T4r4sB, Вы писали:
TB>>Речь идёт о более сложных примерах, когда без RefCell не обойтись
AD>Согласен. В сложных случаях RefCell добавляет несколько процессорных инструкций. Но всё равно не понятно почему тут обсуждается именно borrow_mut(), потому что его вызовы в реальных среднестатистических программах происходят на порядки реже, чем обращение к элементу массива по индексу, в особенности, если на расте пишут не в стиле раста ))
У меня этот borrow_mut блин везде. Потому что Rc<RefCell<>> просто блин везде. Даже вот элементарно прокинуть хоть какой-то контекст в каллбак — всё, пихай Rc<RefCell> потому что любая попытка захватить нормальную ссылку приведёт к невозможности что-то ещё делать с объектом в другом коде.
А местами реально доходит до Rc<RefCell<Vec<Rc<RefCell<usize>>>>>
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>У меня этот borrow_mut блин везде. Потому что Rc<RefCell<>> просто блин везде. Даже вот элементарно прокинуть хоть какой-то контекст в каллбак — всё, пихай Rc<RefCell> потому что любая попытка захватить нормальную ссылку приведёт к невозможности что-то ещё делать с объектом в другом коде.
В этом как раз и состоит смысл рантайм проверок на наличие гонок в коде. Просто если он используется уж слишком часто, это возможно означает, что что-то пошло не так и надо ещё раз окинуть взглядом архитектуру
TB>А местами реально доходит до Rc<RefCell<Vec<Rc<RefCell<usize>>>>>
Я стараюсь по максимуму задействовать обычные ссылки, где это возможно. Но, да, согласен, Rc<RefCell<>> или Arc<Mutex<>> — "наше всё" ))
