forum.opennet.ru

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

Оглавление

Оптимизация приложения 'Hello world', opennews (ok), 17-Мрт-10, (0) [смотреть все]

Что называется нет предела совершенству , Vitto74 (ok), 14:00 , 17-Мрт-10, (1) //

Что называется делать нечего Большенство программ требуют стандартную библиотек, Аноним (-), 14:25 , 17-Мрт-10, (5) //

На ассемблере какого процессора, сэр У ассемблера есть одна проблемка - он непо, User294 (ok), 14:34 , 17-Мрт-10, (6) //

да ладно, практического смысла это имеет мало лучше бы скорость загрузки библио, Аноним (-), 14:39 , 17-Мрт-10, (10)

Когда как Вот немного лирики http www wasm ru article php article onebyte , User294 (ok), 15:47 , 17-Мрт-10, (17)

тот кто мыслит как быдло пишет на жабе и C потому что тогда это будет отдельный , Аноним (-), 15:57 , 17-Мрт-10, (18)

Мыслить как быдло можно в принципе на любом языке Быдло предпочитает упомянутые, User294 (ok), 16:16 , 17-Мрт-10, (23)

Можно Но не обязательно все же писать все на asm Можно и сайты на asm писать, н, Аноним (-), 16:25 , 17-Мрт-10, (25)

скорее GCC - плагин к LLVM, на Mac используется с 2007 г LLVM-GCC4 2, что вам ме, Ariel (??), 17:02 , 17-Мрт-10, (38)

считайте что религия свободная GPL альтернатива LLVM которая заменит в перспект, Аноним (-), 17:48 , 17-Мрт-10, (41)

LLVM вам не нравится свободной лицензией BSD статью о его возможностях вообще ч, Ariel (??), 20:09 , 17-Мрт-10, (53)

Да, потом нам будут приезжать очень такие свободные тулчейны в виде блобятины по, User294 (ok), 21:17 , 17-Мрт-10, (57)

перечетайте статью и не только про llvm ещё раз, т к у вас каша в голове 1 l, минона (?), 12:33 , 18-Мрт-10, (65)

дотнет генерирует _нативный_ код, аноним (?), 13:48 , 18-Мрт-10, (67) –2

развейте свою мысль и тогда поговорим ps возможность такая есть но также есть р, минона (?), 14:10 , 18-Мрт-10, (68)
Что сказать то хотели В конечном итоге процы нихрена кроме нативного кода выпол, User294 (ok), 14:18 , 18-Мрт-10, (70)

статью писал не я 1, 2LLVM не моджет иметь синтаксический или лексический анализ, Ariel (??), 22:55 , 18-Мрт-10, (84)

это гораздо ближе к истине кроме вот этого тогда придумайте зачем понадобились , минона (?), 23:44 , 18-Мрт-10, (85)
если понимать LLVM в узком смысле, то вы правы, но Крис как бы намекает нам, что, Ariel (ok), 01:30 , 20-Мрт-10, (87)

Тут еще минета Джоббсу не хватает в знак признательности, или типа того Лично м, User294 (ok), 20:16 , 18-Мрт-10, (78)

В этом треде никто и не предлагал писать на асме Более того, тут вообще только , User294 (ok), 14:15 , 18-Мрт-10, (69)

все верно, кроме одного вот выдержки - http ru wikipedia org wiki Unix_wayболе, минона (?), 14:54 , 18-Мрт-10, (72)

Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптими, User294 (ok), 20:38 , 18-Мрт-10, (80)

может быть я не так понял но я точно уверен, что сила юниксвэй вообще и линукс в, минона (?), 21:14 , 18-Мрт-10, (82)
а да в посикс нет завязок ни на фс, ни на их реализации и т д иногда проще в либ, минона (?), 21:22 , 18-Мрт-10, (83)

Эти две фразы противоречат друг другу Сначала приложение нужно разработать, пот, Аноним (-), 15:52 , 18-Мрт-10, (74)

Нормальный архитект должен прикинуть проблемные места еще на фазе проектирования, User294 (ok), 20:27 , 18-Мрт-10, (79)

ты статейку то открой автор так или иначе предлагает непортабельный код, заменя, mike lee (?), 15:44 , 17-Мрт-10, (16) +1

Когда как В какомнить embedded такое на каждом углу Иногда натурально бывает н, User294 (ok), 16:19 , 17-Мрт-10, (24)

Есть программы отрицательной длины не бывают P , User294 (ok), 14:38 , 17-Мрт-10, (9) +1 //

Ага, идеальна та программа, которая не написана, savant (ok), 16:53 , 17-Мрт-10, (36) +2

Хм, может там еще есть что соптимизировать , Зилибоба (ok), 14:07 , 17-Мрт-10, (2) //

ага, можно можно выкинуть нафик строку назвать прогу Хелло ворлд и выводить , hhg (ok), 22:02 , 19-Мрт-10, (86)

Как будто неоптимизированные программы закончились, принялись за столь полезную , www2 (ok), 14:11 , 17-Мрт-10, (3) //

ИМХО, это можно засчитать за вполне вменяемый туториал по поводу того как и что , User294 (ok), 14:37 , 17-Мрт-10, (8) //

многомеговое монстрило по любому будет завязано на libc - бессмыленно это , Аноним (-), 14:42 , 17-Мрт-10, (11) +2 //

Бессмысленно - пытаться освоить азы на сложной и навороченной конструкции Это к, User294 (ok), 15:59 , 17-Мрт-10, (19) +2

В реальной программе в любом случае будет зависимость на libc Это не hello wor, Аноним (-), 16:27 , 17-Мрт-10, (26)

практический смысл имеет переработка гцц, дабы тот перестал вываливать неэффекти, аноним (?), 18:45 , 17-Мрт-10, (47) –2

пройди вступительный тест в разрабы gcc и переработай его , Карбофос (ok), 20:50 , 17-Мрт-10, (56)
К link-time оптимизации весь этот бред вообще никак не относится А hand-optimiz, User294 (ok), 20:41 , 18-Мрт-10, (81)

Далеко не в любом Скажем в embedded отсутствие стандартной либы вообще норма жи, User294 (ok), 21:27 , 17-Мрт-10, (60)
почему это в любом а если dietlibc или ulibc, phaoost (ok), 10:40 , 18-Мрт-10, (64)

Вот бы так еще ядро оптимизировали , Аноним (-), 14:22 , 17-Мрт-10, (4) –2
А вы знаете, что если в PHP вместо двойных кавычек использовать одинарные, то па, zazik (ok), 14:35 , 17-Мрт-10, (7) //

потому и написали компилятор PHP, потому что спрыгивать с этого дерьма на что-то, Аноним (-), 15:59 , 17-Мрт-10, (20) //

А вам не кажется, что если бы он был таким дерьмом, то на нём не писало бы такое, zazik (ok), 16:05 , 17-Мрт-10, (22) //

Миллионы мух не могут ошибаться в дерьме определенно что-то есть , Аноним (-), 16:30 , 17-Мрт-10, (27)

Ничего не понял, знаки препинания помогут тебе вдохнуть смысл в сей набор слов , zazik (ok), 16:33 , 17-Мрт-10, (28)

Вы правда никогда не слышали это выражение , Аноним (-), 08:48 , 18-Мрт-10, (63)

нет не кажется , Аноним (-), 16:35 , 17-Мрт-10, (29)
Про Windows напомнить Быдло всегда ищет где поменьше думать надо , аноним (?), 16:40 , 17-Мрт-10, (32) –1

OMG, это в Пыхе-то думать не надо Да, там нет строгой типизации, ну и что Дума, zazik (ok), 16:43 , 17-Мрт-10, (33)

в исходники php загляните чтобы говорить о его качестве , Cobold (??), 16:50 , 17-Мрт-10, (35)

И что там, в исходниках Зашифрованный призыв Сатаны , zazik (ok), 16:54 , 17-Мрт-10, (37)

там почерк создателей, иногда полезно познакомиться чтобы не поддаваться лишним , Cobold (??), 17:29 , 17-Мрт-10, (39)

Во-первых, у них есть нормальное коммунитэ, которое достаточно успешно патчит и , zazik (ok), 17:31 , 17-Мрт-10, (40)

кстати, Вам не доводилось им багрепорты слать Субъективно конечно, может это то, Cobold (??), 19:20 , 17-Мрт-10, (51)

Доводилось, правда один и по хелпу, а не по сырцам Относятся нормально, пофикси, zazik (ok), 19:54 , 17-Мрт-10, (52)

как связана реализация языка интерпретатор с качеством написанного на нем кода, azure (ok), 17:59 , 17-Мрт-10, (43)

В этом мире все связано Хуже интерпретатор - медленнее исполняется код Неэффек, аноним (?), 18:14 , 17-Мрт-10, (44) +1

трололо кстати, sql тоже изначально рассчитан на непрофессионалов отказываешься, аноним (?), 18:51 , 17-Мрт-10, (48)

И кто его сечас собственно как язык программирования использует Это скорее прот, Cobold (??), 19:02 , 17-Мрт-10, (50)

1да, а ещё количество идиотских багов, нестабильность языка и настроек дефолтно, Cobold (??), 18:55 , 17-Мрт-10, (49)

очень наивно, Cobold (??), 16:46 , 17-Мрт-10, (34)

местечковые гуру зрят в корень все переходим на perl6, аноним (?), 18:43 , 17-Мрт-10, (46)

А кто вам сказал, что на нем пишут 99 9 Веб-дезигнеров никогда с нуля не писа, pavlinux (ok), 21:21 , 17-Мрт-10, (59)

Форум для разработчиков сказал , zazik (ok), 23:35 , 17-Мрт-10, (61)

Они-то и есть 1 , pavlinux (ok), 00:04 , 18-Мрт-10, (62)

http www muppetlabs com breadbox software tiny teensy htmlhttp bsd ope, Andrey Mitrofanov (?), 14:53 , 17-Мрт-10, (12) //

Странно, что на самом опеннете, никто ничего не искал похожего, а ведь есть пост, Damon (??), 20:24 , 17-Мрт-10, (54) //

Ну дык, даже первую страницу гугля лениво просматривать, не то что подбирать бол, Andrey Mitrofanov (?), 14:26 , 18-Мрт-10, (71)

Наконец-то опомнились Теперь осталось оптимизировать всего-то миллионы программ, aZ (ok), 15:19 , 17-Мрт-10, (15) //

Золотые слова , reanimat0r (?), 16:35 , 17-Мрт-10, (30)

подобные туториалы есть и для виндов, вот это я использовал для написания диплом, Карбофос (ok), 16:03 , 17-Мрт-10, (21)
Муха-ха - вспомнилась молодость FIDO анологичный срач и как результат MS-, Diogene the Open Source programmer (?), 17:49 , 17-Мрт-10, (42)
Прикольно - этот hello, world, собранный на FreeBSD занимает по умолчанию в два , аноним (?), 18:19 , 17-Мрт-10, (45) //

Там может выравнивание секций elf а отличаться по дефолту В исполняемых файлах , Damon (??), 20:37 , 17-Мрт-10, (55)
для этого надо проверить, какие секции в бинарники остаются а в целом, про удал, Карбофос (ok), 21:19 , 17-Мрт-10, (58)

реальный софт тащит за собой такую кучу библиотек что такая оптимизация не имеет, sluge (ok), 15:28 , 18-Мрт-10, (73)

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

1. "Оптимизация приложения " +/–

Сообщение от Vitto74 (ok), 17-Мрт-10, 14:00

Что называется нет предела совершенству.

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

5. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 17-Мрт-10, 14:25

Что называется делать нечего.
Большенство программ требуют стандартную библиотеку для работы. А те, что не требуют, те проще написать на ассемблере. Извращение это все...

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

6. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 17-Мрт-10, 14:34

> А те, что не требуют, те проще написать на ассемблере.
На ассемблере какого процессора, сэр? У ассемблера есть одна проблемка - он непортабельный. И собственно а вы пробовали на ассемблере писать всю программу, а не кусочки? Под линух? И как, вам это показалось очень простым начинанием? Ну-ну, языком трындеть не мешки ворочать :). А писать под линух на голом асме от и до - очень на любителя. Не хочу ничего сказать но под операционки писанные на сях, удобно писать на сях. На асме получается довольно колебательно в общем случае.

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

10. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 17-Мрт-10, 14:39

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

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

17. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 17-Мрт-10, 15:47

> практического смысла это имеет мало
Когда как. Вот немного лирики... http://www.wasm.ru/article.php?article=onebyte
(в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...)
> лучше бы скорость загрузки библиотек в память увеличили
Если вас напрягает именно этот аспект - курить маны про прелинкинг, например. Да и чем меньше библиотек грузить - тем меньше их время загрузки. Логично? :)
> и в gcc оптимизатор в отдельный проект выделили по типа LLVM
А зачем все под 1 гребенку то? Есть железобетонная уверенность что так - лучше и баста? И для кого лучше? И почему? Да и строго говоря, вы как бы вы о compile-time оптимизации кода, а тут спич был в основном о link-time оптимизации его компоновки. Как бы слегка разные сущности, а? Даже не пересекающиеся толком (как минимум в классическом дизайне компилеров).

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

18. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 17-Мрт-10, 15:57

>(в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...)
тот кто мыслит как быдло пишет на жабе и C#

>А зачем все под 1 гребенку то? Есть железобетонная уверенность что так
>- лучше и баста? И для кого лучше? И почему?
потому что тогда это будет отдельный проект который можно будет развивать независимо.
помоему это главный плюс LLVM. нужно то-же только под GPL.

>Как бы слегка разные сущности, а?
разные. я о том что силы не туда тратят

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

23. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 17-Мрт-10, 16:16

>тот кто мыслит как быдло пишет на жабе и C#
Мыслить как быдло можно в принципе на любом языке. Быдло предпочитает упомянутые т.к. там дескать думать своей головой поменьше надо. А быдло думать головой не умеет и не любит. Тем не менее, судя по некоторым программам, никакие законы природы не запрещают генерить быдлокод и на сях. Да, это случается реже, т.к. тулсы труднее для освоения дубами. Но - случается, как ни странно.
>потому что тогда это будет отдельный проект который можно будет развивать независимо.
>помоему это главный плюс LLVM. нужно то-же только под GPL.
Хм... прикрутить LLVM как плагин к GCC? :) Если, конечно, оно того вообще будет стоить (что как бы еще не факт и как говорится, "будем посмотреть").
>>Как бы слегка разные сущности, а?
>разные. я о том что силы не туда тратят
Туториал по основам и просто проверка мастерства - вполне нормально. А что до затрат сил - как бы это очень разные виды оптимизации и совсем не факт что те кто умеет линк-тайм оптимизацию заодно является гурой по кодогенерации и оптимизации оной. Странно что столь простая истина не доходит.

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

25. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 17-Мрт-10, 16:25

>Мыслить как быдло можно в принципе на любом языке.
Можно. Но не обязательно все же писать все на asm.
Можно и сайты на asm писать, но пишут в основном на чем то типа php ибо проще, быстрее и все равно все упирается в SQL а не в скорость интерпретации php.
Преждевременная оптимизация зло. 80% времени выполняется 20% кода.
>Хм... прикрутить LLVM как плагин к GCC? :)
Такое уже есть. Нужен свой LLVM под GPL который должен придти на смену оптимизатору gcc.
Как раньше были всякие egcs который влился в gcc.
>Странно что столь простая истина не доходит.
Истина доходит, вот только конкретно вышеописанное практического смысла вообще не имеет кроме повышения опыта автора. Вот и было бы клево чтобы он занялся более практическими вещами.

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

38. "Оптимизация приложения " +/–

Сообщение от Ariel (??), 17-Мрт-10, 17:02

>Такое уже есть. Нужен свой LLVM под GPL который должен придти на
>смену оптимизатору gcc.
>Как раньше были всякие egcs который влился в gcc.
скорее GCC - плагин к LLVM, на Mac используется с 2007 г LLVM-GCC4.2, что вам мешает его использовать и зачем
>Нужен свой LLVM под GPL
не религия ли?
алгоритм такой: C / C++ / ObjC / compilers -> intermediate bytecode -> LLVM -> native code
http://habrahabr.ru/blogs/programming/47878/
LLVM — не просто очередной академический проект. Его история началась в 2000 году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии как Apple и Adobe. В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple.
которым можно производить трансформации во время компиляции, компоновки (linking) и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.
LLVM написана на C++ и портирована на большинство *nix-систем и Windows. Система имеет модульную структуру и может расширяться дополнительными алгоритмами трансформации (compiler passes) и кодогенераторами для новых аппаратных платформ. Пользовательский фронтенд, как правило, линкуется с LLVM и использует C++ API для генерации кода и его преобразований.

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

41. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 17-Мрт-10, 17:48

считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор gcc должна появиться и точка.

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

53. "Оптимизация приложения " +/–

Сообщение от Ariel (??), 17-Мрт-10, 20:09

>считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор
>gcc должна появиться и точка.
LLVM вам не нравится свободной лицензией BSD? статью о его возможностях вообще читали?

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

57. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 17-Мрт-10, 21:17

>LLVM вам не нравится свободной лицензией BSD?
Да, потом нам будут приезжать очень такие свободные тулчейны в виде блобятины под целевые платформы. При том скорее всего - под бзди бинарники никто собирать не будет, спасибо если хоть под i386 линух будет сборка, и то фифти-фифти. А то ведь может оказаться и win-only блобятина чего доброго. Ну и сорс генерации кода под целевую архитектуру зажопят - дескать, бодайтесь сами. В гробу я такую "свободу" видал, честно говоря.

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

65. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 12:33

перечетайте статью (и не только) про llvm ещё раз, т.к. у вас каша в голове.
1. llvm не имеет лексического и синтаксического анализатора для с/с++. для этой цели он задействует gcc
2. чтобы собрать нативный код под платформу ему опять же нужены gnu assembler и gnu linker (другими словами он преобразует исходники - например на с - в ассемблер, а гнушные уже соберут в бинарник)
3. в макоси не "подсистема opengl" основана на нём, он просто используется для компиляции кода шейдеров во время выполнения. не более.
4. количество поддерживаемых платформ и языков у него гораздо меньше, чем у gcc
5. если с чем и сравнивать llvm, то с платформой дотнет. но только лучше (т.к. используя гнушные утилиты можно получить нативный код)
6. у яблока (и адоба, и ...) просто не было выбора с их универсал бинари.
ну и 7 - как это коррелирует с новостью? помоему никак

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

67. "Оптимизация приложения " –2 +/–

Сообщение от аноним (?), 18-Мрт-10, 13:48

>лучше (т.к. используя гнушные утилиты можно получить нативный код)
дотнет генерирует _нативный_ код

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

68. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 14:10

развейте свою мысль и тогда поговорим.
ps:
возможность такая есть. но также есть ряд причин почему компиляция полноценного .net приложения в нативный код не целесообразна. это с одной стороны.
с другой стороны нативные сырцы от с/с++/асм - тоже не целевая сфера .net.
в тоже время компиляция в нативный код в llvm ничем не отличается от той же компиляции например в gcc. поэтому их и сравнивают (на мой взгляд ошибочно). ценность же llvm именно в в том, что аббревиатура llvm под собой скрывает. и это как раз аналог .net. только лучше.

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

70. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 18-Мрт-10, 14:18

>дотнет генерирует _нативный_ код
Что сказать то хотели? В конечном итоге процы нихрена кроме нативного кода выполнять 1 фиг не умеют. Так что все так или иначе генерят нативный код весьма разными по кривизне и эффективности методами. И дальше что?

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

84. "Оптимизация приложения " +/–

Сообщение от Ariel (??), 18-Мрт-10, 22:55

>у вас каша в голове
статью писал не я
1, 2
LLVM не моджет иметь синтаксический или лексический анализатор, это целая инфракструктура создания компиляторов и run-time architecture, чтобы скормить ей код, его нужно транслировать в ассемблер LLVM, с помощью front-end, в качестве таковых могут выступать gcc, clang, или то, что вы напишите. Это значит, что вам при написании компилятора, пишите транслятор из своего языка в ассемблер LLVM, а трансляцией его в нативный код целевой платформы займётся LLVM.
3 статью писал не я
4 и?
что касается "лишнего" bytecode, он используется для например, link-time оптимизации.
http://developer.apple.com/mac/library/releasenotes/Develope...
на остальную истерию юзера294 нет смысла писать

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

85. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 23:44

это гораздо ближе к истине. кроме вот этого:
>а трансляцией его в нативный код целевой платформы займётся LLVM.
тогда придумайте зачем понадобились гнушные ассемблер и линкер (могут быть и не гнушные)?
нет. llvm - это именно то, как он и расшифровывается.
если хотите, то компиляция в нативный код - это его побочная функция.
универсальная? да. логичная? да. но побочная.
говорят правда, что он преобразует исходный код на С/С++ в промежуточный быстрее, чем gcc. но это не так важно. да и не всё он делает. а когда сможет - не факт, что будет быстрее.
если хотите, то это следующий шаг вначале после java, а потом после дотнета.
конечно бродят мысли сделать нечто подобное и на базе gnu/gcc - почему нет?

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

87. "Оптимизация приложения " +/–

Сообщение от Ariel (ok), 20-Мрт-10, 01:30

если понимать LLVM в узком смысле, то вы правы, но
>LLVM is also a collection of source code that implements the language and compilation strategy. The primary >components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework >with a growing set of global and interprocedural analyses and transformations, static back-ends for many popular >(and some obscure) architectures, a back-end which emits portable C code, and a Just-In-Time compilers for >several architectures.
Крис как бы намекает нам, что LLVM можно понимать и несколько шире,  и считать front-end и back-end частью LLVM. К сожалению, о back-end я нашел мало информации, возможно потому, что front-end`ов может быть много, а back-end на целевую архитектуру - один;
испоьзуют ли утилиты llvm as и ld не знаю, но возможно, что и нет:
llc - generate native machine code for a bytecode file
lli - directly run a program compiled to bytecode using a JIT compiler or interpreter

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

78. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 18-Мрт-10, 20:16

>LLVM-GCC4.2, что вам мешает его использовать и зачем
Тут еще минета Джоббсу не хватает в знак признательности, или типа того.
>не религия ли?
Лично мне не нужны чертовы блобы в роли тулчейна. Это уже проходили, спасибо. Потом въехали мордой в стол, когда борланд стал метаться в разные стороны. Добавки от ябблов и прочих проприетарных конторок которым BSDL удобна сугубо для зажима сорцев - не надо, спасибо.
>алгоритм такой: C / C++ / ObjC / compilers -> intermediate
>bytecode -> LLVM -> native code
Мне одному кажется что фаза с intermediate bytecode по идее лишняя и нафиг не впилась, по больщому счету? Ну то есть, если поклоняться LLVM оно может и надо, но если цель - получить от компилера бинарь - эта фаза определенно лишняя :).
>LLVM — не просто очередной академический проект. Его история началась в 2000
>году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии
>как Apple и Adobe.
При том обе конторы - злостные проприетарщики. Наиболее мерзкие из существующих пожалуй. Первые просто фашисты, достаточно на их ограничилово посмотреть. И там же в районе хабры какой-то мак-овец проблеял что-то вида "Эппл позволяет юзать их девелскую тулсень только под макось версий ... ". Вот извините, но такого блеяния нам не надо. Идите нафиг. Вместе с вашими богами из эппла. И блейте там дальше под их строгим надзором. Мак-овцы, блин.
>В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5,
>а iPhone SDK использует GCC с бэкэндом на LLVM.
А я юзаю обычный GCC генеря оным код под штук пять разных платформ. И мне если честно насрать что там использует эппл и адоб, потому что оно зачастую какая-то блобятина и/или не умеет генерить код так как надо мне без большого бубна и в проверенном на безглючноть виде. Ы?
>Apple является одним из основных спонсоров проекта, а вдохновитель
>LLVM — Крис Латтнер — теперь работает в Apple.
Вот и хрен с ним с этим эпплом. Мне не нужен геморрой с тулчейном и блобятиной в нем. И чем дальше от этих фашиствующих проприетарщиков - тем проще моя жизня. Приколитесь? :)
>LLVM поддерживает генерацию кода для x86, [...]
Угу, пара моментов:
1) Вы забыли тут рекламный баннер воткнуть в вашей порции пиара.
2) Я ни разу в жизни не видел тулсей генерящих код LLVMом под, допустим, MIPS или хотя-бы внятных описаний как сие собрать.
>LLVM написана на C++ и портирована на большинство *nix-систем и Windows.
А GCC портирован на немереное количество платформ. Даже дос в качестве хохмы :). А уж как таргет у него может быть и мелочь типа Atmel AVR, Ti MSP430, простые ARM7 и Cortex и т.п. :). При том - можно взять эти тулзы и сгенерить код.
>с LLVM и использует C++ API для генерации кода и его преобразований.
Угу, практика показывает что чем больше наворотов - тем больше глюков. Со всеми этими преобразованиями потом поди черт ногу при отладке сломит.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

69. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 18-Мрт-10, 14:15

>Можно. Но не обязательно все же писать все на asm.
В этом треде никто и не предлагал писать на асме. Более того, тут вообще только особенности линковки обсуждались. Для тех кто на бронепоезде, намекаю: линковка строго говоря к языку программирования не особо относится: линкеру в принципе насрать как вы получили вон тот объектник. Написали ли вы его ручками в хексэдиторе, собрал ли вам его ассемблятор, сгенерил ли его сишный (а может и какой-нибудь еще) компилер и прочая. Спич шел о оптимизации размера программы и освоении азов линкера по сути.

>Можно и сайты на asm писать, но пишут в основном на чем
>то типа php ибо проще, быстрее и все равно все упирается
>в SQL а не в скорость интерпретации php.
А когда прижимает - переписывают куски на сях/плюсах, выбрасывают скуль и юзают простые но чертовски быстрые БД вида key-value (или memcached как вариант если все в оператвку умещается).

>Преждевременная оптимизация зло.
Дежурный принцип рапидчика? :)
>80% времени выполняется 20% кода.
Поэтому нормальные люди оптимизируют именно те места в которые упирается. А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например).
>Такое уже есть. Нужен свой LLVM под GPL который должен придти на
>смену оптимизатору gcc.
Может нужен, а может и нет. Далеко не факт что сие натянет оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто дает просраться половине коммерческих компилеров под ряд архитектур.
>Истина доходит, вот только конкретно вышеописанное практического смысла вообще
>не имеет кроме повышения опыта автора.
Оно имеет смысл - на простом примере можно научиться, блин, управлять линковкой. Поняв что и как и когда возникнет необходимость (минимальные системы, embedded, ... например) - применив оный скилл. Да и вообще от оптимизации никому хуже еще не становилось.
>Вот и было бы клево чтобы он занялся более практическими вещами.
Клево для кого? За такие туториалы спасибо надо говорить. Хотя да, замечено что метать бисер перед теми у кого мозг работает хило - занятие неблагодарное.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

72. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 14:54

все верно, кроме одного:
>А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например).
вот выдержки - http://ru.wikipedia.org/wiki/Unix_way
>Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
>......
>Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
более того, ранняя оптимизация - действительно зло для универсальности решений.
лучше оптимизировать готовый код для сборки на конкретной платформе, чем заранее залочить себя только на одной из них и потом через костыли и грабли добиваться стандартов типа POSIX

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

80. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 18-Мрт-10, 20:38

>>Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите,
Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптимизировать любой ценой даже если ее и так хватает с запасом? Строго говоря весь этот тред в основном про оптимизацию *размера* программы. Путем фокусов с линкером. При том фокусы потенциально грабельные, да. Но они позволят понять как работает линкер, как компилер генерячит программу, из каких кирпичиков она собирается и потом можно с этим играться в :)

>и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
Опять же, повторяю, блин: оптимизция скорости и размера - разные сущности, зачастую противоположные по смыслу.
>стабильной работы, только потом оптимизируйте.
Все так, тем не менее, грамотно сархитектив и заранее вычислив очевидные потенциальные грабли - можно сильно скостить себе фазу траха с оптимизацией, или вообще от нее избавиться, ага?
>более того, ранняя оптимизация - действительно зло для универсальности решений.
Вполне соглашусь с этим - раньше для скорости писали на асме. Ну хоть те же VxD драйвера. И кому они теперь нужны? Правильно, 0xDEADC0DE :)
>лучше оптимизировать готовый код для сборки на конкретной платформе,
>чем заранее залочить себя только на одной из них и потом через костыли и
>грабли добиваться стандартов типа POSIX
Сильно зависит от. Подгонять какойнить код писанный допустим без учета специфики embedded под особенности оного - может быть достаточно непростым и грабельным начинанием. Скажем как делать POSIX вызовы если ФС в девайсе вообще нету?И куда они должны отправиться? :)

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

82. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 21:14

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

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

83. "Оптимизация приложения " +/–

Сообщение от минона (?), 18-Мрт-10, 21:22

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

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

74. "Оптимизация приложения " +/–

Сообщение от Аноним (-), 18-Мрт-10, 15:52

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

>Далеко не факт что сие натянет
>оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным
>отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто
>дает просраться половине коммерческих компилеров под ряд архитектур.
Факт, но также и факт что далеко не сразу. Но это перспективно и это должно появиться как аналог LLVM но под GPL, начать развиваться и постепенно придти на смену оптимизатору gcc.
Больше читать этот тред не буду, комментарии в виде дерева это нечто.

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

79. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 18-Мрт-10, 20:27

>Эти две фразы противоречат друг другу. Сначала приложение нужно разработать, потом узнать
>где оно тормозит и лишь потом оптимизировать тормозящее ибо преждевременная оптимизация
>зло.
Нормальный архитект должен прикинуть проблемные места еще на фазе проектирования и сделать все чтобы проблем было как можно меньше. Сие может очень сильно скостить потом нужду в пускании пара на фазе кодинга в аврально порядке. Ну и напротив - эпичная лажа в этой фазе воздастся нуждой в геройствовании потом.
>Факт,
Фактом оно будет когда я смогу взять в руки компилер А и Б и сравнить качество кодогенерации. Если А уделает Б наголову - отлично, А более хороший компилер. До тех пор - в сад!
>но также и факт что далеко не сразу.
У вас какие-то проблемы с логикой и причинно-следственными связями. См. выше. Не бывает софта который хорош в теории.
>Но это перспективно
Уточним, судя по всему это модно у ряда местных бздунов, которым очень хочется выбросить GCC который с неправильной лицензией, видите ли :).
>и это должно появиться как аналог LLVM но под GPL, начать
>развиваться и постепенно придти на смену оптимизатору gcc.
Вот только станет ли от этого лучше - большой такой вопрос. Собственно, а какие законы природы это гарантируют? И какие реализаторы это гарантируют? oO
>Больше читать этот тред не буду, комментарии в виде дерева это нечто.
Коменты на опеннете - да, та еще дрянь по удобству, согласен. На большей части других ресурсов такой стиль коментов сдох годы назад в силу ряда грабель и неудобств, но тут движок по прежнему хорошо отдает девяностыми :)

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

16. "Оптимизация приложения " +1 +/–

Сообщение от mike lee (?), 17-Мрт-10, 15:44

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

24. "Оптимизация приложения " +/–

Сообщение от User294 (ok), 17-Мрт-10, 16:19

>но в любом случае все это должно носить только познавательный характер.
Когда как. В какомнить embedded такое на каждом углу. Иногда натурально бывает надо сэкономить каждый байт любой ценой, например. Скажем если надо в 2-меговую флеху затрамбовать всего пингвина с кучей демонов, экономия по 10 кило на файл врядли покажется какой-то ненужной сущностью. Особенно если окажется что образ не лезет на каки-то чертовы 50 кило а перепаивать флеху в миллионе плат на более емкую стоит астрономических бабок :)

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

9. "Оптимизация приложения " +1 +/–

Сообщение от User294 (ok), 17-Мрт-10, 14:38

>Что называется нет предела совершенству.
Есть :) программы отрицательной длины не бывают :P.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

36. "Оптимизация приложения " +2 +/–

Сообщение от savant (ok), 17-Мрт-10, 16:53

Ага, идеальна та программа, которая не написана

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Оптимизация приложения "	+/–
Сообщение от Vitto74 (ok), 17-Мрт-10, 14:00
Что называется нет предела совершенству.
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 17-Мрт-10, 14:25
	Что называется делать нечего. Большенство программ требуют стандартную библиотеку для работы. А те, что не требуют, те проще написать на ассемблере. Извращение это все...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 17-Мрт-10, 14:34
	> А те, что не требуют, те проще написать на ассемблере. На ассемблере какого процессора, сэр? У ассемблера есть одна проблемка - он непортабельный. И собственно а вы пробовали на ассемблере писать всю программу, а не кусочки? Под линух? И как, вам это показалось очень простым начинанием? Ну-ну, языком трындеть не мешки ворочать :). А писать под линух на голом асме от и до - очень на любителя. Не хочу ничего сказать но под операционки писанные на сях, удобно писать на сях. На асме получается довольно колебательно в общем случае.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 17-Мрт-10, 14:39
	да ладно, практического смысла это имеет мало. лучше бы скорость загрузки библиотек в память увеличили и в gcc оптимизатор в отдельный проект выделили по типа LLVM чтобы его можно было независимо развивать
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 17-Мрт-10, 15:47
	> практического смысла это имеет мало Когда как. Вот немного лирики... http://www.wasm.ru/article.php?article=onebyte (в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...) > лучше бы скорость загрузки библиотек в память увеличили Если вас напрягает именно этот аспект - курить маны про прелинкинг, например. Да и чем меньше библиотек грузить - тем меньше их время загрузки. Логично? :) > и в gcc оптимизатор в отдельный проект выделили по типа LLVM А зачем все под 1 гребенку то? Есть железобетонная уверенность что так - лучше и баста? И для кого лучше? И почему? Да и строго говоря, вы как бы вы о compile-time оптимизации кода, а тут спич был в основном о link-time оптимизации его компоновки. Как бы слегка разные сущности, а? Даже не пересекающиеся толком (как минимум в классическом дизайне компилеров).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 17-Мрт-10, 15:57
	>(в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...) тот кто мыслит как быдло пишет на жабе и C# >А зачем все под 1 гребенку то? Есть железобетонная уверенность что так >- лучше и баста? И для кого лучше? И почему? потому что тогда это будет отдельный проект который можно будет развивать независимо. помоему это главный плюс LLVM. нужно то-же только под GPL. >Как бы слегка разные сущности, а? разные. я о том что силы не туда тратят
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 17-Мрт-10, 16:16
	>тот кто мыслит как быдло пишет на жабе и C# Мыслить как быдло можно в принципе на любом языке. Быдло предпочитает упомянутые т.к. там дескать думать своей головой поменьше надо. А быдло думать головой не умеет и не любит. Тем не менее, судя по некоторым программам, никакие законы природы не запрещают генерить быдлокод и на сях. Да, это случается реже, т.к. тулсы труднее для освоения дубами. Но - случается, как ни странно. >потому что тогда это будет отдельный проект который можно будет развивать независимо. >помоему это главный плюс LLVM. нужно то-же только под GPL. Хм... прикрутить LLVM как плагин к GCC? :) Если, конечно, оно того вообще будет стоить (что как бы еще не факт и как говорится, "будем посмотреть"). >>Как бы слегка разные сущности, а? >разные. я о том что силы не туда тратят Туториал по основам и просто проверка мастерства - вполне нормально. А что до затрат сил - как бы это очень разные виды оптимизации и совсем не факт что те кто умеет линк-тайм оптимизацию заодно является гурой по кодогенерации и оптимизации оной. Странно что столь простая истина не доходит.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 17-Мрт-10, 16:25
	>Мыслить как быдло можно в принципе на любом языке. Можно. Но не обязательно все же писать все на asm. Можно и сайты на asm писать, но пишут в основном на чем то типа php ибо проще, быстрее и все равно все упирается в SQL а не в скорость интерпретации php. Преждевременная оптимизация зло. 80% времени выполняется 20% кода. >Хм... прикрутить LLVM как плагин к GCC? :) Такое уже есть. Нужен свой LLVM под GPL который должен придти на смену оптимизатору gcc. Как раньше были всякие egcs который влился в gcc. >Странно что столь простая истина не доходит. Истина доходит, вот только конкретно вышеописанное практического смысла вообще не имеет кроме повышения опыта автора. Вот и было бы клево чтобы он занялся более практическими вещами.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Оптимизация приложения "	+/–
	Сообщение от Ariel (??), 17-Мрт-10, 17:02
	>Такое уже есть. Нужен свой LLVM под GPL который должен придти на >смену оптимизатору gcc. >Как раньше были всякие egcs который влился в gcc. скорее GCC - плагин к LLVM, на Mac используется с 2007 г LLVM-GCC4.2, что вам мешает его использовать и зачем >Нужен свой LLVM под GPL не религия ли? алгоритм такой: C / C++ / ObjC / compilers -> intermediate bytecode -> LLVM -> native code http://habrahabr.ru/blogs/programming/47878/ LLVM — не просто очередной академический проект. Его история началась в 2000 году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии как Apple и Adobe. В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, а iPhone SDK использует GCC с бэкэндом на LLVM. Apple является одним из основных спонсоров проекта, а вдохновитель LLVM — Крис Латтнер — теперь работает в Apple. которым можно производить трансформации во время компиляции, компоновки (linking) и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha. LLVM написана на C++ и портирована на большинство *nix-систем и Windows. Система имеет модульную структуру и может расширяться дополнительными алгоритмами трансформации (compiler passes) и кодогенераторами для новых аппаратных платформ. Пользовательский фронтенд, как правило, линкуется с LLVM и использует C++ API для генерации кода и его преобразований.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 17-Мрт-10, 17:48
	считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор gcc должна появиться и точка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Оптимизация приложения "	+/–
	Сообщение от Ariel (??), 17-Мрт-10, 20:09
	>считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор >gcc должна появиться и точка. LLVM вам не нравится свободной лицензией BSD? статью о его возможностях вообще читали?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 17-Мрт-10, 21:17
	>LLVM вам не нравится свободной лицензией BSD? Да, потом нам будут приезжать очень такие свободные тулчейны в виде блобятины под целевые платформы. При том скорее всего - под бзди бинарники никто собирать не будет, спасибо если хоть под i386 линух будет сборка, и то фифти-фифти. А то ведь может оказаться и win-only блобятина чего доброго. Ну и сорс генерации кода под целевую архитектуру зажопят - дескать, бодайтесь сами. В гробу я такую "свободу" видал, честно говоря.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	65. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 12:33
	перечетайте статью (и не только) про llvm ещё раз, т.к. у вас каша в голове. 1. llvm не имеет лексического и синтаксического анализатора для с/с++. для этой цели он задействует gcc 2. чтобы собрать нативный код под платформу ему опять же нужены gnu assembler и gnu linker (другими словами он преобразует исходники - например на с - в ассемблер, а гнушные уже соберут в бинарник) 3. в макоси не "подсистема opengl" основана на нём, он просто используется для компиляции кода шейдеров во время выполнения. не более. 4. количество поддерживаемых платформ и языков у него гораздо меньше, чем у gcc 5. если с чем и сравнивать llvm, то с платформой дотнет. но только лучше (т.к. используя гнушные утилиты можно получить нативный код) 6. у яблока (и адоба, и ...) просто не было выбора с их универсал бинари. ну и 7 - как это коррелирует с новостью? помоему никак
	Ответить \| Правка \| К родителю #38 \| Наверх \| Cообщить модератору


	67. "Оптимизация приложения "	–2 +/–
	Сообщение от аноним (?), 18-Мрт-10, 13:48
	>лучше (т.к. используя гнушные утилиты можно получить нативный код) дотнет генерирует _нативный_ код
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 14:10
	развейте свою мысль и тогда поговорим. ps: возможность такая есть. но также есть ряд причин почему компиляция полноценного .net приложения в нативный код не целесообразна. это с одной стороны. с другой стороны нативные сырцы от с/с++/асм - тоже не целевая сфера .net. в тоже время компиляция в нативный код в llvm ничем не отличается от той же компиляции например в gcc. поэтому их и сравнивают (на мой взгляд ошибочно). ценность же llvm именно в в том, что аббревиатура llvm под собой скрывает. и это как раз аналог .net. только лучше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 18-Мрт-10, 14:18
	>дотнет генерирует _нативный_ код Что сказать то хотели? В конечном итоге процы нихрена кроме нативного кода выполнять 1 фиг не умеют. Так что все так или иначе генерят нативный код весьма разными по кривизне и эффективности методами. И дальше что?
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	84. "Оптимизация приложения "	+/–
	Сообщение от Ariel (??), 18-Мрт-10, 22:55
	>у вас каша в голове статью писал не я 1, 2 LLVM не моджет иметь синтаксический или лексический анализатор, это целая инфракструктура создания компиляторов и run-time architecture, чтобы скормить ей код, его нужно транслировать в ассемблер LLVM, с помощью front-end, в качестве таковых могут выступать gcc, clang, или то, что вы напишите. Это значит, что вам при написании компилятора, пишите транслятор из своего языка в ассемблер LLVM, а трансляцией его в нативный код целевой платформы займётся LLVM. 3 статью писал не я 4 и? что касается "лишнего" bytecode, он используется для например, link-time оптимизации. http://developer.apple.com/mac/library/releasenotes/Develope... на остальную истерию юзера294 нет смысла писать
	Ответить \| Правка \| К родителю #65 \| Наверх \| Cообщить модератору


	85. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 23:44
	это гораздо ближе к истине. кроме вот этого: >а трансляцией его в нативный код целевой платформы займётся LLVM. тогда придумайте зачем понадобились гнушные ассемблер и линкер (могут быть и не гнушные)? нет. llvm - это именно то, как он и расшифровывается. если хотите, то компиляция в нативный код - это его побочная функция. универсальная? да. логичная? да. но побочная. говорят правда, что он преобразует исходный код на С/С++ в промежуточный быстрее, чем gcc. но это не так важно. да и не всё он делает. а когда сможет - не факт, что будет быстрее. если хотите, то это следующий шаг вначале после java, а потом после дотнета. конечно бродят мысли сделать нечто подобное и на базе gnu/gcc - почему нет?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Оптимизация приложения "	+/–
	Сообщение от Ariel (ok), 20-Мрт-10, 01:30
	если понимать LLVM в узком смысле, то вы правы, но >LLVM is also a collection of source code that implements the language and compilation strategy. The primary >components of the LLVM infrastructure are a GCC-based C & C++ front-end, a link-time optimization framework >with a growing set of global and interprocedural analyses and transformations, static back-ends for many popular >(and some obscure) architectures, a back-end which emits portable C code, and a Just-In-Time compilers for >several architectures. Крис как бы намекает нам, что LLVM можно понимать и несколько шире, и считать front-end и back-end частью LLVM. К сожалению, о back-end я нашел мало информации, возможно потому, что front-end`ов может быть много, а back-end на целевую архитектуру - один; испоьзуют ли утилиты llvm as и ld не знаю, но возможно, что и нет: llc - generate native machine code for a bytecode file lli - directly run a program compiled to bytecode using a JIT compiler or interpreter
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 18-Мрт-10, 20:16
	>LLVM-GCC4.2, что вам мешает его использовать и зачем Тут еще минета Джоббсу не хватает в знак признательности, или типа того. >не религия ли? Лично мне не нужны чертовы блобы в роли тулчейна. Это уже проходили, спасибо. Потом въехали мордой в стол, когда борланд стал метаться в разные стороны. Добавки от ябблов и прочих проприетарных конторок которым BSDL удобна сугубо для зажима сорцев - не надо, спасибо. >алгоритм такой: C / C++ / ObjC / compilers -> intermediate >bytecode -> LLVM -> native code Мне одному кажется что фаза с intermediate bytecode по идее лишняя и нафиг не впилась, по больщому счету? Ну то есть, если поклоняться LLVM оно может и надо, но если цель - получить от компилера бинарь - эта фаза определенно лишняя :). >LLVM — не просто очередной академический проект. Его история началась в 2000 >году в Университете Иллинойса, а теперь LLVM используют такие гиганты индустрии >как Apple и Adobe. При том обе конторы - злостные проприетарщики. Наиболее мерзкие из существующих пожалуй. Первые просто фашисты, достаточно на их ограничилово посмотреть. И там же в районе хабры какой-то мак-овец проблеял что-то вида "Эппл позволяет юзать их девелскую тулсень только под макось версий ... ". Вот извините, но такого блеяния нам не надо. Идите нафиг. Вместе с вашими богами из эппла. И блейте там дальше под их строгим надзором. Мак-овцы, блин. >В частности, на LLVM основана подсистема OpenGL в MacOS X 10.5, >а iPhone SDK использует GCC с бэкэндом на LLVM. А я юзаю обычный GCC генеря оным код под штук пять разных платформ. И мне если честно насрать что там использует эппл и адоб, потому что оно зачастую какая-то блобятина и/или не умеет генерить код так как надо мне без большого бубна и в проверенном на безглючноть виде. Ы? >Apple является одним из основных спонсоров проекта, а вдохновитель >LLVM — Крис Латтнер — теперь работает в Apple. Вот и хрен с ним с этим эпплом. Мне не нужен геморрой с тулчейном и блобятиной в нем. И чем дальше от этих фашиствующих проприетарщиков - тем проще моя жизня. Приколитесь? :) >LLVM поддерживает генерацию кода для x86, [...] Угу, пара моментов: 1) Вы забыли тут рекламный баннер воткнуть в вашей порции пиара. 2) Я ни разу в жизни не видел тулсей генерящих код LLVMом под, допустим, MIPS или хотя-бы внятных описаний как сие собрать. >LLVM написана на C++ и портирована на большинство *nix-систем и Windows. А GCC портирован на немереное количество платформ. Даже дос в качестве хохмы :). А уж как таргет у него может быть и мелочь типа Atmel AVR, Ti MSP430, простые ARM7 и Cortex и т.п. :). При том - можно взять эти тулзы и сгенерить код. >с LLVM и использует C++ API для генерации кода и его преобразований. Угу, практика показывает что чем больше наворотов - тем больше глюков. Со всеми этими преобразованиями потом поди черт ногу при отладке сломит.
	Ответить \| Правка \| К родителю #38 \| Наверх \| Cообщить модератору


	69. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 18-Мрт-10, 14:15
	>Можно. Но не обязательно все же писать все на asm. В этом треде никто и не предлагал писать на асме. Более того, тут вообще только особенности линковки обсуждались. Для тех кто на бронепоезде, намекаю: линковка строго говоря к языку программирования не особо относится: линкеру в принципе насрать как вы получили вон тот объектник. Написали ли вы его ручками в хексэдиторе, собрал ли вам его ассемблятор, сгенерил ли его сишный (а может и какой-нибудь еще) компилер и прочая. Спич шел о оптимизации размера программы и освоении азов линкера по сути. >Можно и сайты на asm писать, но пишут в основном на чем >то типа php ибо проще, быстрее и все равно все упирается >в SQL а не в скорость интерпретации php. А когда прижимает - переписывают куски на сях/плюсах, выбрасывают скуль и юзают простые но чертовски быстрые БД вида key-value (или memcached как вариант если все в оператвку умещается). >Преждевременная оптимизация зло. Дежурный принцип рапидчика? :) >80% времени выполняется 20% кода. Поэтому нормальные люди оптимизируют именно те места в которые упирается. А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например). >Такое уже есть. Нужен свой LLVM под GPL который должен придти на >смену оптимизатору gcc. Может нужен, а может и нет. Далеко не факт что сие натянет оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто дает просраться половине коммерческих компилеров под ряд архитектур. >Истина доходит, вот только конкретно вышеописанное практического смысла вообще >не имеет кроме повышения опыта автора. Оно имеет смысл - на простом примере можно научиться, блин, управлять линковкой. Поняв что и как и когда возникнет необходимость (минимальные системы, embedded, ... например) - применив оный скилл. Да и вообще от оптимизации никому хуже еще не становилось. >Вот и было бы клево чтобы он занялся более практическими вещами. Клево для кого? За такие туториалы спасибо надо говорить. Хотя да, замечено что метать бисер перед теми у кого мозг работает хило - занятие неблагодарное.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	72. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 14:54
	все верно, кроме одного: >А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например). вот выдержки - http://ru.wikipedia.org/wiki/Unix_way >Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные. >...... >Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте. более того, ранняя оптимизация - действительно зло для универсальности решений. лучше оптимизировать готовый код для сборки на конкретной платформе, чем заранее залочить себя только на одной из них и потом через костыли и грабли добиваться стандартов типа POSIX
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 18-Мрт-10, 20:38
	>>Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптимизировать любой ценой даже если ее и так хватает с запасом? Строго говоря весь этот тред в основном про оптимизацию размера программы. Путем фокусов с линкером. При том фокусы потенциально грабельные, да. Но они позволят понять как работает линкер, как компилер генерячит программу, из каких кирпичиков она собирается и потом можно с этим играться в :) >и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные. Опять же, повторяю, блин: оптимизция скорости и размера - разные сущности, зачастую противоположные по смыслу. >стабильной работы, только потом оптимизируйте. Все так, тем не менее, грамотно сархитектив и заранее вычислив очевидные потенциальные грабли - можно сильно скостить себе фазу траха с оптимизацией, или вообще от нее избавиться, ага? >более того, ранняя оптимизация - действительно зло для универсальности решений. Вполне соглашусь с этим - раньше для скорости писали на асме. Ну хоть те же VxD драйвера. И кому они теперь нужны? Правильно, 0xDEADC0DE :) >лучше оптимизировать готовый код для сборки на конкретной платформе, >чем заранее залочить себя только на одной из них и потом через костыли и >грабли добиваться стандартов типа POSIX Сильно зависит от. Подгонять какойнить код писанный допустим без учета специфики embedded под особенности оного - может быть достаточно непростым и грабельным начинанием. Скажем как делать POSIX вызовы если ФС в девайсе вообще нету?И куда они должны отправиться? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 21:14
	>Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптимизировать любой ценой даже если ее и так хватает с запасом? может быть я не так понял. но я точно уверен, что сила юниксвэй вообще и линукс в частности - следование заявленным стандартам. даже если они не совсем адекватны. это не самый лёгкий путь. но в результате он приносит плоды. в том числе и в эмбедед. зы: >Опять же, повторяю, блин: оптимизция скорости и размера - разные сущности, зачастую противоположные по смыслу. метод только один - результат не однозначен. не инвариантен. следовательно, если и применять, то только для окончательной шлифовки. да и то когда уже никак по другому.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Оптимизация приложения "	+/–
	Сообщение от минона (?), 18-Мрт-10, 21:22
	а да. в посикс нет завязок ни на фс, ни на их реализации и т.д. иногда проще в либси что-то подправить, чем в по (вы сами же их реализации и приводили). зы: это юникс. тут нет невозможного. (вспоминаю трухина и его последний коммент о том как невозможно в хп что-то там :D)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Оптимизация приложения "	+/–
	Сообщение от Аноним (-), 18-Мрт-10, 15:52
	>Поэтому нормальные люди оптимизируют именно те места в которые упирается. А еще >лучше - на фазе дизайна и ранней имплементации принимают такие решения >чтобы попросту работсло быстро сразу. Эти две фразы противоречат друг другу. Сначала приложение нужно разработать, потом узнать где оно тормозит и лишь потом оптимизировать тормозящее ибо преждевременная оптимизация зло. >Далеко не факт что сие натянет >оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным >отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто >дает просраться половине коммерческих компилеров под ряд архитектур. Факт, но также и факт что далеко не сразу. Но это перспективно и это должно появиться как аналог LLVM но под GPL, начать развиваться и постепенно придти на смену оптимизатору gcc. Больше читать этот тред не буду, комментарии в виде дерева это нечто.
	Ответить \| Правка \| К родителю #69 \| Наверх \| Cообщить модератору


	79. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 18-Мрт-10, 20:27
	>Эти две фразы противоречат друг другу. Сначала приложение нужно разработать, потом узнать >где оно тормозит и лишь потом оптимизировать тормозящее ибо преждевременная оптимизация >зло. Нормальный архитект должен прикинуть проблемные места еще на фазе проектирования и сделать все чтобы проблем было как можно меньше. Сие может очень сильно скостить потом нужду в пускании пара на фазе кодинга в аврально порядке. Ну и напротив - эпичная лажа в этой фазе воздастся нуждой в геройствовании потом. >Факт, Фактом оно будет когда я смогу взять в руки компилер А и Б и сравнить качество кодогенерации. Если А уделает Б наголову - отлично, А более хороший компилер. До тех пор - в сад! >но также и факт что далеко не сразу. У вас какие-то проблемы с логикой и причинно-следственными связями. См. выше. Не бывает софта который хорош в теории. >Но это перспективно Уточним, судя по всему это модно у ряда местных бздунов, которым очень хочется выбросить GCC который с неправильной лицензией, видите ли :). >и это должно появиться как аналог LLVM но под GPL, начать >развиваться и постепенно придти на смену оптимизатору gcc. Вот только станет ли от этого лучше - большой такой вопрос. Собственно, а какие законы природы это гарантируют? И какие реализаторы это гарантируют? oO >Больше читать этот тред не буду, комментарии в виде дерева это нечто. Коменты на опеннете - да, та еще дрянь по удобству, согласен. На большей части других ресурсов такой стиль коментов сдох годы назад в силу ряда грабель и неудобств, но тут движок по прежнему хорошо отдает девяностыми :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Оптимизация приложения "	+1 +/–
	Сообщение от mike lee (?), 17-Мрт-10, 15:44
	ты статейку то открой. автор так или иначе предлагает непортабельный код, заменяя стандартную точку входа своей. другое дело что кода там 4 строчки, но в любом случае все это должно носить только познавательный характер.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	24. "Оптимизация приложения "	+/–
	Сообщение от User294 (ok), 17-Мрт-10, 16:19
	>но в любом случае все это должно носить только познавательный характер. Когда как. В какомнить embedded такое на каждом углу. Иногда натурально бывает надо сэкономить каждый байт любой ценой, например. Скажем если надо в 2-меговую флеху затрамбовать всего пингвина с кучей демонов, экономия по 10 кило на файл врядли покажется какой-то ненужной сущностью. Особенно если окажется что образ не лезет на каки-то чертовы 50 кило а перепаивать флеху в миллионе плат на более емкую стоит астрономических бабок :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Оптимизация приложения "	+1 +/–
	Сообщение от User294 (ok), 17-Мрт-10, 14:38
	>Что называется нет предела совершенству. Есть :) программы отрицательной длины не бывают :P.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору