LINUX.ORG.RU
ФорумTalks

Расчёт зависимостей ebuild-ов на GPU

 , ,


2

2

Говорят, что нет большой разницы между paludis и portage по производительности, потому что алгоритмическая сложность задачи высока сама-по-себе, и переход с питона на C++ почти ничего не даёт.

Знаачит, надо переходить с CPU на GPU. Там много процессоров, вот пусть они зависимости и считают.

Интересные ссылки из связанных топиков:
2017-08-18, Реклама https://github.com/gunrock/gunrock
2015-09-25, где алгоритм? - где-то там
2014-10-28, Оценка влияния количества ebuild-ов в дереве на скорость выполнения emerge
2013-11-09, Идея считать на GPU
2013-07-05, про визуализацию зависимостей
2013-02-28, в squashfs запаковать или в базу sqlite, eix

Если бы не расчёт зависимостей у портежа, гента была бы самым фичастым и стабильным дистрибутивом.

- (q) vurdalak

Тут не смогли сделать расчет зависимостей в многопотоке, а ты уже толкаешь офигительную идею о ГПУ.

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

А можно URL на то место, где не смогли сделать? А то «тут» это обобщающее местоимение и мне не ясно - где именно. Спасибо,

Einstok_Fair ★★☆ ()

Зачем ты так много понаписал? Ты мог сразу написать: «Я думаю, что GPU это процессор общего назначения потому, что я нифига не знаю. Мне плевать на специалистов - вы должны слушать меня.».

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

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

что такое GPU и как вообще там происходят вычисления

GPU это большое количество (пара тысяч штук на современных 10-ти терафлопсных картах) относительно медленных процессоров (вполне себе способных на вычисления общего назначения). Закачиваем всё дерево в видеопамять (по-любому это быстрее, чем читать его с диска). Запускаем вычисления, получаем результат.

Einstok_Fair ★★☆ ()

Пользуясь случаем, спрошу, т.к. тема меня давно интересует. Что вообще читать\куда вникать, чтобы можно было попробовать приложить руку к ускорению просчёта зависимостей? Что такого сложного в алгоритме работы portage, что он делает это дольше, чем большинство других пакетных менеджеров? Неужели USE-флаги, опции сборки и слоты добавляют столько оверхеда? Ведь в любом другом формате пакетов тоже есть описание зависимостей, и любой другой пакетный менеджер должен их удовлетворить.
Интуитивно я догадываюсь, что задача сводится к построению графа с кучей связей, но необходимых теоретических знаний, да и практических навыков, нет, поэтому буду благодарен за ссылки на полезные ресурсы\рекомендации литературы.

Nirvandil ()

гента была бы самым фичастым

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

ozz_is_here ()

Мне не очень понятно, в чём смысл ускорять portage если всё равно львиная часть времени уходит не на расчёт зависимостей, а на компиляцию и линковку.

tim239 ()
Ответ на: комментарий от Suigintou

как же тогда USE и остальные фичи портежа?

Ты умный, и придумаешь что-нибудь. Например создашь комплект профилей и к каждому профилю сделаешь свой бинарный репозиторий.

Не проще и быстрее ли тогда deb с arch?

Не знаю, изучать их всё равно сил нет.

Einstok_Fair ★★☆ ()
Последнее исправление: Einstok_Fair (всего исправлений: 1)
Ответ на: комментарий от Einstok_Fair

А флудить, значит, не лапки? Иди работай. Идеи он тут выдвигать вздумал.

Идей у всех полно. Только времени на их реализацию не хватает.

i-rinat ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Например создашь комплект профилей и к каждому профилю сделаешь свой бинарный репозиторий.

И ферму для компиляции под каждую слабую машинку поднять, ага.
Тут или USE, или pacman -Syu. Среднего не дано.

Suigintou ★★★★ ()
Ответ на: комментарий от Einstok_Fair

(вполне себе способных на вычисления общего назначения)

Нет.

(по-любому это быстрее, чем читать его с диска).

Нет.

Запускаем вычисления, получаем результат.

Рановато.

Итог: ты не понял ничего.

Quasar ★★★★★ ()
Ответ на: комментарий от Nirvandil

Интуитивно я догадываюсь, что задача сводится к построению графа с кучей связей

Вот только этот граф будет не настолько большим чтобы его имело смысл грузить в GPU. Итого вычисления будут идти медленнее. Проверено на LibreOffice.

Quasar ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Ты умный, и придумаешь что-нибудь.

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

Quasar ★★★★★ ()
Ответ на: комментарий от goingUp

Да, я читал об этом.

Я думал, что ты где-то видел попытку реализовать многопоточный расчёт и там могли бы быть выписаны причины, почему это не удалось

Einstok_Fair ★★☆ ()
Последнее исправление: Einstok_Fair (всего исправлений: 1)

Говорят, что нет большой разницы между paludis и portage по производительности

Серьезно? Пропасть по производительности между нативным кодом и питоном огромная. Неужели paludis ничуть не быстрее?

kawaii_neko ★★★★ ()
Ответ на: комментарий от kawaii_neko

Серьезно?

Сам не проверял, читал в интернете. Верю им на слово.

Einstok_Fair ★★☆ ()
Ответ на: комментарий от kawaii_neko

Визуально разница околонулевая, причём как на Gentoo, так и на Exherbo.

Nirvandil ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.