The OpenNET Project / Index page

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



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

"В ночных сборках Rust расширены возможности распараллеливания компиляции"  +/
Сообщение от opennews (??), 11-Ноя-23, 23:05 
Во фронтэнде компилятора Rust, выполняющем такие задачи, как синтаксический анализ, проверка типов и анализ заимствований, реализована поддержка параллельного выполнения, позволяющего существенно сократить время компиляции. Распараллеливание уже доступно в ночных сборках Rust и включается при помощи опции "-Z threads=8". В стабильную ветку рассматриваемую возможность планируют включить в 2024 году...

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

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

Оглавление

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

1. Сообщение от Аноним (1), 11-Ноя-23, 23:05   +/
это получается я смогу быстрее компилять фаерфокс?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

2. Сообщение от Аноним (2), 11-Ноя-23, 23:07   –1 +/
Ну а как вы хотели?
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Аноним (6), 11-Ноя-23, 23:08   +/
Остаётся этот самый бекэнд на Раст переписать. Зиг по слухам уже слезает с ллвмной иглы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #39

5. Сообщение от Павел Отредиез (ok), 11-Ноя-23, 23:09   +/
:) надо быстрее в своп ложиться...
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 11-Ноя-23, 23:12   +1 +/
Там у огнелисы лишь небольшие куски на расте, поэтому даже медленнее получиться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7, #14

7. Сообщение от worldmind (?), 11-Ноя-23, 23:21   +2 +/
Стоит запустить cloc перед тем как комментировать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #67

8. Сообщение от Аноним (8), 11-Ноя-23, 23:21   +/
>Кроме того, потребление памяти в многопоточном режиме может значительно возрастать, например, в тестах наблюдался рост потребления памяти до 35%.

Возрастать по сравнению с многопроцессностью? Не верю.

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

11. Сообщение от Аноним (11), 11-Ноя-23, 23:35   +2 +/
Совсем не по слухам, давно стоит чёткая цель

https://github.com/ziglang/zig/issues/16270

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

14. Сообщение от НяшМяш (ok), 12-Ноя-23, 00:10   –6 +/
Санта-Барбара "онаним газифицирует лужу" серия 1337
https://openhub.net/p/firefox/analyses/latest/languages_summary
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #18, #20, #41, #65

15. Сообщение от Tron is Whistling (?), 12-Ноя-23, 00:10   +1 +/
Вполне может. Если там насовали лок на каждый указатель и используются обильные мелкие структуры - 35% - это ещё не предел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

17. Сообщение от Аноним (17), 12-Ноя-23, 00:18   +/
Собаки лают, караван идёт...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #79

18. Сообщение от фнон (?), 12-Ноя-23, 00:39   –3 +/
ого, это получается что в следующем (возможно в 25м) году Раст обгонит Сишку
Неплохо, весьма неплохо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #76

20. Сообщение от Алкоголизм (?), 12-Ноя-23, 01:01   –3 +/
Б-же, 4 ляма строк на HTML, даже больше, чем на С. И после этого некоторые продолжают утверждать, что HTML не язык программирования, а я не могу являться сертифицированным HTML-программистом.

А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

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

21. Сообщение от Аноним (21), 12-Ноя-23, 01:02   +1 +/
Собаки распараллеливают - караван идет

8 потоков и на 50% быстрее. Каждый поток добавляет 6%... Питон, вроде, "параллельнее" будет.

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

23. Сообщение от Павел Отредиез (ok), 12-Ноя-23, 01:26   +1 +/
Они ещё не познали всю силу фрагментирующего дефрагментатора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #24

24. Сообщение от Павел Отредиез (ok), 12-Ноя-23, 01:45   +/
У меня и козырь припасён. А как насчёт дефрагментирующего фрагментатора?

Всё братья, простите грешника, спаааать!

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

25. Сообщение от Аноним (25), 12-Ноя-23, 02:36   +5 +/
«Вы говорите что HTML невозможно программировать. По-моему вы просто жутко наелись конфет…» — Денис Попов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

27. Сообщение от Аноним (27), 12-Ноя-23, 03:04   +1 +/
Лучше бы сборку из GCC завезли.  Go можно собрать из GCC, а сабж - нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #44

31. Сообщение от morphe (?), 12-Ноя-23, 05:16   +/
Многопроцессность не отменяется, как и раньше каждый крейт компилируется в отдельном процессе, однако теперь каждый из этих процессов может использовать несколько потоков при компиляции (При кодогенерации оно и так использовало многопоточность llvm)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #43

32. Сообщение от Аноним (32), 12-Ноя-23, 05:25   +/
Не переживайте. Люди этим занимаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

33. Сообщение от вымя (?), 12-Ноя-23, 05:28   +/
> А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

Да. XUL мёртв, но подходы его живы.

Хотя я уверен, что до половины от этого занимает монструозный about:newtab с нескучными списками самых посещаемых сайтов на react.js.

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

34. Сообщение от Смузихлёб (ok), 12-Ноя-23, 06:52   –2 +/
> Весь интерфейс лисы описан на html/js?

Было бы прекрасно, если все интерфейсы писались на стеке html/css/js.

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

35. Сообщение от Аноним (35), 12-Ноя-23, 07:27   +/
сборка больших проектов и так задействует все ядра, так как производится в несколько процессов. А для небольших проектов время компиляции - явно не бутылочное горлышко.

Если кто еще не понял, для чего это все делается, то - чтобы ускорить искусственные хелловорлды, впечатлить CEO, добавить круто выглядящие строчки в резюме и освоить деньги спонсоров. Собственно, весь раст как язык был изначально создан с такими целями.

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

39. Сообщение от фнон (?), 12-Ноя-23, 08:55   +/
Не очень понятно 'зачем'?
Т.е можно потратить N сотен человеко-часов, а можно за это время и силы добавить какие-то полезные конструкции в язык или оптимизировать быстродействие.

Даже в упомянутом тикете Зиг мотивация довольно размытая:
- All our bugs are belong to us.
Ну так вам их все и чинить придется) А над ЛЛВМ работает еще куча людей.

- The Zig compiler binary goes from about 150 MiB to 5 MiB.
Думаю речь про дебажные билды, да и 150 не такое большое число.

- We can implement our own optimization passes that push the state of the art of computing forward.
Спасибо, мы уже насмотрелись на оптимизации в С/С++

- We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs.
'Мы просто хотим чемодан денег от Интел?' - а вот это уже достойная цель!

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

40. Сообщение от glad_valakas (?), 12-Ноя-23, 09:50   +2 +/
а в дневных билдах хрома и фаерфокса распараллелено уже все что можно.
только жрать меньше они не стали.
еще раз для непонятливых: ловкая утилизация системных ресурсов не является оптимизацией производительности.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Axel (??), 12-Ноя-23, 10:10   +2 +/
Зачем там BrainFuck?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #61, #66

42. Сообщение от Советский инженер (ok), 12-Ноя-23, 10:16   +1 +/
судя по тикету, они не хотят зависеть от LLVM-ных библиотек.
но это не мешает им использовать бинарники LLVM
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

43. Сообщение от Аноним (43), 12-Ноя-23, 10:18   –1 +/
Надеюсь, додумаются всё в 1 процесс засунуть и параллелить только одними потоками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #69

44. Сообщение от Аноним (43), 12-Ноя-23, 10:20   +/
go-gcc не собирает многие приложения. А м6огие собранные - крашатся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #45

45. Сообщение от Аноним (85), 12-Ноя-23, 10:28   +2 +/
Учитывая, что на расте ничего не написано, то хватит и сборки немногого. Главное, что не придётся тащить этот мерзкий тулчейн (а шланг и вовсе компилируется вечность).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #48

46. Сообщение от ИмяХ (ok), 12-Ноя-23, 10:47   –2 +/
Но, погодите-ка, ведь раст изначально разрабатывался с поддержкой многопоточности "из коробки", как так получается, что многопоточная компиляция появляется только сейчас, спустя 15 лет с начала его разработки?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #50, #96

47. Сообщение от фнон (?), 12-Ноя-23, 11:06   +1 +/
Ты не путай многопоточное исполнение и компиляцию
Компилятор может вообще быть на совершенно другом языке (и потом быть переписан на свой же язык, но не всегда)
Раст начинал с окалма, ГнуСИ с волосатого паскаля.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #58

48. Сообщение от Советский инженер (ok), 12-Ноя-23, 11:52   –1 +/
>расте ничего не написано
>не придётся тащить этот мерзкий тулчейн

так если ничего не написано, то зачем таскаешь?
мазохист?

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

50. Сообщение от Аноним (55), 12-Ноя-23, 12:04   +2 +/
> Но, погодите-ка, ведь раст изначально разрабатывался с поддержкой многопоточности "из
> коробки", как так получается, что многопоточная компиляция появляется только сейчас,

А зачем "домохозяки", очевидно считающие что можно было просто сделать "запусти_много_потоков(синтактический_анализ_сорса)" интересуются?


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

51. Сообщение от Аноним (85), 12-Ноя-23, 12:11   +1 +/
Firefox, pyca/cryptography, librsvg. Ни одной другой причины нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

52. Сообщение от Terminator_T1000_РоботСлизь (?), 12-Ноя-23, 12:30   +3 +/
Цель скорее имиджевая. Раст декларируется как замена дырявым Си/Си++, а под копотом втихаря у себя юзает "ллвмное сишное поделие". Более того, Раст не гнушается пользоваться сишной либси в недрах своей стдлибы. Не к лицу, какие-то "двойные стандарты". Попахивает ханжеством и лицемерием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #53, #55

53. Сообщение от фнон (?), 12-Ноя-23, 12:56   +4 +/
Извини, но твое сообщение выглядит как набор пафосных штампов.

Никто втихаря ничего не юзает - о том что раст собирается ллвм'ом могут не знать только домохозяйки (и то не все)) - любой человек которые решил его установить, прочтет документацию.
По поводу либСИ - уже были попытки переписать (steed), думаю к этому еще вернутся.

В любом случае добавление раст-кода к си-коду уже делает код лучше (хотя бы будет меньше use-after-free).

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

54. Сообщение от Аноним (54), 12-Ноя-23, 13:00   +/
> Не очень понятно 'зачем'?

зачем независимость ? внезапно чтобы не зависеть от прихотей левой пятки трансгендера

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

55. Сообщение от Аноним (55), 12-Ноя-23, 13:58   +/
> Более того, Раст не гнушается пользоваться сишной либси в недрах своей стдлибы. Не к лицу, какие-то "двойные стандарты". Попахивает ханжеством и лицемерием.

Но двойные они только у опеннетных Военов Супротив Раста, сидящих тут с вендочки или мака и не знающих про штатный интерфейс взаимодейстия с *nix-ядрами ...



System calls and library wrapper functions
       System calls are generally not invoked directly, but rather via
       wrapper functions in glibc (or perhaps some other library).
...
Architecture-specific requirements
       Each architecture ABI has its own requirements on how system call
       arguments are passed to the kernel.  For system calls that have a
       glibc wrapper (e.g., most system calls), glibc handles the
       details of copying arguments to the right registers in a manner
       suitable for the architecture.

вон, на редоксе прекрасно обходятся без сишной либц (и даже предоставляют либц на расте для запуска сишко-софта).
Впрочем, Военам это ведь не помеха - как только появится "своя" версия, на расте, Воены хором начнут декларировать вторую часть своего Эпоса: "Опять NIH! Опять лишь переписали! Опять тянут в систему что-то свое, вместо использования уже готового системного!"  


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

58. Сообщение от Аноним (58), 12-Ноя-23, 14:57   +1 +/
А он и не путает. Он спрашивает, как так получилось, что сами сапожники остались без сапог.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #59, #97

59. Сообщение от фнон (?), 12-Ноя-23, 15:04   +/
А они собирались делать себе сапоги? Или сам придумал)?
Насколько я помню историю то выбор ллвм был почти сразу.
Это отличный способ получить кучу профита из коробки и не придумывать велосипеды без сильной необходимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

60. Сообщение от янонимус (?), 12-Ноя-23, 15:56   +3 +/
А он не может написать хороший код?
Может ты не сможешь им пользоваться? Как это у вас называется, "зашкварно"?
Или скрепы разогнуться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #64, #77

61. Сообщение от фнон (?), 12-Ноя-23, 15:59   +/
Чтоб тебе стало инетресно и ты сломал мозг))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

63. Сообщение от Аноним (67), 12-Ноя-23, 16:07   +/
А где конкретные цифры по проектам? Ну к примеру насколько сам компилятор стал быстрее собираться? Что это маркетинговые байки
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70

64. Сообщение от Аноним (64), 12-Ноя-23, 17:41   +/
> А он не может написать хороший код ?

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

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

65. Сообщение от Аноним (67), 12-Ноя-23, 17:54   +/
11% - это много? Потом идет python, будет говорить что ff на питоне? Или ты сразу встал в защитную позу из-за того, что кто-то сказал что тебе не нравится?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #78

66. Сообщение от Аноним (67), 12-Ноя-23, 17:55   +/
Очевидно это некорректные данные от систем, которые определяют тип файла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

67. Сообщение от Аноним (67), 12-Ноя-23, 17:56   +/
Ты запустил сам-то? Какие результаты? ff на с++ и js написан - шах и мат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

68. Сообщение от Аноним (67), 12-Ноя-23, 17:59   +/
> А если серьёзно, откуда так много? Весь интерфейс лисы описан на html/js?

Не только интерфейс, но и многая внутренняя логика. Чего удивительного? Ты посмотри сколько занимает в процентном соотношении код на lua или vimscript в neovim, или код на elisp в emacs.

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

69. Сообщение от morphe (?), 12-Ноя-23, 19:31   +/
> Надеюсь, додумаются всё в 1 процесс засунуть и параллелить только одними потоками.

А какой смысл?

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

70. Сообщение от фнон (?), 12-Ноя-23, 19:50   +1 +/
Если перейти по ссылке в статье в блог - то там можно найти ссыль на гитхаб
https://github.com/rust-lang/compiler-team/issues/681
там есть примеры изменения времени компиляции разных либ (напр Serde, hyper, regex и тд)

Спойлер: ускорилось от 11 до 47%, в среднем 30%
Under 8 cores and 8 threads, the parallel front end can reduce the clean build (cargo build with -Z threads=8 option) time by about 30% on average.

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

72. Сообщение от Аноним (72), 13-Ноя-23, 01:08   +/
Ну что ты как маленький? Чтобы потребители Коры Дуба™ были счастливы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

73. Сообщение от Аноним (76), 13-Ноя-23, 07:12   –1 +/
"для очень маленьких программ, которые и так компилируются быстро, компиляция в многопоточном режиме может выполняться медленнее" - то есть общая скорость компиляции хелоуворлдов растишек в итоге только уменьшилась.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #90, #98

74. Сообщение от Аноним (76), 13-Ноя-23, 07:17   +1 +/
Эффективным менеджерам не нужен быстрый и эффективный язык, им нужно нечто с помощью чего можно бесконечно доить проект переписываниями и фиксами. Вот они и проталкивают Раст, специально спроектированный для этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

75. Сообщение от Аноним (76), 13-Ноя-23, 07:20   +2 +/
Добавление раст-кода к си-коду делает только необходимым поддерживать два языка вместо одного. Никакой код лучше от Раста автоматически не становится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #85

76. Сообщение от Аноним (76), 13-Ноя-23, 07:24   +1 +/
Последние пару лет Раст и Сишка соревновались только в том кого из них первым выкинут из проекта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

77. Сообщение от Аноним (76), 13-Ноя-23, 07:27   –1 +/
Так эти трансгендеры код не пишут, они максимум на маркдауне в CoC контрибутят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

78. Сообщение от Аноним (76), 13-Ноя-23, 07:33   +/
Учитывая, что код на Python форматирован без скобок и в целом более компактный и высокоуровневый, можно смело говорить, что Firefox скорее написан на Python, чем на Rust. Не говоря уже о Javascript.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

79. Сообщение от Аноним (76), 13-Ноя-23, 07:38   +/
Собаки лают, а все как писали на Си и С++, так и пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

80. Сообщение от Аноним (76), 13-Ноя-23, 07:47   +/
Чтобы весь тулчейн Zig был написан на компактном и быстром Zig и не тянул за собой тонны легаси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #82

82. Сообщение от Советский инженер (ok), 13-Ноя-23, 09:46   +/
а может Zig такой компактный и быстрый как раз за счет использования LLVM?
такие простые мысли тебя не посещали?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

84. Сообщение от Серб (ok), 13-Ноя-23, 13:40   +/
Совсем евангилисты раста обленились?

Где тут сказано, что штатный интерфейс?

Где тут сказано что никто не может сделать библиотеку для работы с системными вызовами?

Бери, делай, работай. Поддерживать придется самому - это да.
И код поддержки разных архитектур и ядер придется писать самому - это то же да.


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

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

85. Сообщение от Аноним (85), 13-Ноя-23, 13:57   +/
Можно утверждать с полной уверенностью, что становится хуже. Потому что ломается линковка, появляется зависимость от шланга и его стека (в том числе, от плюсовых либ), во многих случаях появляются случайные труднодиагностируемые зависания (и особенно это касается менее популярных платформ). Так что, если видишь растофанатика, смело плюй ему в лицо, он глупый и хочет тебе навредить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #92

86. Сообщение от Аноним (55), 13-Ноя-23, 16:31   +/
> Где тут сказано что никто не может сделать библиотеку для работы с
> системными вызовами?

Совсем Воены овоенились - сами опять что-то придумали, сами оспорили.

> Бери, делай, работай. Поддерживать придется самому - это да.
> И код поддержки разных архитектур и ядер придется писать самому - это то же да.

И слушать скандирования местных Военов "опять NIH! Опять тянут в систему что-то свое, вместо использования уже готового системного!"  - тоже да.

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

// This function is only included when compiling for a unixish OS with a 32-bit
// architecture
#[cfg(all(unix, target_pointer_width = "32"))]
fn on_32bit_unix() {
  // ...
}


Опять у Военов фантазия разыгралась ...


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

87. Сообщение от Серб (ok), 13-Ноя-23, 16:48   +/
А теперь дай пример кода, где функции на разных архитектурах в качестве параметров принимают разные структуры. И как реализуется работа с двумя разными структурами двух разных архитектур одним кодом...

Очень будем посмотреть!

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

88. Сообщение от Аноним (55), 13-Ноя-23, 17:32   +/
> А теперь дай пример кода, где функции на разных архитектурах в качестве
> параметров принимают разные структуры. И как реализуется работа с двумя разными
> структурами двух разных архитектур одним кодом...
> Очень будем посмотреть!

https://github.com/jasonwhite/syscalls/tree/main/src


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

89. Сообщение от Серб (ok), 13-Ноя-23, 18:01   +/
Чутку глянул!

Это вот прям сахарок:

https://github.com/jasonwhite/syscalls/blob/main/src/args.rs

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

90. Сообщение от нах. (?), 13-Ноя-23, 18:10   –1 +/
Не переживай за них так. На самом деле скорость компиляции не изменилась, потому что определяется скоростью скачивания миллиона крейтов от которых зависит их хеловрот.

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

91. Сообщение от Серб (ok), 13-Ноя-23, 18:16   –1 +/
>> А теперь дай пример кода, где функции на разных архитектурах в качестве
>> параметров принимают разные структуры. И как реализуется работа с двумя разными
>> структурами двух разных архитектур одним кодом...
>> Очень будем посмотреть!
> https://github.com/jasonwhite/syscalls/tree/main/src

Так где там разные структуры?
Вызов системного вызова по номеру и передача параметров им. Без интерпретации содержимого.

Где сами системные вызовы разные на разных платформах?

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

92. Сообщение от Советский инженер (ok), 13-Ноя-23, 18:52   +/
пойди это librsvg расскажи.
все вы такие умеые и умелые в комментах языком чесать. а вот когда касается дела - то пшик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

93. Сообщение от Аноним (55), 13-Ноя-23, 20:49   +/
> Так где там разные структуры?

Папа, где море? (c)

> Вызов системного вызова по номеру и передача параметров им. Без интерпретации содержимого.

Сам что-то придумал, сам потребовал опровергнуть ... истинный Воен!

> Где сами системные вызовы разные на разных платформах?


pub unsafe fn syscall2(n: Sysno, arg1: usize, arg2: usize) -> usize {
    let mut ret: usize;
    asm!(
        "syscall",
        inlateout("rax") n as usize => ret,
        in("rdi") arg1,
        in("rsi") arg2,
        out("rcx") _, // rcx is used to store old rip
        out("r11") _, // r11 is used to store old rflags
        options(nostack, preserves_flags)
    );
    ret
}
...
pub unsafe fn syscall2(n: Sysno, arg1: usize, arg2: usize) -> usize {
    let mut ret: usize;
    asm!(
        "svc 0",
        in("r7") n as usize,
        inlateout("r0") arg1 => ret,
        in("r1") arg2,
        options(nostack, preserves_flags)
    );
    ret
}
...
pub unsafe fn syscall2(n: Sysno, arg1: usize, arg2: usize) -> usize {
    let mut ret: usize;
    asm!(
        "ecall",
        in("a7") n as usize,
        inlateout("a0") arg1 => ret,
        in("a1") arg2,
        options(nostack, preserves_flags)
    );
    ret
}
...
pub unsafe fn syscall2(n: Sysno, arg1: usize, arg2: usize) -> usize {
    let mut err: usize;
    let mut ret: usize;
    asm!(
        "syscall",
        inlateout("$2") n as usize => ret,
        lateout("$7") err,
        in("$4") arg1,
        in("$5") arg2,
        // All temporary registers are always clobbered
        lateout("$8") _,
        lateout("$9") _,
        lateout("$10") _,
        lateout("$11") _,
        lateout("$12") _,
        lateout("$13") _,
        lateout("$14") _,
        lateout("$15") _,
        lateout("$24") _,
        lateout("$25") _,
        options(nostack, preserves_flags)
    );
    if err == 0 {
        ret
    } else {
        ret.wrapping_neg()
    }
}


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

94. Сообщение от Аноним (94), 13-Ноя-23, 21:16   +/
Забавно. Так где разные структуры то? Где один код обрабатывающий разные структуры?

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

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

95. Сообщение от Аноним (55), 13-Ноя-23, 21:53   +/
> Забавно. Так где разные структуры то? Где один код обрабатывающий разные структуры?

Забавно, пошли очередные "это не считаица, это тоже, а покажи мне диво-дивное, чудо-чудное ..."
В реализацию stdlib смотреть не пробовали?
https://doc.rust-lang.org/src/std/fs.rs.html#362-364


pub fn open<P: AsRef<Path>>(&self, path: P) -> io::Result<File> {
        self._open(path.as_ref())
    }

    fn _open(&self, path: &Path) -> io::Result<File> {
        fs_imp::File::open(path, &self.0).map(|inner| File { inner })
    }


Правда, совсем не обязательно делать удаление гланд автогеном через одно место:


pub fn open<P: AsRef<Path>>(path: P) -> io::Result<File> {
        OpenOptions::new().read(true).open(path.as_ref())
    }

Там ведь под капотом не только лишь "вызовы нашей либц!"


impl File {
    pub fn open(path: &Path, opts: &OpenOptions) -> io::Result<File> {
        let path = maybe_verbatim(path)?;
        let handle = unsafe {
            c::CreateFileW(
                path.as_ptr(),
                opts.get_access_mode()?,
                opts.share_mode,
                opts.security_attributes,
                opts.get_creation_mode()?,
                opts.get_flags_and_attributes(),
                ptr::null_mut(),
            )
        };

...
impl File {
    pub fn open(path: &Path, opts: &OpenOptions) -> io::Result<File> {
        run_path_with_cstr(path, |path| File::open_c(path, opts))
    }

    pub fn open_c(path: &CStr, opts: &OpenOptions) -> io::Result<File> {
        let flags = libc::O_CLOEXEC

...

#[cfg(any(
        target_os = "macos",
        target_os = "ios",
        target_os = "watchos",
        target_os = "linux",
        target_os = "emscripten",
        target_os = "android",
        target_os = "solaris",
        target_os = "illumos",
        target_os = "haiku",
        target_os = "l4re",
        target_os = "fuchsia",
        target_os = "redox",
        target_os = "vxworks",
        target_os = "espidf",
        target_os = "horizon",
        target_os = "vita",
        target_os = "nto",
    ))]
    pub fn ino(&self) -> u64 {
        self.entry.d_ino as u64
    }

    #[cfg(any(
        target_os = "freebsd",
        target_os = "openbsd",
        target_os = "netbsd",
        target_os = "dragonfly"
    ))]
    pub fn ino(&self) -> u64 {
        self.entry.d_fileno as u64
    }


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

96. Сообщение от burjui (ok), 13-Ноя-23, 22:57   +/
Параллельная компиляция в rustc есть уже давно (этап генерации кода), просто сейчас дело дошло до распараллеливания фронтенда. Очевидно, проблемы решаются по мере возникновения и по важности. А как с параллельной компиляцией обстоят дела у других компиляторов, позвольте узнать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

97. Сообщение от burjui (ok), 13-Ноя-23, 22:59   +/
Интересен другой вопрос: а как так получилось, что лучшие разработчики на планете собрались на этом ресурсе и разучились читать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

98. Сообщение от burjui (ok), 13-Ноя-23, 23:03   +/
На целых 2%. Возможно, ты слышал о таком понятии, как "компромисс". Это такая штука, которую приходится реализовывать примерно в 95% решаемых задач в реальном мире.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

99. Сообщение от Аноним (99), 14-Ноя-23, 11:22   +/
> Забавно, пошли очередные "это не считаица

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

Где хот отдаленно похожее на это:

https://codebrowser.dev/glibc/glibc/libio/iofopen.c.html

Не говоря уже об этом:

https://codebrowser.dev/glibc/glibc/nss/getXXbyYY.c.html

Вот просто такое:

#ifdef _IO_MTSAFE_IO
  new_f->fp.file._lock = &new_f->lock;
#endif

?

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

100. Сообщение от Аноним (55), 14-Ноя-23, 22:26   +/
>> Забавно, пошли очередные "это не считаица
> Изначально речь и шла про невозможность одним кодом разные структуры обрабатывать. Что
> ты из раза в раз и подтверждаешь примерами,

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

Вызов WinAPI на венде - дублирование open на nix, так и запишемю

> Где хот отдаленно похожее на это:
> https://codebrowser.dev/glibc/glibc/libio/iofopen.c.html
> Не говоря уже об этом:
> https://codebrowser.dev/glibc/glibc/nss/getXXbyYY.c.html

Какой "отличный" пример "кросплатформы" - линух-онли либа.

> Вот просто такое:
>

 
> #ifdef _IO_MTSAFE_IO
>   new_f->fp.file._lock = &new_f->lock;
> #endif
>


#[cfg(any(
        target_os = "freebsd",
        target_os = "openbsd",
        target_os = "netbsd",
        target_os = "dragonfly"
    ))]
    pub fn ino(&self) -> u64 {
        self.entry.d_fileno as u64
    }

"Папа, где море?"(с)


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

101. Сообщение от Аноним (99), 15-Ноя-23, 02:31   +/
Опять. Вот опять приводишь пример в котором полный вызов функции.

И? Опять показал проблемы раста.

В очередной раз показывая на .вно говоришь, что это съедобно.

Вот реально сказочный Ваня или просто изображаешь?

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


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

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




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

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