LLVM 3.0

Я атлетично сложен, не наговаривай на меня.

Так я про мозг

Ну дропнет, ну и что:)

Как говорит нам К.О.: «Цель разработки софта не в том, что бы в нем учитывались все возможные оптимизации, а в том чтобы получить правильно работающую программу с заданным списком функций.»

А те оптимизации, о которых Вы говорите возможны вероятно только в <1% программ, и оптимизируют там общую скорость на <0.001%. И если кому-то это так критично, то таки да LLVM не для него (никто ж Вам не запрещает использовать HEX редактор кода, например). Но если у кого-то аллергия на воду, это что ж всем из-за этого в бассейн не ходить...

только помни, что в случае с С++-библиотеками, не так все гладко.

Говорят что каждый программист должен написать свою игру, ОС и компилятор =)

Вы бы все-таки почитали документацию (это не только лично к Вам, но и к другим присутствующим в данный момент). inline подстановка функция там есть и была с самого начала еще на уровне LLVM . Как, например, еще и разворот рекурсии и многое другое. Тут нет именного того, о чем говорил один товарищ любящий работать со структурой, как с набором бит.

Я не знаю, я вообще не люблю LLVM, говорю на основе утверждений любителей :)

Жаль, что проигрывал по тестам. Это может подстегнуло бы новый виток инноваций в этой области.

Вы бы все-таки почитали документацию

Извините, разве я что-то не так написал? Ответил человеку на вопрос какие оптимизации может произвести компилятор не зная целевой платформы. Разве я говорил что их нет в LLVM? Дык вроде наоборот =)

Говорят что каждый программист должен написать свою игру, ОС и компилятор =)

Блин. Я не программист. Я только хотел ОС на java писать :)

Вы бы все-таки почитали документацию

Было бы время. А так мы рассуждаем на уровне логики (пытаемся)

Жаль, что проигрывал по тестам. Это может подстегнуло бы новый виток инноваций в этой области.

Года 4 назад, до того как apple пролила водопад инвестиций, он катастрофически отставал и по скорости и по скорости развития.

собственно, SSA или CPS там решается до построения IR

Ассемблер LLVM — это и есть некие инструкции, записанные в форме SSA. Он может быть уже соптимизирован или оставлен как есть, но bytecode — это SSA и машинный код получается из него же. IR, кстати, это «intermediate representation» — байткод LLVM, из которого и генерируется машинный код с использованием архитектурно-специфичных низкоуровневых оптимизаторов.

ну это и ежику понятно :)

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

Читая Ваш комментарий отвлекся на работу, решил что это был сарказм. Пардон :)

Жаль, что проигрывал по тестам. Это может подстегнуло бы новый виток инноваций в этой области.

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

внеклассное чтение: click

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

Не видел...

Ассемблер LLVM — это и есть некие инструкции, записанные в форме SSA

так, под SSA понимается Static Single Assignment? если - да, то Ваша фраза некорректна

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

Не видел...

ну вот же, правда он llvm как раз использует :)

Я всегда считал что задача распараллеливания это задача алгоритмическая, и что у компиляторов не достаточно ума для принятия решения что можно распараллелить, а что нет. Не думаю что что-то сильно изменилось или изменится в ближайшем будущем. Хотя для студенческих задач может быть и достаточно ). Но для энтерпрайза автоматическое распарралеливание может быть опасно.

о какая штука!!!

я правда о С говорил...

так, под SSA понимается Static Single Assignment?

Да.

если - да, то Ваша фраза некорректна

Почему?

Слава богу ) все таки там программист решает что распаралелить и как ) никакого искусственного интеллекта, а то я уже испугался что безнадежно отстал от жизни )

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

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

Ну в любом случае это не исскуственный интеллект. Явно указывается

Но для энтерпрайза автоматическое распарралеливание может быть опасно.

Согласен, что бездумно отдавать это на усмотрение машины нельзя. Но в проверенных вариациях (заведомо оттестированных на целевых платформах) это должно работать нормально и в промышленных масштабах.

Почему идея достаточно проста для понимания

for(int i=0;i<N;i++)
{
a = HeavyGet(i);
HeavyProcess(a);
}

Сложно получение данных тут можно с запаралелить со сложной обработкой данных. a, еще не обработано, а процесс получения следующего a уже пошел. Но на практике нужно отследить множество связей.

Но на практике нужно отследить множество связей.

Во во. Это уже думать надо

>так, под SSA понимается Static Single Assignment?

Да.

если - да, то Ваша фраза некорректна

Почему?

потому что codegen() в узлах синтаксического дерева пишет программист, а не llvm :)

Но если, например, функции HeavyGet(i); HeavyProcess(a);

Используют только локальные переменные, то ничего случится не должно. Или же используют функции с только локальными переменными. Дальше, если есть простые данные к которым может иметь доступ и HeavyGet(i) и HeavyProcess(a), то такой доступ компилятор должен синхронизировать таким образом, чтобы HeavyGet подождала завершение HeavyProcess, если HeavyGet сейчас считает такие данные. Если есть работа со ссылками, то задача возможности запаралеливания значительно усложняется, нужно отследить все случаи как получена ссылка куда она может указывать, но тоже это решается в некоторых случаях. Правда опять же для таких задач не понятно зачем привязка к конкретной архитектуре. С другой стороны подобные задачи могут в комплексе помогать и другие проблемы, например потенциальные deadlock-и. Думаю, много чего в будущем компиляторы смогут параллель очень многое.

а ещё потому, что всякие функциональные языки на синтаксическом дереве вертели этот SSA :)

Почему идея достаточно проста для понимания

for(int i=0;i<N;i++)
{
    a = HeavyGet(i);
    HeavyProcess(a);
}

а теперь преставь что HeavyProcess() использует значение a, как у тебя и написано, и чего ты получишь распараллелив вычисление значения и его дальнейшее использование?

Попались :)

Ничего не получу при i==0. Но я же вроде ясно написал. Получили a, передали a на выполнение HeavyProcess, а сами пошли искать a для i==1 в отдельном процессе.

Пока обрабатывается a0, параллельный процесс ищет a1 (даже если еще a0 не обработано, нечто нам не мешает найти параллельно значения a2, a3 и т.п).

Для значений i==0 и i==N-1, цикл будет использовать только один процесс.

Все это конечно возможна при N>1 и если нет других зависимостей между HeavyGet(i) и HeavyProcess(a).

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

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

Все это конечно возможна при N>1 и если нет других зависимостей между HeavyGet(i) и HeavyProcess(a).

проблема в том что все подобные рассуждения опираются на 1-2, по мнению автора, очевидных случая, но, уверяю, если попробовать начать писать реализацию, то быстро начинаешь волосы на попе рвать от отчаяния

«Для значений i==0 и i==N-1» имелось ввиду как минимум один вызов HeavyGet в начале не будет запаралелен с HeavyProcess и как минимум один вызов HeavyProcess в конце не будет запараллелен с HeavyGet.

Если на выполнение HeavyGet и HeavyProcess нужно использовать примерно одинаковое количество времени, то получим практически одинаковую разгрузку ресурсов на два процесса при N>>1. Если a занимает не много места в памяти, а функция HeavyGet обрабатывается в несколько раз быстрее, то один процесс может интенсивно искать и заносить в список значения a1, a2, a3, а другой уже непрерывно выполнять HeavyProcess. И получим «поглощение» времени на обработку HeavyGet процессом обрабатывающим HeavyProcess (если что можно и более одного процесса выделить на обработку только HeavyProcess).

Ты упустил две вещи:

1. Нормальный JIT

2. Самая обычная статическая компиляция.

Ну и универсальная библиотека, позволяющая каждому Васе Пупкину писать компиляторы своих недоязыков :) (проверено на себе: удобно и сравнительно просто, значительно уменьшает количество изобретаемых велосипедов).

А clang в архитектурном плане намного продуманнее, чем gcc. Да и со скоростью компилирования у clang лучше.

Когда вспоминают python, обычно имеют в виду это: http://code.google.com/p/unladen-swallow/ (оно немного мертвое)

С PyQt у них все было нормально.

И PyPy вроде тоже LLVM.

PyPy вроде тоже LLVM.

Даже и не близко.

Так их всего и есть только 3 возможных варианта. Названный мной, и еще тоже самое но с рекурсивными вызовами. И еще линейная программа:

A(); B(); C();

Можно функции A, B и C запараллелить.

Все остальное решается программистом.

Главных проблем тут три: правильное построение зависимостей, построение правильной синхронизации доступа к общим данным и очень важное: сделать так, чтобы дополнительные функции по обработке параллельных процессов не были настолько ресурсуемкими чем конечный выигрыш во времени таки был и таки того стоил.

И PyPy вроде тоже LLVM.

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

Так их всего и есть только 3 возможных варианта. Названный мной, и еще тоже самое но с рекурсивными вызовами. И еще линейная программа:

A(); B(); C();

Можно функции A, B и C запараллелить.

ну-ну, а теперь представь что в твоём языке конвенция передачи параметров - passing bу name

Вы описали лишь одну очень специфическую задачу, со стольким если, что не каждый программист сможет «вкурить» =) не говоря уже про компилятор. Мой моск в конце рабочего дня вообще отказывается воспринимать столько букав =)

Они сказали, что llvm не подходит для их задачи и стали пилить свой кодогенератор с блэк джеком

//поправил

насолько я помню разговор был именной такой, что дескать тяжело возиться с llvm

проблема в том что все подобные рассуждения опираются на 1-2, по мнению автора, очевидных случая

Но лично для Вас то они были не очевидные (как мы видим из предыдущего вашего комментария) :)

Поэтому для Вас:

но, уверяю, если попробовать начать писать реализацию, то быстро начинаешь волосы на попе рвать от отчаяния

Это, скорее, закономерное следствие.

>проблема в том что все подобные рассуждения опираются на 1-2, по мнению автора, очевидных случая

Но лично для Вас то они были не очевидные (как мы видим из предыдущего вашего комментария) :)

это оттого что я вижу практически 100% гарантию вляпаться с такими подходами

и да, смотрите

ну-ну, а теперь представь что в твоём языке конвенция передачи параметров - passing bу name

Ну о чем Вы таком говорите. Посмотрите на новость, которую Вы сами и создали. Речь едет о программе на LLVM инструкциях, а не каком-то там языке.

И да, вы не поверите, но «passing bу name» абсолютно ничего не меняет. Тут то же самое что и с глобальными переменными, что я уже написал.