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

"Facebook присоединился к организации Rust Foundation"	+/–
Сообщение от opennews (ok), 29-Апр-21, 22:25
Компания Facebook  вошла в число платиновых участников организации Rust Foundation, которая курирует связанную с языком Rust экосистему, поддерживает основных мэйнтейтнеров, занимающихся разработкой и принятием решений, а также отвечает за организацию финансирования проекта. Платиновые участники получают право вхождения представителя компании в совет директоров.  Представителем Facebook стал Джоэл Марси (Joel Marcey), который присоединился в совете директоров к представителям AWS, Huawei, Google, Microsoft и Mozilla, а также пяти участникам,  выбранным из Core Team и групп, отвечающих за надёжность, качество и взаимодействие с сообществом... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55049
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Wilem82 (ok), 29-Апр-21, 22:25	–3 +/–
Щас что-нить про макак начнут ныть, вангую.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5, #8

3. Сообщение от Аноним (3), 29-Апр-21, 22:27	+6 +/–
макаки ноют
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Аноним (5), 29-Апр-21, 22:32	+1 +/–
Ну да, ну да, ведь манагеры пейсбука, ответственные за подобные решения имеют, как минимум, лет сто опыта работы с С/С++ и нахлебались с этими наколенными поделками горя, так что точно знают, что делают. Только идиот может подумать, что такое прорывное решение может быть как-то связано с пиаром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6, #7

6. Сообщение от Аноним (5), 29-Апр-21, 22:44	+2 +/–
Ну и да, они заслали в РастФандэйшн своего главного ПХПшника. Но вам всё божья роса, прогрессивные вы ниши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

7. Сообщение от Wilem82 (ok), 29-Апр-21, 22:45	+/–
Манагеры не продумывают технические решения. Они максимум могут их одобрить, когда инженеры объяснят зачем это нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от Аноним (8), 29-Апр-21, 22:50	+3 +/–
Макака82 начала ныть :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

9. Сообщение от Аноним (8), 29-Апр-21, 22:52	+8 +/–
> Facebook Что на этот раз будет сливать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #39

14. Сообщение от Аноним (14), 29-Апр-21, 23:31	+4 +/–
Ржавую воду
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

18. Сообщение от Аноним (18), 29-Апр-21, 23:46	+2 +/–
GTK создали для гимпа, но в итоге это гноме тулкит. Раст создали для фаерфокса - оранжевого, но в итоге хз что будет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #77, #83

19. Сообщение от Анонин (?), 29-Апр-21, 23:50	–1 +/–
> в итоге это гноме тулкит Гимп они тоже забрали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

20. Сообщение от Аноним (20), 30-Апр-21, 00:00	+14 +/–
>например, на Rust написаны применяемые в Facebook Mercurial-сервер Mononoke Новость о том, что существует такой сервер, поважнее будет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #63

22. Сообщение от Аноним (22), 30-Апр-21, 00:27	+7 +/–
Теперь ясно, Rust - очередная диверсия корпорастов в опенсорсе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #27, #50

23. Сообщение от Ты идиот лол (?), 30-Апр-21, 00:28	–1 +/–
Ну всё. Теперь чтоб юзать раст придётся предоставлять удостоверение личности 🤣🤣🤣
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78

24. Сообщение от Аноним (24), 30-Апр-21, 00:29	+7 +/–
опенсорс это диверсия корпорастов по определению
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29, #79

26. Сообщение от Аноним (27), 30-Апр-21, 00:45	+/–
Что ж, Раст не зря отправился в свободное плавание, стены Мозиллы он давно перерос Следим дальше
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57

27. Сообщение от Аноним (27), 30-Апр-21, 00:46	+7 +/–
Кстати, что интересно, сделать в Расте проприетарную либу - не самая тривиальная задача
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #33

29. Сообщение от НяшМяш (ok), 30-Апр-21, 01:11	+/–
Диверсификация рисков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

33. Сообщение от Аноним (33), 30-Апр-21, 02:49	+/–
> сделать в Расте проприетарную либу - не самая тривиальная задача сделать в расте хоть что-то работающее - уже нетривиальная задача.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #35, #41, #105

35. Сообщение от Аноним (27), 30-Апр-21, 03:21	+7 +/–
Эээ, почему это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

38. Сообщение от Аноним (-), 30-Апр-21, 04:26	–2 +/–
"Компания Facebook вошла в число партийных участников ..." Исправлено и дополнено. Исправленому верить. "мэйнтейтнеров" Так, и только так надо писать это слово.
Ответить | Правка | Наверх | Cообщить модератору

39. Сообщение от Леголас (ok), 30-Апр-21, 06:17	+6 +/–
как обычно ВСЁ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

40. Сообщение от Ivan_83 (ok), 30-Апр-21, 06:22	–2 +/–
Кто видел фабрикатор - тот понимает что новость печальная для раста :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #65, #72

41. Сообщение от Аноним (41), 30-Апр-21, 06:25	+7 +/–
не более, чем на C или C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

42. Сообщение от Lex (??), 30-Апр-21, 06:34	–1 +/–
Означает ли это, что из фейсбука перестанут литься данные пользователей всем кому не лень ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #55

44. Сообщение от n00by (ok), 30-Апр-21, 07:00	+1 +/–
> Означает ли это, что из фейсбука перестанут литься данные пользователей всем кому > не лень ? Прекратятся утечки про утечки данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

48. Сообщение от Nikki Next (?), 30-Апр-21, 07:21	–2 +/–
Найдите серьезный софт на расте
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #66, #74, #84, #95

50. Сообщение от Fracta1L (ok), 30-Апр-21, 07:45	+4 +/–
Клятые корпорасты лишают бедных бородачей возможности бесконечно латать сишные дыры. Не забудем, не простим!!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #53

51. Сообщение от paulus (ok), 30-Апр-21, 07:52	+/–
проприетарно же спрятан :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

53. Сообщение от Lex (??), 30-Апр-21, 08:24	–2 +/–
Взамен сишных дыр придут дыры ржавые
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #61

55. Сообщение от lockywolf (ok), 30-Апр-21, 08:31	+/–
Где скачать? Мне нужно для одного пет-проджекта...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

56. Сообщение от lockywolf (ok), 30-Апр-21, 08:34	–1 +/–
Фейсбук такой большой, что ему можно всё.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58

57. Сообщение от bergentroll (ok), 30-Апр-21, 08:44	+2 +/–
Выпал из гнезда и такой «надо в дорогу-дорогу-дорогу мне торопиться!..».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #67

58. Сообщение от Ivan_83 (ok), 30-Апр-21, 08:48	–2 +/–
У пёсбука скажем так нетрадиционный подход ко всему, притом я бы сказал в негативном смысле. Примерно как у телевизионщиков или телефонистов - они просто невыносимы :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #59

59. Сообщение от lockywolf (ok), 30-Апр-21, 09:02	+1 +/–
Все невыносимы, кроме админов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

61. Сообщение от Аноним (27), 30-Апр-21, 09:18	–1 +/–
Побойтися бога, в расте дыры ещё найти надо, а крэш словить без ffi вообще маловероятно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

63. Сообщение от Аноним (63), 30-Апр-21, 09:51	+/–
ну  может где-то внутри пейсбука и существует, тебе-то что с того? https://github.com/facebookarchive/mononoke - упс, пустое место. Пейсбук не собирается делиться с тобой технологиями, пригодными к использованию (ссылка на бесполезного несовместимого недоделка в вечном процессе "переписывания" - это ни разу не пригодное к использованию)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #68

65. Сообщение от Аноним (63), 30-Апр-21, 09:54	+/–
Что тебе не так с фабрикатором? Недостаточно эмодзишечек?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #87

66. Сообщение от Ыноним (?), 30-Апр-21, 10:12	–3 +/–
https://github.com/topics/rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #92

67. Сообщение от пох. (?), 30-Апр-21, 10:19	–2 +/–
Это была его лебединая песня. Под деревом, с которого выпал, вот такое: https://d.radikal.ru/d22/2002/ca/d5f430c08f46.jpg Хлоп, и уже переваривается.  Пейсбуком, с очень плохой дорогой пополам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

68. Сообщение от . (?), 30-Апр-21, 10:45	+2 +/–
Это у них теперь часть EdenSCM: https://github.com/facebookexperimental/eden/tree/master/ede...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #69

69. Сообщение от пох. (?), 30-Апр-21, 11:31	–2 +/–
Имянно - то есть доделано не было и не будет никогда (а совместимости с настоящим hg уже нет). А то что за закрытыми дверями использует сам пейсбук- вам не дадут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #70, #71, #108

70. Сообщение от anonymous (??), 30-Апр-21, 11:50	+1 +/–
Доделано .было и опубликовано было. Но в другом репозитории.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

71. Сообщение от anonymous (??), 30-Апр-21, 11:52	–1 +/–
За закрытыми дверями Facebook использует Eden, собственно. Вы просто лжёте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

72. Сообщение от anonymous (??), 30-Апр-21, 11:54	+/–
Я видел фабрикатор и не понимаю. Более того, я вообще не вижу связи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #89

74. Сообщение от anonymous (??), 30-Апр-21, 12:07	–3 +/–
Отвечали на этот вопрос уже тонну раз. Хоть бы сами поискали на GitHub и в Google, прежде чем писать этот комментарий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #82, #93

77. Сообщение от Аноним (77), 30-Апр-21, 12:48	–1 +/–
> Раст создали для фаерфокса - оранжевого, но в итоге хз что будет. Цвета радуги будут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

78. Сообщение от Аноним (77), 30-Апр-21, 12:50	+2 +/–
Достаточно надеть платье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

79. Сообщение от Клавиатур (?), 30-Апр-21, 12:53	–2 +/–
1) .. по определению анонима из его головы, а там может быть всякое и даже больше. 2) Назови пострадавших от диверсии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

80. Сообщение от Аноним (77), 30-Апр-21, 12:54	+4 +/–
Забавен факт, что даже самый задрипанный проект на ржавом обязательно пытается о сим факте упомянуть. Какой-то комплекс неполноценности.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #101

82. Сообщение от Goes (?), 30-Апр-21, 12:57	–2 +/–
Так мусор один находит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #109

83. Сообщение от Anonim (??), 30-Апр-21, 13:00	+/–
>  Раст создали для фаерфокса Неа. раст к тому моменту уже разрабатывался несколько лет. Наверно мозиловцы увидели что-то перспективное
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #107

84. Сообщение от Лягушка (?), 30-Апр-21, 13:02	+/–
Rust очень удобен как система сборки для libcurl, я могу в Cargo.toml сказать "скачай, собери и прилинкуй libcurl статически", и это будет работать. Никаких дополнительних динамических линков, описанная система работает даже с кросс-компиляцией. Скажите, можно ли как-то удобно сделать это на Си или как-то еще? Я бы очень хотел найти более удобное решение, сам не очень люблю Rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #91, #94, #100

87. Сообщение от Ivan_83 (ok), 30-Апр-21, 16:52	–1 +/–
С ним не так всё, когда вы начинаете в нём работать это становится очевидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

88. Сообщение от Аноним (-), 30-Апр-21, 16:52	+4 +/–
Так что это получается?!.. Важно не компетентное мнение комментаторов Opennet, а шкурный интерес каких-то состоятельных проходимцев?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98

89. Сообщение от Ivan_83 (ok), 30-Апр-21, 16:57	–2 +/–
А вы не смотрите, а попробуйте там что то сделать. Это чудоподелие МЕСЯЦ всасывало репозиторий фри и портов фри, те всосало то оно быстро, потом жевало месяц. Тазик там не супермощный был, но всё же. Нажевало в итоге базу до 30Гб. Там нет пулрегвестов, есть поделие под это, где дифф надо или руками загружать или как то дурацкой утилитой написанной на пхп. Зато там есть куча всего не нужного. Файбрикатор - это сугубо внутренний продукт для мордоркниги для своих же ПХПеров, за пределами - он бесполезен и приносит больше вреда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #97

91. Сообщение от Аноним (33), 30-Апр-21, 18:44	+/–
То-то Линус ругал раст за отсутствие модульности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #96

92. Сообщение от Аноним (33), 30-Апр-21, 18:45	+/–
ну очень серьёзный софт :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

93. Сообщение от Аноним (33), 30-Апр-21, 18:45	–2 +/–
> поискали на Неуловимого Джона тоже ищут...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

94. Сообщение от Анонин (?), 30-Апр-21, 18:54	–1 +/–
> Rust очень удобен как система сборки для libcurl, я могу в Cargo.toml сказать "скачай, собери и прилинкуй libcurl статически", и это будет работать. Никаких дополнительних динамических линков, описанная система работает даже с кросс-компиляцией. В итоге бинари получаются очень жирными. > Скажите, можно ли как-то удобно сделать это на Си Meson или Makefile для труЪ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #99

95. Сообщение от Аноним (95), 30-Апр-21, 20:27	–1 +/–
Зачем его искать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

96. Сообщение от Аноним (-), 30-Апр-21, 21:35	+5 +/–
> То-то Линус ругал раст за отсутствие модульности. Только слушал эту ругань аноним как обычно принято на опеннете - жопой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

97. Сообщение от anonymous (??), 01-Май-21, 02:41	+/–
Во-первых сегодня много пользовался фабрикатором и просто недоумеваю о чём вы. Может так было когда-то давно? Во-вторых какая связь с Rust-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

98. Сообщение от Ordu (ok), 01-Май-21, 06:48	–1 +/–
Да в фейсбуке лошьё сплошное, наслушались растового маркетинга. И поверили, всем же известно, что маркетинг -- это сплошное враньё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

99. Сообщение от uis (ok), 01-Май-21, 10:39	+/–
CMake и Ninja
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #102

100. Сообщение от uis (ok), 01-Май-21, 10:45	+/–
>"скачай, собери и прилинкуй libcurl статически" А чем динамический не угодил? Libcurl гарантированно есть даже на ведроиде. Разве-что в openwrt его нет, но там статику ссаными тряпками гонят, ибо места мало. >Никаких дополнительних динамических линков Будет 30 файлов по 30 метров(900 всего) вместо 50 файлов по одному метру(50 всего) Такое есть смысл использовать в закрытых проектах. Ну ещё иногда для микроконтроллеров, но пихать туда libcurl изначально гиблая идея.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #106

101. Сообщение от uis (ok), 01-Май-21, 10:48	+/–
Занятно, что обычно он проявляется у пихтонщиков, жсников, жошников и собсна ржашников. pysmth, smth.js/smth.io, gosmth и smth-rust соответственно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

102. Сообщение от Анонин (?), 01-Май-21, 11:05	+/–
> CMake и Ninja Cmake на С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #114

103. Сообщение от InuYasha (??), 01-Май-21, 19:20	+2 +/–
Ох, вот теперь точно расхотелось в раст учиться... :-|
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #110, #111

105. Сообщение от Прохожий (??), 02-Май-21, 00:32	+1 +/–
Если не знаешь языка - конечно. Но так про любой язык можно сказать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

106. Сообщение от Ordu (ok), 02-Май-21, 04:56	–1 +/–
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W.../ Динамическая линковка внезапно добавляет рантайм косты, накидывает ряд других проблем, взамен чего она позволяет иногда экономить память. За пределами glibc не нужно. Не совсем понятно, чё все линуксодистры так озабочены динамической линковкой. Я тоже был озабочен, но вот сейчас мне не вспомнить почему, по-моему, лишь по той причине, что оверлеи в досе были продвинутой техникой, и уметь их делать было почётно. И как-то эта почётность в моей голове перепрыгнула на динамическую линковку. Но реально, это ж убожество. Ну ты сам прикинь: на каждую динамическую библиотеку при старте приложения надо сделать mmap, потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить, но ведь всё это можно было сделать статически, причём даже лучше сделать: lto, pgo, заинлайнить функций, выкинуть неиспользуемое из библиотеки, а оставшееся рпзместить компактнее и более кеш-френдли. Можно сделать офигенно, и один раз на все запуски приложения, но вместо этого почемуто предпочитают делать кое-как, наспех, и при каждом старте. Ппц какой-то. Очередное наследие старпёров, протухший юниксвей, феласофея, скрепы, духовность... а инженерная сторона вопроса никому не интересна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #113

107. Сообщение от Аноним (107), 03-Май-21, 01:53	+/–
Не разрабатывался, а только проектировался. Разрабатываться-таки он как раз с поддержкой Mozilla начал. И то - до сих пор родного компилятора нет, только LLVM-ный костыль, что отпугивает большинство знакомящихся конечным результатом компилируемого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

108. Сообщение от Аноним (107), 03-Май-21, 01:55	+/–
О, классическойи пох. пожаловал, не прошло и 12 часов с новости)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

109. Сообщение от Аноним (107), 03-Май-21, 01:58	+/–
Ваши комментарии не считаются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

110. Сообщение от Аноним (95), 03-Май-21, 08:19	+/–
А во что захотелось? Во что удалось научиться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

111. Сообщение от burjui (ok), 04-Май-21, 19:51	+/–
Немедленно перестань дышать, пить и есть, а то в тебя попадут молекулы, побывавшие в организме Гитлера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

113. Сообщение от uis (ok), 10-Май-21, 01:39	+/–
> Динамическая линковка внезапно добавляет рантайм косты, накидывает ряд других проблем Как бы это странно не звучало, но статика тоже может. Кеш-то не резиновый. Как процессорный, так и io. Да и так получается быстрее грузить систему с хардов или ещё чего с медленной скоростью чтения или случайного доступа. >За пределами glibc не нужно. Ну и перекомпилирую систему после обновления, например, libcurl. > Не совсем понятно, чё все линуксодистры так озабочены динамической линковкой. Драсты и правда озабочены. А лигуксоиды не все. Я знаю как минимум двух людей, которым всё равно. > Но реально, это ж убожество. Ну ты сам прикинь: на каждую динамическую библиотеку при старте приложения надо сделать mmap Дисковый кеш может спать спокойно > потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить Относительная адресация > это можно было сделать статически, причём даже лучше сделать: lto, pgo, Это про оптимизацию. Зубилом хлеб не режут, ножём не делают статуи. Ну и напоследок >https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_W... Тут немного про другое. Тут про черезмерное использование динамичечкой линковки. И да, со статикой модет работать быстрее. Но это не повод запрещать динамику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #115

114. Сообщение от uis (ok), 10-Май-21, 01:48	+/–
Meson вообще на питоне. И что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

115. Сообщение от Ordu (ok), 10-Май-21, 08:10	+/–
>> потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить > Относительная адресация Что относительная адресация? Вот написал ты в своей программе: printf("Hello, world\n"); Это сведётся к: call printf какой адрес у printf? Этот адрес станет известным только в процессе работы динамического линкера. И никакая относительная адресация тебе не поможет. pic код, как я понимаю, использует глобальную табличку оффсетов, и этот call становится косвенным вызовом, и требует дополнительного обращения к памяти. То есть, во-первых, ту табличку надо заполнить на этапе динамической линковки. Во-вторых, при _каждом_ вызове printf будет дополнительная стоимость для процессора -- обращение к глобальной табличке оффсетов, таким образом процессорный кеш, внезапно, вынужден постоянно эту табличку хранить. > Как бы это странно не звучало, но статика тоже может. Кеш-то не резиновый. Как процессорный, так и io. Да и так получается быстрее грузить систему с хардов или ещё чего с медленной скоростью чтения или случайного доступа. Ты замерял этот эффект? Я как-то очень сомневаюсь, что будет быстрее. Во-первых, процессорный кеш инструкций вылетает от любого чиха, и надеятся на то, что переключение процессов его сохранит... Лучше бы не сохраняло, потому как мы знаем о том к каким дырам в процессорах оно приводит. А значит возможность шарить код между процессами -- это антифича. Во-вторых, дисковый кеш, по-моим наблюдениям, вылетает не из-за кода, а из-за данных. Данных на порядки больше кода, и тормоза там лезут именно из-за данных, которые надо читать с диска. Мне приходилось неоднократно сталкиваться с исследованиями о том, как необходимость взаимодействия с жёстким диском для чтения данных приводит к тормозам. Разного уровня исследованиями, начиная от "гляньте чуваки, у меня программа тормозила, но я тут алгоритм поменял, чтобы он читал в другом порядке, и хоп, она стала тормозить в разы меньше", и заканчивая почти уровнем научной статьи, где использовались различные способы измерений (один подтверждает/опровергает другой), проверялись альтернативные гипотезы, где человек шёл на очень серьёзные меры, чтобы показать, что тормоза возникают именно таким образом, каким он говорит. Мне попадались такие исследования про данные, но я не видел ни одного исследования, которое показывало бы превосходство динамической линковки над статической по скорости выполнения. Я отмечу, что я не искал специально, может они и есть такие? Но вот тут как раз у меня и возникает вопрос: что ты знаешь, и почему ты думаешь, что ты это знаешь? Тебе известны такие исследования? Сейчас будет очень кстати поделиться ссылками на них. Потому как я в этом месте склонен делать вывод, что отсутствие свидетельств -- это свидетельство отсутствия: если проблему никто не подтвердил измерениями, значит проблемы нет. >> это можно было сделать статически, причём даже лучше сделать: lto, pgo, > Это про оптимизацию. Зубилом хлеб не режут, ножём не делают статуи. Да, это про оптимизацию. Статический линкер может её выполнять, динамический -- нет. Я не знаю, называешь ли ты его зубилом здесь или ножом, и я не очень понимаю, что ты хочешь сказать этой метафорой, но факт в том, что динамический линкер не может в оптимизации. > Тут немного про другое. Тут про черезмерное использование динамичечкой линковки. И да, со статикой модет работать быстрее. Но это не повод запрещать динамику. А раст не запрещает динамику. Тебе никто не мешает объявлять extern-символы. Единственное что, есть ограничения на то, что может быть extern. Параметризованную функцию, например, ты не сделаешь extern. В целом, в rust'е, ты можешь создавать API для динамических библиотек, и использовать эти API, но эти API будут выглядеть так, как выглядят API C.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #116

116. Сообщение от uis (ok), 13-Май-21, 23:45	+/–
> pic код, как я понимаю, использует глобальную табличку оффсетов, и этот call > становится косвенным вызовом, и требует дополнительного обращения к памяти. То есть, > во-первых, ту табличку надо заполнить на этапе динамической линковки. Во-вторых, при > _каждом_ вызове printf будет дополнительная стоимость для процессора -- обращение к > глобальной табличке оффсетов, таким образом процессорный кеш, внезапно, вынужден постоянно > эту табличку хранить. Если надо несколько раз вызвать одну и ту же функцию, то можно хранить её адрес в регистре. +PIC - это ASLR. > Ты замерял этот эффект? Я как-то очень сомневаюсь, что будет быстрее. Во-первых, > процессорный кеш инструкций вылетает от любого чиха, и надеятся на то, > что переключение процессов его сохранит... Лучше бы не сохраняло, потому как > мы знаем о том к каким дырам в процессорах оно приводит. > А значит возможность шарить код между процессами -- это антифича. Это делают разные кеши. Кэш инструкций реализован аппаратно, а кеш страниц ВНЕЗАПНО через MMU. Ну и без него придётся для каждого процесса выделять кучу реального пространства. > но я не видел ни одного исследования, которое показывало > бы превосходство динамической линковки над статической по скорости выполнения. Я такого не заявлял. Я наоборот, говорил, что статика быстрее. >И да, со статикой модет работать быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

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

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