The OpenNET Project / Index page

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



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

"В ядро Linux 5.12 принята подсистема KFence для выявления ошибок при работе с памятью"  +/
Сообщение от opennews (?), 28-Фев-21, 10:41 
В состав находящегося в разработке ядра Linux 5.12 включена реализация механизма KFence (Kernel Electric Fence), который проверяет работу с памятью, отлавливая выход за границы буферов, обращения к памяти после освобождения и другие ошибки подобного класса...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=54671

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

Оглавление

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

2. Сообщение от A.Stahl (ok), 28-Фев-21, 10:43   +26 +/
Всё, Раст больше не нужен? (Ну, он и раньше был не нужен, но теперь за него вообще никаких аргументов не осталось)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #7, #10, #16, #80, #83, #92, #146

3. Сообщение от Аноним (-), 28-Фев-21, 10:46   –2 +/
Лучше бы добавили простую возможность узнавать-проверять валидные границы памяти в приложениях, существующие решения или набор непереносимых костылей или огромные библиотеки снижающие производительность
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #22

4. Сообщение от ИмяХ (?), 28-Фев-21, 10:46   +11 +/
Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #6, #62, #148, #171

5. Сообщение от Онаним (?), 28-Фев-21, 10:51   +2 +/
Такая возможность в C/C++ и много других языков уже давно добавлена.
if или assert, по вкусу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (6), 28-Фев-21, 10:57   +2 +/
Нужно ли? Чтобы добавить оверхед на пустом месте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #12, #43, #94

7. Сообщение от Аноним (7), 28-Фев-21, 10:59   –3 +/
Ты не так остёр, как думаешь.

Поздно пить смузи, когда продакшн упал. И удачи с исправлением в исходниках и слел6ующим деплоем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #54

8. Сообщение от Аноним (8), 28-Фев-21, 11:08   +2 +/
Что-то Debian стал много есть оперативки. Голая установка на uefi занимает 75 Мб оперативки. А ведь ещё пару лет назад 30 было. Ядро жиреет или что?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #15, #38, #96

9. Сообщение от Lex (??), 28-Фев-21, 11:17   +2 +/
Т.е памяти потребляться будет ещё больше ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

10. Сообщение от Леголасemail (ok), 28-Фев-21, 11:27   +8 +/
> Всё, Раст больше не нужен?

Fracta1L теперь не нужен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #13, #20, #67

11. Сообщение от Аноним (11), 28-Фев-21, 11:27   +/
Про systemdick не забывай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Аноним (12), 28-Фев-21, 11:31   +11 +/
А сабж - оверхед не на пустом месте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #17, #18, #19

13. Сообщение от A.Stahl (ok), 28-Фев-21, 11:38   +14 +/
(Ну, он и раньше был не нужен, но теперь за него вообще никаких аргументов не осталось)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

14. Сообщение от Аноним (14), 28-Фев-21, 11:48   +4 +/
Нет, физическая память под guard-страницы не выделяется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #132

15. Сообщение от Аноним (8), 28-Фев-21, 11:54   +/
Чего минусов налепили? Проверьте сами в виртуалке хотя бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #23, #176

16. Сообщение от anonymous (??), 28-Фев-21, 11:55   +/
Так вот кусочек за кусочком пытаются из Си сделать недо-Rust :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #21

17. Сообщение от Аноним (6), 28-Фев-21, 11:57   +1 +/
Сабж только для разработки и вполне отключается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #178

18. Сообщение от Anonimous (?), 28-Фев-21, 11:58   +/
Так сабж всегда можно отключить, если дебаг не нужен. При отклюбчении не будет и оверхеда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

19. Сообщение от Аноним (19), 28-Фев-21, 11:58   +3 +/
Сабж это культ-карго от легковерных туземцев, которые ужас как боятся дыреней.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #79, #170

20. Сообщение от Аноним (19), 28-Фев-21, 11:59   +/
Безопасных языков еще полно, можно за любой топить хоть за zig.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #46

21. Сообщение от alex312 (?), 28-Фев-21, 12:00   +2 +/
раст, в отличии от, делает проверки на этапе компиляции
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #32, #173

22. Сообщение от Аноним (19), 28-Фев-21, 12:02   –1 +/
Умные указатели уже миллион лет как придумали в с++. Это все равно что аналог safe в с++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #30

23. Сообщение от Аноним (19), 28-Фев-21, 12:03   –1 +/
Хорошая попытка, но нет.  Даже без гуя.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #25

24. Сообщение от Zenitur (ok), 28-Фев-21, 12:09   –4 +/
Самое то для старых компьютеров, на которых memtest бьёт тревогу, а QEMM постоянно показывает окно "ой, у вас тут содержимое памяти повредилось". Но при этом надо как-то выживать, потому что SIMM или DIMM SDRAM уже хрен купишь.

Или это не то?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #36, #85, #98, #201

25. Сообщение от Аноним (6), 28-Фев-21, 12:16   +/
Моё ядро занимает 80-100 (понятное дело без гуя вообще без всего). Но там все эти acpi с i2c и edac и всё прочее -- если их отключить, вроде даже можно что-то сэкономить, но тогда никакого контроля над железом просто не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #26

26. Сообщение от Аноним (8), 28-Фев-21, 12:17   –1 +/
Почему раньше всё работало и занимало 30 Мб?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #27, #28

27. Сообщение от Аноним (6), 28-Фев-21, 12:20   +3 +/
Из того что я знаю, добавили различные защиты и канареечные значения на случай атак, кроме того структуры ядра теперь рандомизируются в памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от Аноним (12), 28-Фев-21, 12:23   +1 +/
Если раньше все работало, то зачем ты что-то меняешь? Сиди себе на своем старье на пуле памяти в 30мб
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #40, #58

29. Сообщение от Нанобот (ok), 28-Фев-21, 12:24   –5 +/
Какие только костыли не придумают, лишь бы не изучать раст
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

30. Сообщение от Аноним (12), 28-Фев-21, 12:25   –2 +/
> Умные указатели уже миллион лет как придумали в с++

А когда запретят писать на "тупых" указателях?

> Это все равно что аналог safe в с++

Что ты подразумеваешь под safe?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34, #150

31. Сообщение от Аноним (31), 28-Фев-21, 12:28   –3 +/
Ядро стало помойкой.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

32. Сообщение от Аноним (32), 28-Фев-21, 12:46   +1 +/
переполнение буфера от присланного по сети кривого пакета раст тоже на этапе компиляции проверяет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #35, #44

33. Сообщение от Иван Лох (?), 28-Фев-21, 13:17   +4 +/
Нет. Это не то. То (возможномть передать ядру список битых блоков RAM) есть с первых версий linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

34. Сообщение от SR_team (ok), 28-Фев-21, 13:18   –1 +/
> А когда запретят писать на "тупых" указателях?

Не раньше, чем из раста полностью удалят unsafe, и любой код будет safe, т.е. никогда

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #56

35. Сообщение от Аноним (35), 28-Фев-21, 13:20   –1 +/
При обращении к буферу Rust автоматически сделает проверки на выход за границу. При выходе будет либо паника, либо вернется Option::None, зависит как обращаться. Если эти проверки гарантированно не нужны, их выкинет оптимизатор. Для чтения данных применяются методы, которые тоже проверяют границы переданного им буфера, и не выходят за границу. (Слайсы в Rust содержат не только голый указатель, но и длину).

Я не работал с голыми пакетами, но если объясните подробнее, как при кривом пакете происходит переполнение буфера, буду благодарен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #126, #127

36. Сообщение от n80 (?), 28-Фев-21, 13:33   +1 +/
Не то, это легковесный аналог address sanitizer, чисто пытается проверять выходы за границу массивов/объектов. Для твоих нужд badram давно в ядре есть, если сбоят конкретные участки. Но, вообще говоря, контакты чисть и проверь охлаждение.

И да, где это SIMM/DIMM хрен купишь? Залежи же.

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

37. Сообщение от Аноним (37), 28-Фев-21, 13:47   –1 +/
а вы видимо каждый раз глаза закрываете на ту кучу уязвимостей, связанных с переполнением буфера
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

38. Сообщение от timur.davletshin (ok), 28-Фев-21, 13:52   +2 +/
Отключи Huge pages и будет кушать НАМНОГО меньше. Другой вопрос, что ты будешь потом жаловаться на фрагментацию оперативной памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #97

39. Сообщение от Аноним (39), 28-Фев-21, 13:57   +1 +/
Fracta1L! Ты уволен!
Ответить | Правка | Наверх | Cообщить модератору

40. Сообщение от Аноним (8), 28-Фев-21, 14:03   +3 +/
Я хотел узнать причины, а не слушать едкие бессмысленные колкости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #48

41. Сообщение от Аноним (41), 28-Фев-21, 14:06   –1 +/
Компилятор, пусть даже раста, не может дать гарантий. Гарантии корректной работы с памятью может дать только ядро OS и процессор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

42. Сообщение от Аноним (41), 28-Фев-21, 14:10   –5 +/
Почему не интегрировали готовую защиту памяти от PaX из https://grsecurity.net ?

Потому что PaX имеет очень строгую защиту памяти, наличие которой у GNU/Linux многим не нравится!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #63

43. Сообщение от Owlet (?), 28-Фев-21, 14:14   –2 +/
У раста нет оверхеда по сравнению с си на эквивалентном коде. Все его фичи работают во время компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #45, #49, #81, #125, #149

44. Сообщение от Аноним (-), 28-Фев-21, 14:38   +/
> переполнение буфера от присланного по сети кривого пакета раст тоже на этапе
> компиляции проверяет?

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #53

45. Сообщение от Аноним (6), 28-Фев-21, 14:45   –2 +/
Это не так, мы уже выяснили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #50

46. Сообщение от Аноним (6), 28-Фев-21, 14:48   +/
> Безопасных языков еще полно, можно за любой топить хоть за zig.

Я топил за zig 8 лет назад, теперь я топлю за си, как за самый безопасный (в сравнении с теми же плюсами или даже джавой).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #141

47. Сообщение от Dzen Python (ok), 28-Фев-21, 14:50   –1 +/
А давно ли суды были с этой самой сесурити, забившей на лицензию?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #52

48. Сообщение от Аноним (12), 28-Фев-21, 14:52   –2 +/
Ну смотри

Ты не сидишь на своем старье, потому что тебя что-то не устраивало в нем, ты взял по-новее, решив свои проблемы, но расплатившись за это потреблением памяти, то есть решение проблем потребовало увеличения потребления памяти

Так яснее?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #57

49. Сообщение от Славик (?), 28-Фев-21, 14:53   –1 +/
Smart_pointer - это разве не оверхед? Каждое обращение к памяти со спинлоком!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #51, #95, #124, #131

50. Сообщение от Аноним (12), 28-Фев-21, 14:53   +2 +/
Сылки на треды, в которых проходило обсуждение
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #137, #142

51. Сообщение от Аноним (12), 28-Фев-21, 15:01   –8 +/
у тебя весь код состоит из смартпоинтеров?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

52. Сообщение от Аноним (52), 28-Фев-21, 15:04   –1 +/
Там длинная история: https://www.opennet.me/openforum/vsluhforumID3/119728.html#31

PaX патчи для защиты памяти отдельный проект, grsecurity его в себя интегрировал.

Патчи распространяются под GPL-2 и их можно включать в основное ядро.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #194

53. Сообщение от Сишник (?), 28-Фев-21, 15:10   –2 +/
Ну так и в сишке можно массив гарантированно обойти без промаха и проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #55, #72

54. Сообщение от Аноним (54), 28-Фев-21, 15:12   +/
что самое интересное, его плюсуют какие-то смузи-фанбои, что говорит о том, насколько интеллектуально развиты 95% местной аудитории
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #64, #68

55. Сообщение от Аноним (12), 28-Фев-21, 15:15   –2 +/
Кто-то говорил, что нельзя? А почему все не юзают? А говорит ли об этом компилятор? А почему мне язык не даст по рукам, если я использую небезопасную версию, если безопасная версия не имеет штрафа по перформансу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #70, #88

56. Сообщение от Аноним (12), 28-Фев-21, 15:18   +/
Ему про тупые указатели, он про раст и safe, сначала определи, что такое safe, можешь при этом не использовать слово "раст"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #138, #145, #175

57. Сообщение от Аноним (8), 28-Фев-21, 15:21   +/
При чём здесь мой выбор новой версии? Я спросил лишь причину жора оперативки. Меня не интересует обсуждение причин выбора новой версии. Неужели это непонятно? Но раз уж такой интерес, скажу. Старые версии не имеют поддержки и исправления безопасности к ним не приходят.
>решение проблем потребовало увеличения потребления памяти

Не потребовало. Проблемы как таковой нет. Раньше обновлялся и жора не было. Теперь есть. И я _просто_ хочу узнать причины.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #59, #111

58. Сообщение от Аноним (8), 28-Фев-21, 15:24   –1 +/
Специалист по ИБ из вас так себе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #61

59. Сообщение от Аноним (12), 28-Фев-21, 15:29   –1 +/
> Старые версии не имеют поддержки и исправления безопасности к ним не приходят
> Не потребовало. Проблемы как таковой нет.

Обновления безопасности - проблема? Если нет проблем, то почему тебя беспокоят обновления безопасности? С чего ты взял, что обновления безопасности не жрут память?

> Раньше обновлялся и жора не было.

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

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

> И я _просто_ хочу узнать причины.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #65

61. Сообщение от Аноним (12), 28-Фев-21, 15:33   +/
Ты тоже из тех, кто считает, что если в системе есть баги, то это называется "все работает"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #66, #112

62. Сообщение от Аноним (62), 28-Фев-21, 15:43   +/
>Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.

Но зачем? Раз уж выявили, то можно существующих код на C подправить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #82, #189

63. Сообщение от Аноним (-), 28-Фев-21, 15:46   +2 +/
Не всем удается без смс и просмотра рекламы его скачать. Может по-этому ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

64. Сообщение от Аноним (62), 28-Фев-21, 15:46   +2 +/
Так смузи-фанбои они же наоборот, за Rust топят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

65. Сообщение от Аноним (65), 28-Фев-21, 15:46   +/
Я не вижу достаточной аргументации, лишь верчение словами, а это не ответ.
>С чего ты взял, что обновления безопасности не жрут память?

А счего ты взял, что жрут? OpenBSD у меня из коробки 20 Мб ест. И это при том, что проект стремится из коробки иметь много всякого для безопасности. Так почему же Linux стал больше есть? Может быть, знаете конкретную причину, конкретные изменения, приведшие к этому? Если нет, то разговор бессмысленный.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #105

66. Сообщение от Аноним (65), 28-Фев-21, 15:47   –1 +/
Нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

67. Сообщение от Аноним (62), 28-Фев-21, 15:48   –3 +/
>Fracta1L теперь не нужен.

Но, ведь, скучно без него будет :)

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

68. Сообщение от Аноним (68), 28-Фев-21, 15:59   +/
> что самое интересное, его плюсуют какие-то смузи-фанбои, что говорит о том, насколько интеллектуально развиты 95% местной аудитории

Сам и плюсует - делов-то, запустить скрипт трехстрочник.


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

69. Сообщение от Плохой Танцор (?), 28-Фев-21, 15:59   –3 +/
По моему скромному мнению, это всё костыли, а проблема кроется в неудачной архитектуре процессора и его системы команд. Можете бить меня тапками или кидать в меня камни, но от своего скромного мнения, я не откажусь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71, #110, #129, #157

70. Сообщение от Сишник (?), 28-Фев-21, 16:01   +2 +/
> А говорит ли об этом компилятор?

Так это ж не встроено в язык.
>  А почему мне язык не даст по рукам, если я использую небезопасную версию
> Такова иделогия языка, что он ничего не навязывает. Впрочем компилятор делает проверки и выводит предупреждения в подозрительных случаях. В случае, когда цена ошибки - человеческая жизнь (автопром, авиация, ракетчики, медицина) - придерживаются определённых в стандарте MISRA C ограничений. Ну а если цена ошибки - вылетающая в 0.0001% случаях игра, зато можно поиметь на 20fps больше, пишут быстро, но небезоапсно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #73

71. Сообщение от Ordu (ok), 28-Фев-21, 16:07   +2 +/
> от своего скромного мнения, я не откажусь.

Да кому ты нужен со своим скромным мнением?

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

72. Сообщение от Аноним (-), 28-Фев-21, 16:12   +2 +/
> Ну так и в сишке можно массив гарантированно обойти без промаха и
> проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.

Понимаешь, алгебраические типы данных и отсутствие null - это не только модные слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки, заэнфорсив только одну - при проверке входящих данных.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #74, #163, #185

73. Сообщение от Аноним (-), 28-Фев-21, 16:16   –2 +/
> Такова иделогия языка, что он ничего не навязывает.

Таково древнее наследие обратной совместимости и отсутствие проработанной базы (и вычислительных возможностей) теории типов 50 лет назад.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #78

74. Сообщение от Сишник (?), 28-Фев-21, 16:21   –1 +/
На днях подобное смузихлёбство переписал по-человечески в императивном стиле, с той же в точности логикой - перформанс в ~10 раз вырос. Хотя там у компилятора был шанс выкинуть ненужное, но что-то не смог он, вопреки верованиям смузихлёбов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

75. Сообщение от Аноним (75), 28-Фев-21, 16:23   +/
>Подобная функциональность уже присутствовала в ядре в виде опции сборки KASAN (kernel address sanitizer, использует Address Sanitizer в современных gcc и clang) - однако позиционировалась в основном для отладочного применения.

Но ведь на убунте kasan из коробки идёт, и включается опцией в строке ядра.

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

76. Сообщение от Аноним (75), 28-Фев-21, 16:25   +1 +/
Ошибся, не  kasan, а  kaslr.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

77. Сообщение от Аноним (75), 28-Фев-21, 16:28   –1 +/
Судя по описанию, на рабочих системах такое не нужно, в эксплоитах это обойдут, а говнодрайверы броадкома и так постоянно крашатся при полном отсутствии свободных аналогов, хорошо что хоть к панике ядра это не приводит.
Ответить | Правка | Наверх | Cообщить модератору

78. Сообщение от Сишник (?), 28-Фев-21, 16:43   –2 +/
А ещё мощности ЦП подросли для выполнения смузихлёбного кода за приемлимое время и сишных библиотек на все случаи написали, которые смузихлёбы своим смузи-кодом склеивают в относительно юзабельные приложения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

79. Сообщение от пердёжник (?), 28-Фев-21, 16:54   –2 +/
> Сабж это культ-карго от легковерных туземцев, которые ужас как боятся дыреней.

Ну да, это нормально когда у вас приложение вылетает раз в час (сарказм)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #140, #179

80. Сообщение от freecoder_xx (?), 28-Фев-21, 17:01   +4 +/
Это пять! Зашел сюда специально, чтобы почитать комменты про Rust. Заголовок новости просто кричит о том, что в комментариях будут его обсуждать. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #84

81. Сообщение от Аноним (81), 28-Фев-21, 17:20   +3 +/
Садись, два
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

82. Сообщение от Аноним (81), 28-Фев-21, 17:21   +/
Да это просто влажные мечты растомана. Проходим мимо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

83. Сообщение от Анончик (?), 28-Фев-21, 18:36   +/
каким был тролем таким и остался. Думал возраст тебя исправит но видно нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

84. Сообщение от Анончик (?), 28-Фев-21, 18:38   +/
Ну только поржать над людьми которые больше helloworld.c не видели и даже не вдупляют что такое санитайзер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

85. Сообщение от Анончик (?), 28-Фев-21, 18:43   +/
полгода назад выкинул 10 планок по 64мб pc-133, до этого оно лежали на авито с полгода по 1 рубль штука.
Они тупо не нужны были людям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #193

87. Сообщение от Аноним (87), 28-Фев-21, 19:43   +/
Если Rust такой хороший, зачем нужны подобные патчи? Шах и мат, смузихлёбы
Ответить | Правка | Наверх | Cообщить модератору

88. Сообщение от Аноним (88), 28-Фев-21, 20:27   +2 +/
> А почему все не юзают?

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

> А говорит ли об этом компилятор?

Зависит от хотелок. Может и говорить.

> А почему мне язык не даст по рукам, если я использую небезопасную версию, если безопасная версия не имеет штрафа по перформансу?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #101

89. Сообщение от Аноним (-), 28-Фев-21, 21:24   +/
Товарищи, как бы это дело бекпортировать хотяб на 4.19 ? Памагите !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #90

90. Сообщение от Аноним (-), 28-Фев-21, 21:28   +1 +/
И что это за сабатирование arm-a ? зачем 64, не хотим мы 64
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #109

92. Сообщение от GrayRats (ok), 28-Фев-21, 22:13   +/
ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #93, #174

93. Сообщение от Аноним (-), 28-Фев-21, 22:58   +/
> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
> ядро пишут на С и Shell
> Shell и других очень низких языках

Это опеннет ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #121

94. Сообщение от Онаним (?), 28-Фев-21, 22:59   +1 +/
Нужно. А то ядро почти не течёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

95. Сообщение от Онаним (?), 28-Фев-21, 23:00   +3 +/
Самое место внутри IRQ :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #120

96. Сообщение от Онаним (?), 28-Фев-21, 23:03   +/
Делайте скидку на x86-64, в два раза разбухают указатели.
Плюс сам код рыхлее.
Но и модули памяти на месте не стояли, в пристойных машинах менее 4G уже не встретить, а на серверах вообще кошмарные объёмы, у меня системный SSD меньше :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #115, #139

97. Сообщение от Онаним (?), 28-Фев-21, 23:04   –2 +/
Смотря какие huge pages. Если transparent - то ведро нормально справляется с переаллокацией. Если принудительные аллокации в софте - там да, хип на полтора байта 2 метра весит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #99

98. Сообщение от Онаним (?), 28-Фев-21, 23:04   +/
Тут скорее проблема как можно быстрее мусорное ведро найти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

99. Сообщение от timur.davletshin (ok), 28-Фев-21, 23:08   +/
> Смотря какие huge pages. Если transparent - то ведро нормально справляется с
> переаллокацией. Если принудительные аллокации в софте - там да, хип на
> полтора байта 2 метра весит.

Ну переключи madvise параметр у ядра и проверь, сколько будет жрать ОЗУ после перезагрузки. Потом сравнишь с умолчальным. Разница будет в несколько сот мегабайт.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #100, #102

100. Сообщение от Онаним (?), 28-Фев-21, 23:21   +2 +/
> Ну переключи madvise параметр у ядра и проверь, сколько будет жрать ОЗУ
> после перезагрузки. Потом сравнишь с умолчальным. Разница будет в несколько сот
> мегабайт.

Взял одну из тестовых систем с MariaDB и обвесом. Поигрался.

transparent_hugepage=never

MiB Mem :  19977.5 total,  14021.8 free,   3160.5 used,   2795.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  16383.6 avail Mem

transparent_hugepage=madvise

MiB Mem :  19977.6 total,  14056.1 free,   3145.9 used,   2775.5 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  16280.9 avail Mem

transparent_hugepage=always

MiB Mem :  19977.6 total,  13979.7 free,   3223.9 used,   2774.0 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  16210.3 avail Mem

(последний бут из meminfo - большие страницы есть в принципе)
DirectMap4k:      220592 kB
DirectMap2M:     9207808 kB
DirectMap1G:    12582912 kB

(количество распределённых по нулям, не нужны они софту :D)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #104, #106

101. Сообщение от Аноним (12), 28-Фев-21, 23:22   –1 +/
То есть эта хитрая штука не переносима между платформами? Язык Си точно для кросплатформенной разработки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #128, #162, #183

102. Сообщение от Онаним (?), 28-Фев-21, 23:22   +/
С madvise даже немножко меньше выходит, потому что ядро себя слегка пооптимальнее раскладывает.
Но у меня с thp по другим причинам не сложилось, там на расщепление страниц очень большие накладные расходы, поэтому оно везде выключено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #103

103. Сообщение от timur.davletshin (ok), 28-Фев-21, 23:26   +/
C ним и должно меньше выходить. На десктопе разница заметнее кстати.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #107

104. Сообщение от Онаним (?), 28-Фев-21, 23:28   +/
Хотя не, про распределённые вру, total был более 0.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

105. Сообщение от Аноним (12), 28-Фев-21, 23:29   –1 +/
> А счего ты взял, что жрут?

Наблюдаю по ленсуку, венде и прочим живым ОС. Наращивание фич - увеличение потребления ресурсов

> OpenBSD у меня из коробки 20 Мб ест

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

>  И это при том, что проект стремится из коробки иметь много всякого для безопасности.

Перечисли пожалуйста, что именно, заодно напомни, когда последний раз находили в этой поделке уязвимости


>  Может быть, знаете конкретную причину, конкретные изменения, приведшие к этому?

Конечно знаю, это не сложно узнать, берешь и сравниваешь было/стало, разница приводит к потреблению ресурсов в том или ином виде за редким исключением


> Если нет, то разговор бессмысленный.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #114

106. Сообщение от timur.davletshin (ok), 28-Фев-21, 23:31   +/
Раз уж за жадный до РАМы Линукс пошла пьянка, то ещё аллокатор памяти можно на какой-нибудь jemalloc поменять через LD_PRELOAD. Со старыми версиями glibc (до 2.26 вроде) особенно было актуально. Сейчас тоже смысл есть зачастую, но надо тестировать с самым "любимым" приложением. Ситуация перестала быть очень однозначной. Плюс, ряд приложений внутренне уже используют свой аллокатор памяти (FF тот же jemalloc древней версии какой-то использует).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #108

107. Сообщение от Онаним (?), 28-Фев-21, 23:31   +/
Ну да. Там смотрю буферы диска с thp пооптимальнее ещё разложились.
Но всё равно, на системе с 12 крупными фоновыми демонами и ещё чистым MariaDB buffer pool никакими сотнями метров близко не пахнет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

108. Сообщение от Онаним (?), 28-Фев-21, 23:35   +1 +/
Мне показалось - именно показалось, тестов много не делал, что в последнее время разница между malloc и jemalloc почти стёрлась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #113

109. Сообщение от Онаним (?), 28-Фев-21, 23:37   +1 +/
Я так понимаю, "классический" arm лет через эннадцать пойдёт на выпил вместе с i?86 :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

110. Сообщение от Онаним (?), 28-Фев-21, 23:38   +/
Проблема кроется в неудачной архитектуре человеческих мозгов, которые не заточены на 100% точные вычисления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

111. Сообщение от Онаним (?), 28-Фев-21, 23:40   +/
1. x86-64
2. Ряд структур стал несколько более рыхлым с годами, но это позволяет иметь меньшую нагрузку на CPU
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

112. Сообщение от Онаним (?), 28-Фев-21, 23:40   +/
Ты тоже из тех, кто считает, что бывают сколь-либо сложные системы, в которых нет багов? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #117

113. Сообщение от timur.davletshin (ok), 28-Фев-21, 23:41   +1 +/
Она значительно уменьшилась, но не исчезла. Cугубо на синтетических тестах вроде http://ithare.com/testing-memory-allocators-ptmalloc2-tcmall.../ у меня jemalloc всё ещё выигрывает у родного. Но в реальных приложениях разница в производительности уменьшилась по сути до точности измерения. Хотя, по кол-ву пожираемой памяти разница есть заметная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108

114. Сообщение от Аноним (8), 28-Фев-21, 23:42   +/
Не знаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #118

115. Сообщение от Аноним (8), 28-Фев-21, 23:44   +/
Пару лет назад у меня был всё тот же x86-64. Видимо код разрыхлили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #116

116. Сообщение от Онаним (?), 28-Фев-21, 23:52   +2 +/
Не совсем код.
Взять то же ядро.
Cтруктурки повыравнивали, чтобы в кеш удобнее ложились. RCU во все поля. Куча percpu структур новых - рост числа ядер в процах породил необходимость параллелить всё, что можно. Ну и самих структурок поболе стало. В сетевом стеке только с 4.x до 5.x вагон и тележка изменений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

117. Сообщение от Аноним (12), 28-Фев-21, 23:58   +/
Я из тех, кто считает, что если тебя все устраивает, то зачем что-то менять?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #119

118. Сообщение от Аноним (12), 28-Фев-21, 23:59   +/
Прекрасно знаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

119. Сообщение от Онаним (?), 01-Мрт-21, 00:37   +/
Ну так абсолютно правильный ответ в начале дали. Нет смысла обновляться на новое ядро и т.п., если всё устраивает :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #136

120. Сообщение от n00by (ok), 01-Мрт-21, 08:20   +3 +/
"Но у меня на виртуалке работает!"  :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

121. Сообщение от n00by (ok), 01-Мрт-21, 08:24   +/
>> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен
>> ядро пишут на С и Shell
>> Shell и других очень низких языках
> Это опеннет ...

Как минимум Rosa Tresh полностью автономна и написана баш-программистами.

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

122. Сообщение от еман (?), 01-Мрт-21, 09:10   +/
они лишь оттягивают неминуемое переписывание на rust.

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #152, #156

124. Сообщение от Siborgium (ok), 01-Мрт-21, 09:44   +/
Оверхед, но никаких спинлоков там нет. Проблема там в том, что умные указатели плохо оптимизируются, но от этого страдают и кресты в той же степени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #203

125. Сообщение от Siborgium (ok), 01-Мрт-21, 09:45   +/
Полная чушь. Да, на расте можно писать как на си, но тогда он от си ничем не отличается. На сейф расте оверхед есть и он очень заметный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

126. Сообщение от Siborgium (ok), 01-Мрт-21, 09:49   +/
Так нет оверхеда, или есть автоматические проверки на выход за границу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #158

127. Сообщение от Совершенно другой аноним (?), 01-Мрт-21, 10:57   +/
Например, кривой пакет состоит из заголовка плавающего размера и тела. Например, в заголовке,  по лучшим традициям Microsoft (у них часто применялся такой подход) в самом начале есть длина заголовка, на основании которого можно вычислить, где начинается тело и размер самого тела пакета. Ну и вот, вдруг, например размер заголовка кто-то сформировал не 10, а 100. Соответственно при разборе такого пакета можно вылететь за буфер на 90 байт, если взаимно не контролировать все эти длины и между собой и с общей длиной пакета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #159

128. Сообщение от Совершенно другой аноним (?), 01-Мрт-21, 11:02   +1 +/
Скажем так, по всей видимости разработчики стандарта C никак не могли повлиять на разработчиков аппаратуры (тем более тогда архитектур было побольше). Соответственно, там где не получалось найти консенсус меж разработчиками аппаратуры, и где эта самая аппаратура вела себя по-разному, там разработчики стандарта C писали - мы не знаем, как на Вашем железе, с Вашим компилятором оно будет. Это сейчас Rust-а всего одна реализация, и там его разработчики могут сказать - у нас в компиляторе оно так, и мы говорим, что оно так стандартно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #135

129. Сообщение от InuYasha (??), 01-Мрт-21, 11:41   +/
Как бы, и да, но наследие есть наследие, и пилить архитектуру с чистого листа, конечно, можно (если есть много денег и времени), но её внедрение будет весьма затруднительно. Так что, пока живём с x86 и наслоением новых макроинструкций. \(o_O)/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

131. Сообщение от _ (??), 01-Мрт-21, 14:20   +/
О каких умных указателях ты говоришь?

Обычные ссылки (&T, &mut T) имеют в рантайме оверхеда даже меньше чем обычные указатели, ибо у них намного более строгие правила алиасинга

Box оверхед имеет только на этапе компиляции, в рантайме это тот же malloc/free
Rc имеет оверхед Box + подсчёт ссылок через inc/dec
Arc - тот же Rc, только подсчёт ссылок атомарный

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #169

132. Сообщение от Урри (ok), 01-Мрт-21, 17:22   +1 +/
А указатели на эти дополнительные струкуры не в физической памяти создаются?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

133. Сообщение от Урри (ok), 01-Мрт-21, 17:23   +/
Валгринд засунули в ядро.
Зачем?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #155

135. Сообщение от Аноним (135), 01-Мрт-21, 18:23   +/
Ну то есть эта штука не кросплатформенна
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #144

136. Сообщение от Аноним (135), 01-Мрт-21, 18:25   +/
ну так ему и сказали - не обновляйся, но ведь он хочет "безопасность", значит его уже не все устраивает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

137. Сообщение от Аноним (-), 01-Мрт-21, 19:56   +/
> Сылки на треды, в которых проходило обсуждение

"Мы все так говорим, а значит это правда!" (с)

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

138. Сообщение от Аноним (140), 01-Мрт-21, 23:10   +/
Это не указатели тупые, а ты тупой. В Раст есть unsafe и обычные указатели. В С++ обычные указатели это то же самое что unsafe, а есть умные указатели они как дефолтное поведение раста. Но ведь до тебя ты же растофанатик при том что на нём ни одной строчки даже не написал в силу тупости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

139. Сообщение от Аноним (140), 01-Мрт-21, 23:12   +/
Никаких скидок, только рассрочка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

140. Сообщение от Аноним (140), 01-Мрт-21, 23:13   +/
Сейчас 2021 год сейчас ничего не вылетает раз в час. Вылезь уже из криокамеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #154, #202

141. Сообщение от Аноним (140), 01-Мрт-21, 23:15   +/
Языку zig 5 лет, а топил ты за него когда его не было. Завязывай уже с тем что ты там делаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #143

142. Сообщение от Nuzhnyemail (?), 01-Мрт-21, 23:43   –1 +/
Brotli обсуждали? Вот: https://dropbox.tech/infrastructure/lossless-compression-wit...
Dropbox попробовал переисать на Раст и получилось на 28% медленнее. Причины освещены в статье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #147, #164

143. Сообщение от Аноним (6), 02-Мрт-21, 06:13   +1 +/
И что такого? Я оценил аргументы автора ещё когда он только разрабатывался. Но, в конечном счёте, пришлось признать, что си при грамотном подходе намного лучше альтернатив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #172

144. Сообщение от Совершенно другой аноним (?), 02-Мрт-21, 10:16   +/
> Ну то есть эта штука не кросплатформенна

На тот момент было: "а других кроссплатформенных языков у меня для Вас нет" (с).

Мне кажется, Вы всё-таки, пытаетесь оценивать без учёта тогдашней специфики:
- тогда было больше аппаратных архитектур - тяжелее было договориться производителям аппаратуры между собой - каждый гнул свою линию и не хотел подстраиваться под других - ведь уже в аппаратуре реализовано так, и никто под компилятор переделывать железо не будет. Что говорить, что тот-же представление float/double более-менее стандартизировали в 85-то году;
- тогда было гораздо больше разработчиков компиляторов, и C в частности, причём каждый из которых скорее всего ориентировался на свою родную аппаратную архитектуру, а другие плевал с большой колокольни (даже сейчас маленькая фирма Microsoft, которая активно участвует в разработке стандартов на язык C не реализовала у себя даже C99, не говоря об более новых C11 и д.р.). На одной платформе x86 были и borland C/C++, и несколько компиляторов от Microsoft, и Intel-евский компилятор, GCC, Watcom C/C++, Digital Mars C/C++ и, небось, ещё пяток компиляторов, про которые сейчас никто даже и не вспомнит;
- железо было, по сегодняшним меркам, очень слабое и заставить какую-то из аппаратных платформ делать что-то дополнительно, только для абстрактной совместимости, которая пользователям этого железа была не нужна, ну или явно не просматривалась, было тяжеловато.

С другой стороны у Rust сейчас:
- аппаратных архитектур, по сравнению со всем тем многообразием - раз два и обчёлся - кто там остались. В Rust более-менее нормально поддерживаются только 686, x86-64 и aarch64, без тестов (т.е. без гарантии того, что они хоть что-то правильно там компилируют) - arm, mips*, sparc*, power, riscv, 586.
- всего одна реализация компилятора, без всяких стандартов и необходимости хоть с кем-нибудь договариваться;
- аппаратное обеспечение гораздо мощнее, что позволяет как наворачивать сам компилятор, так и программно всех "стандартизировать" - добиваться того, что с точки зрения программы на разных аппаратных платформах она ведёт себя абсолютно одинаково - например нормализуя результат для тех платформ, которые по какой-либо причине выбиваются из строя.

Так-что, имхо, сравнивать в каких условиях развивался C, а в каких Rust не совсем корректно.

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

145. Сообщение от SR_team (ok), 02-Мрт-21, 10:48   +/
> Ему про тупые указатели

они unsafe

> он про раст и safe, сначала определи, что такое safe

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

> можешь при этом не использовать слово "раст"

за живое задел что-ли? Я не имел в виду ничего плохого в контексте раста


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

146. Сообщение от Аноним (149), 02-Мрт-21, 16:40   +/
А он был кому-то кроме фрактала (не написавшего не строчки) нужен?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

147. Сообщение от Аноним (-), 02-Мрт-21, 16:40   +1 +/
> Brotli обсуждали? Вот: https://dropbox.tech/infrastructure/lossless-compression-wit...
> Dropbox попробовал переисать на Раст и получилось на 28% медленнее.

А grep переписали в ripgrep и получилось быстрее. Причем не в абстрактновакуумных конях, а в реальном поиске в 2-3 гиговым репам.
Такие дела, да ...


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #161, #180

148. Сообщение от Аноним (149), 02-Мрт-21, 16:41   +/
Нет не выявляются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

149. Сообщение от Аноним (149), 02-Мрт-21, 16:42   +/
ооооооооооооо даааааааааааааааааааааааа

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

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

150. Сообщение от Аноним (149), 02-Мрт-21, 16:46   +/
> А когда запретят писать на "тупых" указателях?

А зачем? Не надо их запрещать. Они прекрасны.

Те кто не осилил - никто не заставляет использовать. Можешь вообще без указателей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #177

151. Сообщение от Аноним (152), 02-Мрт-21, 17:02   +/
> но предусмотрена настройка "panic_on_warn"

А нельзя просто грохать приложение?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #153, #160, #191

152. Сообщение от Аноним (152), 02-Мрт-21, 17:03   +1 +/
Они доказывают ненужность rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

153. Сообщение от Аноним (68), 02-Мрт-21, 17:36   +/
Так прикольнеее ^_^
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

154. Сообщение от пердёжник (?), 02-Мрт-21, 19:38   +/
> Сейчас 2021 год сейчас ничего не вылетает раз в час. Вылезь уже
> из криокамеры.

у меня десяточка стабильно вылетает раз в неделю с синим экраном. Полностью переполз на линукс

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

155. Сообщение от Аноним (157), 02-Мрт-21, 22:08   +1 +/
Чтобы не ждать вечность пока работает валгринд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

156. Сообщение от Аноним (157), 02-Мрт-21, 22:09   +/
> неминуемое переписывание на rust
> есть же и другие ошибки памяти

Ну вот ты и доказал ненужность хруста.

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

157. Сообщение от Аноним (157), 02-Мрт-21, 22:11   +/
Плохому танцору вечно что-то мешает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

158. Сообщение от Аноним (158), 03-Мрт-21, 01:28   +/
> Так нет оверхеда, или есть автоматические проверки на выход за границу?

Эти проверки и в Си по хорошему надо делать, поэтому никакого оверхеда, только автоматизация. Но если вотпрямкапецкакнадо, есть unsafe-метод.

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

159. Сообщение от тот самый Аноним (?), 03-Мрт-21, 01:37   +/
> Например, кривой пакет состоит из заголовка плавающего размера и тела. Например, в
> заголовке,  по лучшим традициям Microsoft (у них часто применялся такой
> подход) в самом начале есть длина заголовка, на основании которого можно
> вычислить, где начинается тело и размер самого тела пакета. Ну и
> вот, вдруг, например размер заголовка кто-то сформировал не 10, а 100.
> Соответственно при разборе такого пакета можно вылететь за буфер на 90
> байт, если взаимно не контролировать все эти длины и между собой
> и с общей длиной пакета.

Пакет с такой неверной длиной считается криво, но без вылетов за границу.

Если читать стандартными методами, то будет считано ровно под размер выделенного буфера. Ну или можно читать до конца, но только в расширяемый вектор. Это, конечно, не фича языка, просто в стандартной библиотеке есть вот такая готовая абстракция
https://doc.rust-lang.org/std/io/trait.Read.html

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #182

160. Сообщение от Ordu (ok), 03-Мрт-21, 02:14   +/
Какое приложение? Это санитайзер для ядерной кучи, для памяти используемой ядром. Если там косяк, то это косяк ядра, и юзерспейс код тут ни при чём. Более того, даже если его грохнуть, то это скорее всего не поможет, потому как косячные структуры в куче ядра продолжат существовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

161. Сообщение от Nuzhnyemail (?), 03-Мрт-21, 06:42   +/
А мой папа!
Так дети в песочнице хвалятся. А где тесты, где пруфы, где анализ того, почему быстрее... Будем верить на слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #166

162. Сообщение от Siborgium (ok), 03-Мрт-21, 07:08   +/
> То есть эта хитрая штука не переносима между платформами? Язык Си точно
> для кросплатформенной разработки?

Раст работает на всех (даже если принять работающими tier-3 платформы) платформах, поддерживаемых LLVM. Си работает на всех платформах, поддерживаемых LLVM, GCC, MSVC, ICC и многими другими компиляторами. Не адептам раста блеять про кроссплатформенность.

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

163. Сообщение от Siborgium (ok), 03-Мрт-21, 07:09   –1 +/
>> Ну так и в сишке можно массив гарантированно обойти без промаха и
>> проверок - макрос тип FOR(list, pointer, type) юзаешь и всё.
> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
> заэнфорсив только одну - при проверке входящих данных.

Покажи, где ты в С нашел null, и где в switch-case по union с тегом у тебя будут лишние проверки.

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

164. Сообщение от Alexey (??), 03-Мрт-21, 08:17   +1 +/
Надеюсь вы сами прочитали статью. Dropbox как минимум утверждает, что
1) реализация на Rust была безопаснее реализации на C
2) и "Zeroing memory: Telling the Rust allocator to avoid zeroing the memory when allocating for Brotli improves the speed to 224 MB/s.". Т.е. выключение опции обнуления памяти при освобождении увеличила скорость до 224 MB/с, против 217 MB/s для реализации на C. Упс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #165

165. Сообщение от Совершенно другой аноним (?), 03-Мрт-21, 09:50   +/
> Надеюсь вы сами прочитали статью. Dropbox как минимум утверждает, что
> 1) реализация на Rust была безопаснее реализации на C
> 2) и "Zeroing memory: Telling the Rust allocator to avoid zeroing the
> memory when allocating for Brotli improves the speed to 224 MB/s.".
> Т.е. выключение опции обнуления памяти при освобождении увеличила скорость до 224
> MB/с, против 217 MB/s для реализации на C. Упс.

Там как-то текст "немного по дебильному написан".

;----X8
Currently the decompressor runs at 72% of the speed of the vanilla -O3 optimized Brotli decompressor in gcc-4.9 for decompressing 4 megabyte blocks of data. This means it is able to safely decompress Brotli data at 217 MB/s on a Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
;----X8

Я эти строки для себя перевёл как:

;----X8
На данный момент декомпрессор работает на 72% от скорости оптимизированного с gcc-4.9 для 4-х мегабайтных блоков. Это означает, что он может декомпрессировать данные Brotli со скоростью 217 МБ/с на ntel(R) Core(TM) i7-4790 CPU @ 3.60GHz.
;----X8

Т.е. 217 - это скорость декомпрессора на Rust (которая 72% от скорости C-шного варианта. Потом они отключили обнуление памяти и получили 224 Мб/с. Далее отключив проверки границ и включив unsafe они получили 249МБ/с, или 82% от C-шной реализации. Отсюда C-шная реализация имеет скорость имеет скорость около 300 МБ/с.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #181, #188, #198

166. Сообщение от Аноним (-), 03-Мрт-21, 14:46   +/
> А мой папа!
> Так дети в песочнице хвалятся.
> А где тесты, где пруфы,

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

Как и написано - берешь большую репу, берешь time и ищешь. Сравниваешь реальный результат.

> где анализ того, почему быстрее...

Ну да, без анализа реальность данная нам ощущениях (тормозной греп) резко станет неправдой. Хинт: в грепе с параллельным поискоим не очень. И нет, не нужно кивать на распараллеливание xargs - это не очень помогает grеp вырваться вперед (и не работает при поиске в больших файлах). Но если очень хочется именно анализ, то (5 летней давности)
https://blog.burntsushi.net/ripgrep/

> Будем верить на слово.

Учитывая, что репы на несколько гигов я как-то и не собирался загружать, толку то в красивых "пруфах" в виде копипасты (или скриншотов, с графиками) запуска time rg <>?
... впрочем, особой разницы с ссылкой выше в смысле повторимости тоже нет.
Если действительно интересно, а не "за по*раться", то тут на форуме не так давно уже были бенчи и сравнения одновременно еще и с ag
см. ветку начиная с #71 https://www.opennet.me/openforum/vsluhforumID3/118581.html#71 (скрытая модератором подветка тоже содержит бенч)


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #167, #168

167. Сообщение от Аноним (-), 03-Мрт-21, 14:49   +/
> ... впрочем, особой разницы с ссылкой выше в смысле повторимости тоже нет.

В смысле - данной Вами ссылкой. Ни кода, ни данных на которых тестировали там я как-то не обнаружил. А так-то да, графики красивые.

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

168. Сообщение от Nuzhnyemail (?), 03-Мрт-21, 16:55   +/
О, совсем другое дело. Почитаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

169. Сообщение от Аноним (-), 03-Мрт-21, 20:12   +/
Указатель обычно сводится к вгрузке аж 1 регистра (базы) константой (адресом), от которого потом и пляшут. В лучшем случае - круть типа LTO еще потом допрет, что вон там и вон там уже похожее было, так что вместо кодирования всего адреса закодирует только смещение в команде. В каком месте может оверхед возникнуть? Это ж примитивные регистровые операции в современных процессорах. Можно даже прямо относительно PC (IP, ...) кодировать на нормальных процах с относительной адресацией, ARM такое очень любят. Уродцы типа x86-32 не в счет, ими уже почти никто не пользуется.

Там и так эффективность запредельная, LZ4 даже на чистом асме народ побить не смог.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #199

170. Сообщение от Аноним (-), 03-Мрт-21, 20:16   –1 +/
Нене, за карго культом - к растаманам. У них там эрзац пакетного менеджера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

171. Сообщение от Аноним (-), 03-Мрт-21, 20:17   +/
> Благодаря этому инструменту выявятся те участки кода, которые нужно переписать на раст.

Пофиксить их на си будет сильно проще. А так растишки свой redox уже который там год переписыват. Но пока вроде ни 1 живого дева юзающего свое недоразумение для хотя-бы разработки ОС так и нет?

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

172. Сообщение от Аноним (-), 03-Мрт-21, 20:23   +1 +/
Для си статический анализ и инструментацию более-менее нарулили. А типовые проблемы - хотя-бы уже известны. А когда все обмазано новыми кульными фичами, там вообще поди угадай что сломается. К тому же растаманы шагу ступить без unsafe не могут, особенно в системщине, а так arian 5 даже и на ada безопасной расфигачили. Ну и вообще, был прикол когда олдскульный натовский разработчик авионики дал нехилый мастеркласс хипстоте, фапавшей на contract driven. Он у них баг нашел прямо в контракте. В том алгоритме который они пытались реализовать. А, он естественно на сях без багов такое же написал в два счета. Без обмазывания контрактами.

И тем не менее, то что вы не знали о своем коде и боялись спросить:
http://fastcompression.blogspot.com/2019/01/compiler-warning...

Ну что, признавайтесь, шалунишки, кто смог собрать свой код на самом придирчивом уровне? :)

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

173. Сообщение от Аноним (-), 03-Мрт-21, 20:25   –1 +/
> раст, в отличии от, делает проверки на этапе компиляции

А тут их железка делает. Условно халявно - она всегда это делает, просто более креативное использование paging. Хруст, кстати, без MMU тоже, видите ли, много чего не могет - так он тоже на поддержку некоторых constraints железками полагается.

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

174. Сообщение от Аноним (-), 03-Мрт-21, 20:26   +/
> ммм ядро пишут на С и Shell и других очень низких языках раст тут не нужен

На shell там разве что кусочки системы сборки, лол.

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

175. Сообщение от Аноним (-), 03-Мрт-21, 20:28   +/
> сначала определи, что такое safe, можешь при этом не использовать слово "раст"

У хрустиков есть кейворд такой. И что характерно, системщина без него чего-то ну совсем вот не обходится. Доходит до того что эти чудо кодеры пишут unsafe, asm, ну и какой там safety дальше наверное понятно. Черт, это уже даже статический анализ не сожрет, в asm видите ли маловато формальных деклараций намерений было.
  

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

176. Сообщение от Аноним (-), 03-Мрт-21, 20:29   +1 +/
> Чего минусов налепили? Проверьте сами в виртуалке хотя бы.

Запустил armhf версию на 64 мегах без свопа. Нормально? Не быстро, конечно - дискового буфера мизер.

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

177. Сообщение от Аноним (178), 03-Мрт-21, 20:34   +/
Особенно с железками поработать. Особенно когда точный паттерн доступа к адресу важен, ога. Но хрустики напишут unsafe asm и поимеют офигенно безопасТный и охренеть какой читаемый код.

А так то сие на сях делается. Если осторожно.

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

178. Сообщение от Аноним (178), 03-Мрт-21, 20:37   +/
Сабж таки позиционируется как годный и для продакшнового применения. Если от KASAN оверхед солидный то от этого уже куда разумнее. Поэтому можно позволить себе избавиться от непонятных барабашек и сделать хакерам неудобно. Если это важнее максимального перфоманса любой ценой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #184

179. Сообщение от Аноним (178), 03-Мрт-21, 20:37   +/
> Ну да, это нормально когда у вас приложение вылетает раз в час (сарказм)

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

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

180. Сообщение от Аноним (178), 03-Мрт-21, 20:39   +/
> А grep переписали в ripgrep и получилось быстрее.

А кто сказал что там алгоритмы одинаковые были? Вон там сравнили один конкретный алгоритм, одинаковый. Вот это честное сравнение. А две напрочь разные программы - ни о чем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #186

181. Сообщение от Аноним (178), 03-Мрт-21, 20:41   +/
И это, gcc 4.9 немного протух. А они не хотят хотя-бы 9..10 взять? А то б еще 2.95 бенчмаркали :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #190

182. Сообщение от Аноним (-), 03-Мрт-21, 20:46   +/
> Это, конечно, не фича языка, просто в стандартной библиотеке есть вот
> такая готовая абстракция

Особенно интересно будет когда ты попробуешь все это в кернел моде провернуть. А хочешь прикол? Нет, никто в здравом уме и твердой памяти в ядро даже libc не засунул. Как максимум, для очень сильно нагруженных сисколов у них есть забавный хак с vDSO, когда ядро :) подпихивает типа-либу в адреса процесса. Но вот у самого по себе ядра стандартного сишного рантайма, внезапно, нет.

Более того - окружение в котором работает кернел и допущения о том что там и как здорово отличаются от "апликушных" подходов и либ. И на это были хорошие причины. Например фундаментально разная цена сбоев. Если у вас out of memory в программе, ну, хрен с ней с программой. А вот если это уже с ядром - ну, допустим, та абстракция не сможет отрастить буфер. Что будет дальше? Жоский кернелпаник с обрушением ВСЕЙ СИСТЕМЫ? А такая система будет кому-то нужна вообще?

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

183. Сообщение от Аноним (-), 03-Мрт-21, 20:49   +/
> То есть эта хитрая штука не переносима между платформами? Язык Си точно
> для кросплатформенной разработки?

Так то си есть для сильно большего количества архитектур чем хруст. А что, хруст умеет в MSP430 или там STM8 какой? Да, они продаются. Сейчас. Миллионами.

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

184. Сообщение от Аноним (6), 03-Мрт-21, 20:49   +/
Если есть проблемы. Если их нет, то и оверхэд ни к чему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #196

185. Сообщение от Аноним (-), 03-Мрт-21, 20:52   +/
> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
> заэнфорсив только одну - при проверке входящих данных.

Как ни странно, GCC в этом довольно неплохо преуспевает. А прикинь, он сам умеет в range check и если видит что я никогда не вызываю вон ту функцию с вон теми параметраим - выкидывает к хренам и проверки, и имплементацию этого случая.

Внезапно, в кернелмоде, с модулями и всем таким, это может сыграть дурную шутку: компилер внезапно не видит всех возможных сценариев. Как будет юзать вон тот код вот это и это - ок, а что насчет юзерского loadable module? Его видите ли совсем не было compile time :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #187

186. Сообщение от тот самый аноним (?), 04-Мрт-21, 00:58   +/
> Вон там сравнили один конкретный алгоритм, одинаковый.
> Вот это честное сравнение.

При этом, один и тот же алгорим может быть реализован разными способами, что существенно влияет на конечный результат
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


×     source     secs     mem
1.0 Rust 0.45 499,168
1.4 C++ g++ 0.63 499,704
1.7 Rust #2 0.75 995,144
1.7 Rust #3 0.78 995,136
1.9 C gcc 0.86 698,264
2.2 C gcc 0.98 994,220
3.1 C gcc 1.41 994,048
...
5.4 C++ g++ #3     2.42     499,964     
6.4 C++ g++ #6    2.88     1,505,952     
7.6 C gcc #4    3.40     500,236     
13 C++ g++    5.96     979,844     

> А две напрочь разные программы - ни о чем.

Две разные реализации - собственно тоже.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #197

187. Сообщение от Аноним (-), 04-Мрт-21, 01:15   +/
>> Понимаешь, алгебраические типы данных и отсутствие null - это не только модные
>> слова акедемических смузихлебов последних 30 лет, но и возможность для компилятора
>> сильно ограничить некорректные состояния вычислений и выкинуть на*рен все лишние проверки,
>> заэнфорсив только одну - при проверке входящих данных.
> Как ни странно, GCC в этом довольно неплохо преуспевает. А прикинь, он
> сам умеет в range check и если видит что я никогда
> не вызываю вон ту функцию с вон теми параметраим - выкидывает
> к хренам и проверки, и имплементацию этого случая.

А прикинь - как ни странно, для этого используются наработки "смузихлебов" по оптимизации, можешь глянуть на md или pd файлы или как выглядит RTL (хинт:

(set (reg:SI 140)
     (plus:SI (reg:SI 138)
              (reg:SI 139)))

да и gcc-extensions типа pure - как раз про это.

> Внезапно, в кернелмоде, с модулями и всем таким, это может сыграть дурную
> шутку: компилер внезапно не видит всех возможных сценариев. Как будет юзать
> вон тот код вот это и это - ок, а что
> насчет юзерского loadable module? Его видите ли совсем не было compile time :)

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

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

188. Сообщение от Alexey (??), 04-Мрт-21, 06:35   +/
Да, похоже на то. Они как-то коряво написали, но дальше однозначно

Activating unsafe mode results in another gain, bringing the total speed up to 249MB/s, bringing Brotli to within 82% of the C code.

Так что да, rust медленнее.

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

189. Сообщение от пердёжник (?), 04-Мрт-21, 08:25   +/
> Но зачем? Раз уж выявили, то можно существующих код на C подправить.

тоже логично

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

190. Сообщение от Совершенно другой аноним (?), 04-Мрт-21, 10:01   +/
> И это, gcc 4.9 немного протух. А они не хотят хотя-бы 9..10
> взять? А то б еще 2.95 бенчмаркали :)

Там просто статья за 2016 год, тогда максимальная версия gcc была 5.X, но может она в том дистрибутиве, которые они использовали, не поставлялась.

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

191. Сообщение от all_glory_to_the_hypnotoad (ok), 04-Мрт-21, 14:54   +/
Можно, panic_on_warn именно это и делает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

192. Сообщение от Аноним (192), 04-Мрт-21, 23:28   –1 +/
Когда система уходит в бесконечный своп и перестаёт реагировать на операции ввода, о чём в это время думает Торвальдс, какие все кругом 3.14-до-сы?
Ответить | Правка | Наверх | Cообщить модератору

193. Сообщение от Аноним (193), 07-Мрт-21, 00:17   +/
> полгода назад выкинул 10 планок по 64мб pc-133, до этого оно лежали
> на авито с полгода по 1 рубль штука.

Странно, они на драгмет заметно дороже идут.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #195

194. Сообщение от Аноним (194), 07-Мрт-21, 00:21   +/
> Там длинная история: https://www.opennet.me/openforum/vsluhforumID3/119728.html#31

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

> Патчи распространяются под GPL-2 и их можно включать в основное ядро.

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

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

195. Сообщение от n80 (?), 07-Мрт-21, 10:08   +/
> Странно, они на драгмет заметно дороже идут.

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

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

196. Сообщение от Аноним (196), 07-Мрт-21, 10:25   +/
> Если есть проблемы. Если их нет, то и оверхэд ни к чему.

Оно как бы да. И все же в проекте ТАКОГО размера уповать на полное отсутствие багов - для оптимистов. А кому безопасность и отсутствие багов важнее - ну вот теперь будет оно, как еще 1 вариант.

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

197. Сообщение от Аноним (-), 07-Мрт-21, 10:33   +/
> При этом, один и тот же алгорим может быть реализован разными способами,
> что существенно влияет на конечный результат

Оно как бы да, но есть нюансы.

> https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

> Две разные реализации - собственно тоже.

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

На самом деле там сам алгоритм довольно средненький, кста, но гугол массой продавил, а автор креативно смухлевал с предзагруженным словарем. Если кого скорость, особенно распаковки волновала, zstd в этом плане интереснее.

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

198. Сообщение от Аноним (198), 07-Мрт-21, 13:58   +/
> Далее отключив проверки границ и включив unsafe они получили 249МБ/с, или
> 82% от C-шной реализации. Отсюда C-шная реализация имеет скорость имеет
> скорость около 300 МБ/с.

Что-то не выглядит эпично. Профакать треть скорости, поотключать все фичи безопасности и все равно не догнать.

Так то понятнее чего растаманов увольняют: на треть больше серваков ставить жаба душит, а если там unsafe везде и все такое - а в чем профит этой камасутры был? "Зато на расте"? oO

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

199. Сообщение от _ (??), 11-Мрт-21, 11:28   +1 +/
Оверхед появляется на оптимизируемом коде с алиасингом, см сишный restrict

В Rust все ссылки по умолчанию restrict, но на деле их можно оптимизировать ещё сильнее, т.к у Rust правила алиасинга более строгие чем можно выразить в C

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

201. Сообщение от Аноним (201), 30-Авг-21, 16:40   +/
Может, тебе подумать, какому бы музею вычтехники всю твою коллекцию продать? На вырученны, глядишь, и один новый компуктер прикупить выгорит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

202. Сообщение от нах.. (?), 31-Авг-21, 15:39   +/
Ну дык да, стабильно раз в 10 минут или random time.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

203. Сообщение от Славик (ok), 14-Окт-22, 10:35   +/
Я имел ввиду Thread Safety смарт поинтера. Если не спинлок то атомик, хрен редьки не слаще.

Ой.. позновато прочитал.

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


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

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




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

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