LLVM 3.0

А здесь ему то зачем? В том же С++ при использовании битовых полей мало что гарантируется, кроме как того, что ты сможешь обращаться к нему. А уж порядок бит там это личные сексуальные проблемы компилятора.

Ты не развернул вот эту часть:

если align в struct, union происходит в порядке увеличения адреса в байтах.

И напиши, что такое «арифметическое понимание»

А так же, ты начал с ассемблера и IR и Endiannes. Ты с ними разобрался?

А уж порядок бит там это личные сексуальные проблемы компилятора.

Порядок бит? Можно подробнее?

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

И да, я писал код, который учитывал это, ибо работал он и на ppc и на x86, но этот код писал я, а не компилятор.

Блин.

Арифметическое: fedcba9876543210

В памяти: 76543210fedcba98

Но когда ты обращаешься к нему, как к единому типу, ты не задумываешься об этом.

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

Да, да. У меня сразу этот топик хабра всплыл в голове.

Я до сих пор не понимаю, зачем КОМПИЛЯТОРУ

Да понял я, что ты этого не понимаешь. Но вопрос не об ограниченности твоих (или моих, раз я не могу привести четкий use-case), а в дизайне LLVM.

Не. Ну может быть какому-то компилятору это и надо, но точно не С/С++. Вообще, если компилятор генерирует код (именно автогененрируемый код, а не код, написанный программистом), и он может быть зависим от этого, то компилятор должен это учитывать. Но use-case этого я не представляю.

Если вы пользуетесь высокоуровневыми средствами Си++, Паскаля, Питона и т.д. то он транслируются в высокоуровневые инструкции IR (т.е. в IR структуры будут представлены как структуры) которые будут корректно транслированы в машинный код, если же вы к структуре обращаетесь как к массиву байтов (т.е. буз корректного преобразования типа пытаетесь работать на низком уровне) то уж извольте вас никакой компилятор не спасет by design. Вы должны осознавать что делаете.

буз = без. Я не поверю что какой-то мифический компилятор прочитает ваши мысли и переставит для вас байты в нужном порядке в вашем use-case.

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

Повторюсь: IR достаточно высокоуровневый. У него есть всевозможные инструкции приведения типов. И даже куда более высокоуровневые. Взять пример из новости:

LLVM IR (intermediate representation - платформонезависимый ассемблер для LLVM) включает в себя полную поддержку атомарных операций с памятью (load, store, compare, exchange, read/modify/write, etc.);

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

Хотя в принципе думаю проблемы такой (сильной привязки к особенностям железа) нет в принципе - на уровне виртуальной машины вводятся стандарты (например: все числа хранятся как индианлесс). Далее при трансляции из исходников в байт-код попадают уже правильно расположенные байты, а при трансляции из байт-кода в нативный код уже конвертируются под особенности конкретной архитектуры ЦПУ. И введением таких стандартизованных ограничений на язык байт-кода можно видимо обойти любые ограничения на несовместимость железа - думаю, именно так и работают остальные компиляторы

эх ты... знаток Mono и ник такой же ))) мы про нативные говорим вообщето и то как они подцепляются, ясен красен что .net-овские dll совершенно иного рода

Главная фича новых плюсов «Concurrency» вообще не поддерживается. Кому нужен такой компилятор?

из доков на Mono

The Common Language Infrastructure (CLI) is designed to make it «easy» to interoperate with existing code. In principal, all you need to do is create a DllImport function declaration for the existing code to invoke, and the runtime will handle the rest. For example:

 [DllImport ("libc.so")]
 private static extern int getpid ();

вот такая интеграция мне нра

Не много языков позволят вам такое наплевательское отношение к типам чтобы обращаться к структуре как к массиву байт, но даже если взять самый популярный (и ненавистный) из таких Си/Си++ то ваш код не будет работать на платформах с разным размером int, порядком байт в слове, значением align и т.д. Разве что вы будете совершать соответствующие проверки например с помощью sizeof, но стоп! тогда эти же проверки будут и в IR и оно будет работать так же ) Алилуйя.

тогда я не понимаю, в чем проблема, в питоне же есть поддержка FFI. или что-то другое имеется в виду?

для простоты можно какой-нибудь SWIG юзать.

А могёт кто полноценно сделать обзор и сравнить производительность программ, максимально оптимизированных с помощью LLVM, старого доброго gcc и интеловского icc? Например, как распараллеливаются циклы по ядрам и пр. и пр. С цифрами-то и примерами интереснее было бы аргументировать.

Язык Си разрабатывался как платформонезависемый, и если пишется переносимый код, то биты вытягиваются так i&MASK=MASK

Если вы к структурам обращаетесь как к массиву байт, то не LLVM компилятор вас не спасет, в разных компиляторах есть разные опции, которые могут изменить физическую адресацию структур, например для оптимизация памяти/скорости, могут сделать адресацию/смещение кратным, например 64 битам и т.п... .

Сразу вспомнился термин БЫДЛОКОД из луркморе :)

Сорри за возможно глупый вопрос =) Но разве сейчас кто-то в продакшене полагается на автоматическое распараллеливание? =)

import ctypes
libc = ctypes.CDLL( '/lib/libc.so.6' )
t = libc.time(None)
print t

да, точно, не знал - нашел, я как раз этим интересовался

Компилятору тоже нужно об этом знать, хотя бы в случаях приведения типов

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

И введением таких стандартизованных ограничений на язык байт-кода можно видимо обойти любые ограничения на несовместимость железа

Оно то да. Но язык должен стать очень умный, ибо пришлось бы анализировать, что вот этот void* это long, а вот этот char. А от этого пытались уйти.

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

Вообще ограничения, связанные с разными размерами типов, а, следовательно, разнными вариатами allign присущи всем компиляторам. Так что это проблема программиста ИМХО.

А могёт кто полноценно сделать обзор и сравнить производительность

Делали. Скоро будет еще. Сравнимо, но llvm проигрывал

Сразу вспомнился термин БЫДЛОКОД из луркморе :)

Именно. Должны быть веские основания для того, чтоб так делать. Как мы уже тут обсудили, use case, кроме как ошибки программиста и быдлокода, мы не увидели.

Пафосно-интеллигентным тоном: Как, разве Вы не читали код современного компилятора? :)

Молодец, соображаешь. Не то, что тупые регистранты :D

LLVM реализует виртуальную RISC-машину (так говорит википедия).

Советую тебе пореже заходить на ru.wikipedia.org. Ассемблер LLVM имеет под собой некую теоретическую базу (http://en.wikipedia.org/wiki/SSA_(compilers) ) и весьма эффективно транслируется в машинный код x86, которые, как известно, являются представителями CISC архитектуры.

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

Ты сомневаешься в существовании платформно-независимых оптимизаций, или что? %)

Вообще ограничения, связанные с разными размерами типов, а, следовательно, разнными вариатами allign присущи всем компиляторам. Так что это проблема программиста ИМХО.

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

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

Можно я? =) Способов много, лучше почитать статьи на эту тему хотя бы на сайте того же LLVM, первое что приходит на ум это инлайнинг функций, упрощение некоторых мат вычислений (да, да, может быть и такое, если программисту совсем уж было лень замарачиваться и он пропустил очевидные оптимизации), удаление хвостовых рекурсий, отбрасывание не используемого кода и т.д. Кроме того такое представление отлично подходит для статического анализа кода(т.е. программисту могут выдаваться варнинги от «Ты забыл инициализировать переменную» до «Вах! У тебя здесь может быть утечка памяти/других ресурсов», «Вайвайвай может быть dead lock» и т.д.) и всё это не зависимо от языка на котором пишется программа.

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

Это был намёк на то, что современные компиляторы делают очень много оптизаций на разных проходах/стадиях, часть из которых сильно платформенно-зависима и эту часть нельзя в принципе сделать платформенно-независимой. Соответственно нельзя дропать такие вещи, как уже замусоленный endianness, так как это дропнет эти оптизации.

Можно я? =) Способов много, лучше почитать статьи на эту тему хотя бы на сайте того же LLVM,

Молодец, после такого твоего объяснения наконец-то смогу спокойно спать. Благодарсвтую.

Ваш намек принят к сведению и отправлен разрабам через машину времени в прошлое, поэтому платформозависимые оптимизации в LLVM стеке есть ;)

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

Соответственно нельзя дропать такие вещи, как уже замусоленный endianness, так как это дропнет эти оптизации.

Как только начинаешь думать об endianness, оптимизация летит в Ж

Ты толст.

Все таки вы меня заинтересовали вопросами платформозависимых оптимизаций. Как нить почитаю детали. Интересно

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

до версии 3 байткод не был кроссплатформенным. Это изменили?

Ты толст.

Сам толст. Если ты runtime начинаешь менять порядок байт или выбирать с помощью адресной арифметики байта вместо применения маски или сдвигов, то ты ССЗБ

Ассемблер LLVM имеет под собой некую теоретическую базу (http://en.wikipedia.org/wiki/SSA_(compilers) ) и весьма эффективно транслируется в машинный код x86, которые, как известно, являются представителями CISC архитектуры.

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

Я уверен что есть платформонезависимый инлайнинг ) ибо сегодня очень модно писать например геттеры и сеттеры в одну строчку, типа: public int value { get { return _value; } set { _value = value; } }

так что есть смысл от такого оптимизатора )

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

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

ещё раз - до 3-й версии он не был таким. Что-то изменилось?

У меня ненароком действительно в 1 строчку получилось =) сорри )

так что есть смысл от такого оптимизатора )

Это да. Надо бы покурить, интересная это вещь.