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 (linux.org.ru)

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

- (q) (linux.org.ru) vurdalak

★★☆

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

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

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 ★
()
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.