The OpenNET Project / Index page

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



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

Оглавление

Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из состава ядра Linux, opennews (??), 16-Окт-23, (0) [смотреть все]

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


4. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  –1 +/
Сообщение от svsd_val (ok), 16-Окт-23, 11:38 
Используешь не С - перестань, с чего это такие глупые призывы. ХОТЯ ДА, нынче если Ваше ПО не жрёт фигову тучу ресурсов - это не гууд... нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицу что бы быть в тренде ... так получается ?
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

9. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  +7 +/
Сообщение от Аноним (9), 16-Окт-23, 11:51 
> нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицу

Нет чувак. Это даже не проблема языка программирования, а лично разраба.

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

85. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  –1 +/
Сообщение от svsd_val (ok), 16-Окт-23, 16:21 
Согласен, но ... только при одних и тех же обстоятельствах производительность и потребление ресурсов у разных языков разное. И как бы ты не старался для оптимизации работы некоторые вещи лучше писать на асме.... увы знаю о чём говорю... и Си и С++ в этом плане шибко проигрывают чистой асме.

Не говоря о том что многие разрабы в место того что бы реализовать маленькую фигню самим тащат монструозные зависимости которые ничего не делают, жрут ресурсы и весят балластом ) Так что да у многих прогеров нынче с этим беда...

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

124. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  –1 +/
Сообщение от Анонин (?), 16-Окт-23, 20:19 
> Си и С++ в этом плане шибко проигрывают чистой асме

Вот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше?
Предварительная оптимизация - это зло.
А пару маленьких кусков можно и на асме переписать потом, когда уже будут результаты работы профайлера.

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

150. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  +/
Сообщение от svsd_val (ok), 17-Окт-23, 18:37 
> Вот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше?

Да, всё зависит от конкретных задач и конкретного приложения, тупейший пример: рендеринг, расчёт физики и т.п. (там где много ветвлений и циклов) производительность будет падать в разы а не каких то 10/20%.
А теперь что касается реальных задач и конкретной темы в ядре падение скорости даже 2-3% уже сказывается на работу всего софта который был затронут зависимостями... там эти 2-3% могут как снежный ком расти... и в итоге ты будешь к примеру играть не 60fps а 45-48 потому что в коде оказался код который "тормозит" на 2-3%. вот это круто да.... понимаю всего 2-3% а не 10 и не 20%...

> Предварительная оптимизация - это зло.

Конечно, легче говно код написать и сказать что сейчас делать софт можно и нужно который и озу и проц жрут из расчёта что "У ВСЕХ ЕСТЬ ВОЗМОЖНОСТЬ КУПИТЬ НОВЫЙ КОМ" или новый сервер.... %)

> А пару маленьких кусков можно и на асме переписать потом, когда уже
> будут результаты работы профайлера.

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

p.s.
Можете кидаться какахами но увы... % на % и на % уже водном месте , в другом в и в третьем ... они же зачастую суммируются...

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

Увы но Я в корпоративной среде много такого кода видел из этого расчёта написанного ))), да можно работать но иногда просто офигиваешь от того что не шибко сложные вещи могут давать такие нагрузки....

мб просто я уже старый пердун, но в МОЁ ВРЕМЯ все старались писать оптимизированный код сразу а не после того как жаренный петух клюнет...

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

162. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  +/
Сообщение от Анонин (?), 18-Окт-23, 21:49 
> легче говно код написать

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

> я уже старый пердун, но в МОЁ ВРЕМЯ

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

> все старались писать оптимизированный код сразу

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


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

166. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."  +/
Сообщение от svsd_val (ok), 19-Окт-23, 16:40 
> прикольно ты в противовес супер-оптимизированному асму ставишь сразу говнокод))

Эм, похоже у кого-то с логикой не всё хорошо и делает выводы из своих же фактов ? Я утрировал и речь шла о том что предварительная оптимизация зачастую плюс, или ты собираешься пузырьковым методом сортировать массивы ?

> современные компиляторы прекрасно оптимизируют код, при этом нужно тратить время на те
> места, где компилятор не справился

Да, но даже они проигрывают в рациональности и пониманию целей и оптимизации человека.

> возможно в то время средний погромист был умнее компилятора
> но увы, те времена прошли, и слава богу))

Через чур уверенное заявление ...

> Похвально, вот только сколько времени ты будешь писать оптимизированный код на асме?

И так я буду писать на 10-30% дольше, в зависимости от задачи, так как есть понимание где и какой подход в каких обстоятельствах лучше использовать.

Далее, речь шла не только об асме (чего до него докопались то ?) но и о простых оптимизациях в коде, брутфорс наше всё и конечно он хорошо справляется, маленький легко понятный код ))).... На примере строки, как ты будешь производить поиск в огромном объёме ? На удивление простой перебор циклом не очень хорошая идея )))

> Пока ты будешь это делать, Вася на си уже напишет не такой
> оптимальный и он уже будет решать задачу.

Пока у Васи код будет выполняться 10 часов мой выполнится за 10 минут. Пока это разовое задача/действие - да подход Васи предпочтителен, но стоит запустить его больше раз... Хотя мб в этом и цель, что бы оправдания найти или выполнять одну и туже работу дважды ?

> Потому Васю попросят (или не попросят) ускорить свой код, а твой.. ну,
> останется у тебя.

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

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

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

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




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

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