В заметке "Hello from a libc-free world! (http://blog.ksplice.com/2010/03/libc-free-world/)" рассмотрен вопрос неоптимальной компоновки простейшего приложения на языке Си, возможности которого ограничены присвоением переменной текста "Hello world". При компиляции такой программы в GCC результирующий исполняемый файл имеет размер 11 Кб. При попытке разобраться почему так много, выяснилось, что компилятор использует вызов libc, даже если функции данной библиотеки не используются в самой программе.При сборке "gcc -nostdlib -o hello hello.c" размер программы сократился до 1 Кб, но такая программа перестала выполняться корректно. Для исправления ситуации был сформирован упрощенный блок инициализации (подпрограмма _start). В сети также доступно более подробное руководство (http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html) по сокращению исполняемых файлов в формате ELF.
URL: http://blog.ksplice.com/2010/03/libc-free-world/
Новость: https://www.opennet.ru/opennews/art.shtml?num=25829
Что называется нет предела совершенству.
Что называется делать нечего.
Большенство программ требуют стандартную библиотеку для работы. А те, что не требуют, те проще написать на ассемблере. Извращение это все...
> А те, что не требуют, те проще написать на ассемблере.На ассемблере какого процессора, сэр? У ассемблера есть одна проблемка - он непортабельный. И собственно а вы пробовали на ассемблере писать всю программу, а не кусочки? Под линух? И как, вам это показалось очень простым начинанием? Ну-ну, языком трындеть не мешки ворочать :). А писать под линух на голом асме от и до - очень на любителя. Не хочу ничего сказать но под операционки писанные на сях, удобно писать на сях. На асме получается довольно колебательно в общем случае.
да ладно, практического смысла это имеет мало. лучше бы скорость загрузки библиотек в память увеличили и в gcc оптимизатор в отдельный проект выделили по типа LLVM чтобы его можно было независимо развивать
> практического смысла это имеет малоКогда как. Вот немного лирики... http://www.wasm.ru/article.php?article=onebyte
(в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...)> лучше бы скорость загрузки библиотек в память увеличили
Если вас напрягает именно этот аспект - курить маны про прелинкинг, например. Да и чем меньше библиотек грузить - тем меньше их время загрузки. Логично? :)
> и в gcc оптимизатор в отдельный проект выделили по типа LLVM
А зачем все под 1 гребенку то? Есть железобетонная уверенность что так - лучше и баста? И для кого лучше? И почему? Да и строго говоря, вы как бы вы о compile-time оптимизации кода, а тут спич был в основном о link-time оптимизации его компоновки. Как бы слегка разные сущности, а? Даже не пересекающиеся толком (как минимум в классическом дизайне компилеров).
>(в общем зажирается народец, мозг отключает, начинает мыслить как быдло - стыдно, а?...)тот кто мыслит как быдло пишет на жабе и C#
>А зачем все под 1 гребенку то? Есть железобетонная уверенность что так
>- лучше и баста? И для кого лучше? И почему?потому что тогда это будет отдельный проект который можно будет развивать независимо.
помоему это главный плюс LLVM. нужно то-же только под GPL.
>Как бы слегка разные сущности, а?разные. я о том что силы не туда тратят
>тот кто мыслит как быдло пишет на жабе и C#Мыслить как быдло можно в принципе на любом языке. Быдло предпочитает упомянутые т.к. там дескать думать своей головой поменьше надо. А быдло думать головой не умеет и не любит. Тем не менее, судя по некоторым программам, никакие законы природы не запрещают генерить быдлокод и на сях. Да, это случается реже, т.к. тулсы труднее для освоения дубами. Но - случается, как ни странно.
>потому что тогда это будет отдельный проект который можно будет развивать независимо.
>помоему это главный плюс LLVM. нужно то-же только под GPL.Хм... прикрутить LLVM как плагин к GCC? :) Если, конечно, оно того вообще будет стоить (что как бы еще не факт и как говорится, "будем посмотреть").
>>Как бы слегка разные сущности, а?
>разные. я о том что силы не туда тратятТуториал по основам и просто проверка мастерства - вполне нормально. А что до затрат сил - как бы это очень разные виды оптимизации и совсем не факт что те кто умеет линк-тайм оптимизацию заодно является гурой по кодогенерации и оптимизации оной. Странно что столь простая истина не доходит.
>Мыслить как быдло можно в принципе на любом языке.Можно. Но не обязательно все же писать все на asm.
Можно и сайты на asm писать, но пишут в основном на чем то типа php ибо проще, быстрее и все равно все упирается в SQL а не в скорость интерпретации php.
Преждевременная оптимизация зло. 80% времени выполняется 20% кода.>Хм... прикрутить LLVM как плагин к GCC? :)
Такое уже есть. Нужен свой LLVM под GPL который должен придти на смену оптимизатору gcc.
Как раньше были всякие egcs который влился в gcc.>Странно что столь простая истина не доходит.
Истина доходит, вот только конкретно вышеописанное практического смысла вообще не имеет кроме повышения опыта автора. Вот и было бы клево чтобы он занялся более практическими вещами.
>Такое уже есть. Нужен свой 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 для генерации кода и его преобразований.
считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор gcc должна появиться и точка.
>считайте что религия. свободная GPL альтернатива LLVM которая заменит в перспективе оптимизатор
>gcc должна появиться и точка.LLVM вам не нравится свободной лицензией BSD? статью о его возможностях вообще читали?
>LLVM вам не нравится свободной лицензией BSD?Да, потом нам будут приезжать очень такие свободные тулчейны в виде блобятины под целевые платформы. При том скорее всего - под бзди бинарники никто собирать не будет, спасибо если хоть под i386 линух будет сборка, и то фифти-фифти. А то ведь может оказаться и win-only блобятина чего доброго. Ну и сорс генерации кода под целевую архитектуру зажопят - дескать, бодайтесь сами. В гробу я такую "свободу" видал, честно говоря.
перечетайте статью (и не только) про llvm ещё раз, т.к. у вас каша в голове.
1. llvm не имеет лексического и синтаксического анализатора для с/с++. для этой цели он задействует gcc
2. чтобы собрать нативный код под платформу ему опять же нужены gnu assembler и gnu linker (другими словами он преобразует исходники - например на с - в ассемблер, а гнушные уже соберут в бинарник)
3. в макоси не "подсистема opengl" основана на нём, он просто используется для компиляции кода шейдеров во время выполнения. не более.
4. количество поддерживаемых платформ и языков у него гораздо меньше, чем у gcc
5. если с чем и сравнивать llvm, то с платформой дотнет. но только лучше (т.к. используя гнушные утилиты можно получить нативный код)
6. у яблока (и адоба, и ...) просто не было выбора с их универсал бинари.
ну и 7 - как это коррелирует с новостью? помоему никак
>лучше (т.к. используя гнушные утилиты можно получить нативный код)дотнет генерирует _нативный_ код
развейте свою мысль и тогда поговорим.
ps:
возможность такая есть. но также есть ряд причин почему компиляция полноценного .net приложения в нативный код не целесообразна. это с одной стороны.
с другой стороны нативные сырцы от с/с++/асм - тоже не целевая сфера .net.
в тоже время компиляция в нативный код в llvm ничем не отличается от той же компиляции например в gcc. поэтому их и сравнивают (на мой взгляд ошибочно). ценность же llvm именно в в том, что аббревиатура llvm под собой скрывает. и это как раз аналог .net. только лучше.
>дотнет генерирует _нативный_ кодЧто сказать то хотели? В конечном итоге процы нихрена кроме нативного кода выполнять 1 фиг не умеют. Так что все так или иначе генерят нативный код весьма разными по кривизне и эффективности методами. И дальше что?
>у вас каша в головестатью писал не я
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 нет смысла писать
это гораздо ближе к истине. кроме вот этого:
>а трансляцией его в нативный код целевой платформы займётся LLVM.тогда придумайте зачем понадобились гнушные ассемблер и линкер (могут быть и не гнушные)?
нет. llvm - это именно то, как он и расшифровывается.
если хотите, то компиляция в нативный код - это его побочная функция.
универсальная? да. логичная? да. но побочная.
говорят правда, что он преобразует исходный код на С/С++ в промежуточный быстрее, чем gcc. но это не так важно. да и не всё он делает. а когда сможет - не факт, что будет быстрее.
если хотите, то это следующий шаг вначале после java, а потом после дотнета.
конечно бродят мысли сделать нечто подобное и на базе gnu/gcc - почему нет?
если понимать 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
>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 для генерации кода и его преобразований.
Угу, практика показывает что чем больше наворотов - тем больше глюков. Со всеми этими преобразованиями потом поди черт ногу при отладке сломит.
>Можно. Но не обязательно все же писать все на asm.В этом треде никто и не предлагал писать на асме. Более того, тут вообще только особенности линковки обсуждались. Для тех кто на бронепоезде, намекаю: линковка строго говоря к языку программирования не особо относится: линкеру в принципе насрать как вы получили вон тот объектник. Написали ли вы его ручками в хексэдиторе, собрал ли вам его ассемблятор, сгенерил ли его сишный (а может и какой-нибудь еще) компилер и прочая. Спич шел о оптимизации размера программы и освоении азов линкера по сути.
>Можно и сайты на asm писать, но пишут в основном на чем
>то типа php ибо проще, быстрее и все равно все упирается
>в SQL а не в скорость интерпретации php.А когда прижимает - переписывают куски на сях/плюсах, выбрасывают скуль и юзают простые но чертовски быстрые БД вида key-value (или memcached как вариант если все в оператвку умещается).
>Преждевременная оптимизация зло.Дежурный принцип рапидчика? :)
>80% времени выполняется 20% кода.
Поэтому нормальные люди оптимизируют именно те места в которые упирается. А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например).
>Такое уже есть. Нужен свой LLVM под GPL который должен придти на
>смену оптимизатору gcc.Может нужен, а может и нет. Далеко не факт что сие натянет оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто дает просраться половине коммерческих компилеров под ряд архитектур.
>Истина доходит, вот только конкретно вышеописанное практического смысла вообще
>не имеет кроме повышения опыта автора.Оно имеет смысл - на простом примере можно научиться, блин, управлять линковкой. Поняв что и как и когда возникнет необходимость (минимальные системы, embedded, ... например) - применив оный скилл. Да и вообще от оптимизации никому хуже еще не становилось.
>Вот и было бы клево чтобы он занялся более практическими вещами.
Клево для кого? За такие туториалы спасибо надо говорить. Хотя да, замечено что метать бисер перед теми у кого мозг работает хило - занятие неблагодарное.
все верно, кроме одного:
>А еще лучше - на фазе дизайна и ранней имплементации принимают такие решения чтобы попросту работсло быстро сразу. Кроме того - вы про оптимизацию на скорость а тут спич про оптимизацию на размер. Надо быть удивительно дубовым субъектом чтобы не понять что это совершенно разные типы оптимизации. Зачастую - взаимоисключающие (тот же unroll циклов поднимает скорость выполнения ценой распухания программы, например).вот выдержки - http://ru.wikipedia.org/wiki/Unix_way
>Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
>......
>Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.более того, ранняя оптимизация - действительно зло для универсальности решений.
лучше оптимизировать готовый код для сборки на конкретной платформе, чем заранее залочить себя только на одной из них и потом через костыли и грабли добиваться стандартов типа POSIX
>>Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите,Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптимизировать любой ценой даже если ее и так хватает с запасом? Строго говоря весь этот тред в основном про оптимизацию *размера* программы. Путем фокусов с линкером. При том фокусы потенциально грабельные, да. Но они позволят понять как работает линкер, как компилер генерячит программу, из каких кирпичиков она собирается и потом можно с этим играться в :)
>и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.Опять же, повторяю, блин: оптимизция скорости и размера - разные сущности, зачастую противоположные по смыслу.
>стабильной работы, только потом оптимизируйте.
Все так, тем не менее, грамотно сархитектив и заранее вычислив очевидные потенциальные грабли - можно сильно скостить себе фазу траха с оптимизацией, или вообще от нее избавиться, ага?
>более того, ранняя оптимизация - действительно зло для универсальности решений.
Вполне соглашусь с этим - раньше для скорости писали на асме. Ну хоть те же VxD драйвера. И кому они теперь нужны? Правильно, 0xDEADC0DE :)
>лучше оптимизировать готовый код для сборки на конкретной платформе,
>чем заранее залочить себя только на одной из них и потом через костыли и
>грабли добиваться стандартов типа POSIXСильно зависит от. Подгонять какойнить код писанный допустим без учета специфики embedded под особенности оного - может быть достаточно непростым и грабельным начинанием. Скажем как делать POSIX вызовы если ФС в девайсе вообще нету?И куда они должны отправиться? :)
>Подождите, уважаемый минона, а разве я вообще утверждал что скорость надо оптимизировать любой ценой даже если ее и так хватает с запасом?может быть я не так понял.
но я точно уверен, что сила юниксвэй вообще и линукс в частности - следование заявленным стандартам. даже если они не совсем адекватны.
это не самый лёгкий путь. но в результате он приносит плоды. в том числе и в эмбедед.
зы:
>Опять же, повторяю, блин: оптимизция скорости и размера - разные сущности, зачастую противоположные по смыслу.метод только один - результат не однозначен. не инвариантен.
следовательно, если и применять, то только для окончательной шлифовки. да и то когда уже никак по другому.
а да.
в посикс нет завязок ни на фс, ни на их реализации и т.д.
иногда проще в либси что-то подправить, чем в по (вы сами же их реализации и приводили).
зы:
это юникс. тут нет невозможного.
(вспоминаю трухина и его последний коммент о том как невозможно в хп что-то там :D)
>Поэтому нормальные люди оптимизируют именно те места в которые упирается. А еще
>лучше - на фазе дизайна и ранней имплементации принимают такие решения
>чтобы попросту работсло быстро сразу.Эти две фразы противоречат друг другу. Сначала приложение нужно разработать, потом узнать где оно тормозит и лишь потом оптимизировать тормозящее ибо преждевременная оптимизация зло.
>Далеко не факт что сие натянет
>оптимизатор GCCы. Как минимум вот так вот сразу, влегкую, с заметным
>отрывом, будет без багов и глюков, etc. Нынче гнутый си запросто
>дает просраться половине коммерческих компилеров под ряд архитектур.Факт, но также и факт что далеко не сразу. Но это перспективно и это должно появиться как аналог LLVM но под GPL, начать развиваться и постепенно придти на смену оптимизатору gcc.
Больше читать этот тред не буду, комментарии в виде дерева это нечто.
>Эти две фразы противоречат друг другу. Сначала приложение нужно разработать, потом узнать
>где оно тормозит и лишь потом оптимизировать тормозящее ибо преждевременная оптимизация
>зло.Нормальный архитект должен прикинуть проблемные места еще на фазе проектирования и сделать все чтобы проблем было как можно меньше. Сие может очень сильно скостить потом нужду в пускании пара на фазе кодинга в аврально порядке. Ну и напротив - эпичная лажа в этой фазе воздастся нуждой в геройствовании потом.
>Факт,
Фактом оно будет когда я смогу взять в руки компилер А и Б и сравнить качество кодогенерации. Если А уделает Б наголову - отлично, А более хороший компилер. До тех пор - в сад!
>но также и факт что далеко не сразу.
У вас какие-то проблемы с логикой и причинно-следственными связями. См. выше. Не бывает софта который хорош в теории.
>Но это перспективно
Уточним, судя по всему это модно у ряда местных бздунов, которым очень хочется выбросить GCC который с неправильной лицензией, видите ли :).
>и это должно появиться как аналог LLVM но под GPL, начать
>развиваться и постепенно придти на смену оптимизатору gcc.Вот только станет ли от этого лучше - большой такой вопрос. Собственно, а какие законы природы это гарантируют? И какие реализаторы это гарантируют? oO
>Больше читать этот тред не буду, комментарии в виде дерева это нечто.
Коменты на опеннете - да, та еще дрянь по удобству, согласен. На большей части других ресурсов такой стиль коментов сдох годы назад в силу ряда грабель и неудобств, но тут движок по прежнему хорошо отдает девяностыми :)
ты статейку то открой. автор так или иначе предлагает непортабельный код, заменяя стандартную точку входа своей. другое дело что кода там 4 строчки, но в любом случае все это должно носить только познавательный характер.
>но в любом случае все это должно носить только познавательный характер.Когда как. В какомнить embedded такое на каждом углу. Иногда натурально бывает надо сэкономить каждый байт любой ценой, например. Скажем если надо в 2-меговую флеху затрамбовать всего пингвина с кучей демонов, экономия по 10 кило на файл врядли покажется какой-то ненужной сущностью. Особенно если окажется что образ не лезет на каки-то чертовы 50 кило а перепаивать флеху в миллионе плат на более емкую стоит астрономических бабок :)
>Что называется нет предела совершенству.Есть :) программы отрицательной длины не бывают :P.
Ага, идеальна та программа, которая не написана
Хм, может там еще есть что соптимизировать?
ага, можно. можно выкинуть нафик строку. назвать прогу "Хелло ворлд" и выводить имя исполняемого файла из переменных окружения.
Ж:-P
Как будто неоптимизированные программы закончились, принялись за столь полезную программу, как Hello World.
ИМХО, это можно засчитать за вполне вменяемый туториал по поводу того как и что подкрутить в компилере чтобы стало поменьше размером. При том учиться это делать на мелкой проге типа hello world в 100500 раз проще чем пытаться с места в карьер заоптимизировать многомеговое монстрило. Вы как, вашу первую программу тоже писали сразу на много мегабайт весом и со всеми наворотами, с миллионами строк исходника?
многомеговое монстрило по любому будет завязано на libc - бессмыленно это.
>многомеговое монстрило по любому будет завязано на libc - бессмыленно это.Бессмысленно - пытаться освоить азы на сложной и навороченной конструкции. Это как раз логично делать не чем-то предельно простом. Если вы впервые в жизни сели за руль - очень странно будет сесть за руль самого крутого гоночного болида и немедленно попытаться поставить мировой рекорд на извилистой трассе. Скорее всего это ни к чеиу хорошему не приведет и ваши кишки придется отскребать от асфальта.
ЗЫ а если вам впадлу учить основы работы компилера или думалки на это не хватает - так и скажите, паясничать и оправдывться совершенно не обязательно.
>Бессмысленно - пытаться освоить азы на сложной и навороченной конструкции.В реальной программе в любом случае будет зависимость на libc. Это не "hello world".
Это все забавно почитать чтобы понять что происходит (если не знаешь) но вот практического смысла в реальной программе это не имеет.
>Это все забавно почитать чтобы понять что происходит (если не знаешь) но
>вот практического смысла в реальной программе это не имеет.практический смысл имеет переработка гцц, дабы тот перестал вываливать неэффективный код.
пройди вступительный тест в разрабы gcc и переработай его.
К link-time оптимизации весь этот бред вообще никак не относится. А hand-optimized asm в критичных кусках всяко будет заруливать ту мешанину которую компилеры генерят. Потому что как ни крути а иногда даже самый хороший оптимизатор может весьма хорошо протупить.
>В реальной программе в любом случае будет зависимость на libc.Далеко не в любом. Скажем в embedded отсутствие стандартной либы вообще норма жизни. Или завязка на какойнить минимальный uclibc.
>Это не "hello world".
So what?
>Это все забавно почитать чтобы понять что происходит (если не знаешь) но
>вот практического смысла в реальной программе это не имеет.Это имеет смысл проделать чтобы понять как работает компилер, как он генерячит код, как это все линкуется в единое целое и так далее. Иногда сие весьма актуально. Особенно в embedded где зачастую код пашет сам по себе, оси и либ нету а результат надо получить как какой-то бинарь с предсказуемыми смещениями, ожидающий нужные адреса и прочая. Си (особенно gcc) все эти выкрутасы позволяет только так. И да, это по сути единственная альтернатива траху с написанием всего и вся на асме (что не только геморройно но еще и абсолтно не портабельно).
почему это в любом? а если dietlibc или ulibc
Вот бы так еще ядро оптимизировали...
А вы знаете, что если в PHP вместо двойных кавычек использовать одинарные, то парсер не будет пытаться найти и подставить переменные в этой строке. А ведь это драгоценные такты!
>А ведь это драгоценные такты!потому и написали компилятор PHP, потому что спрыгивать с этого дерьма на что-то более быстрое (когда все уперлось в него) еще дольше чем написать компилятор
>>А ведь это драгоценные такты!
>
>потому и написали компилятор PHP, потому что спрыгивать с этого дерьма на
>что-то более быстрое (когда все уперлось в него) еще дольше чем
>написать компиляторА вам не кажется, что если бы он был таким дерьмом, то на нём не писало бы такое количество людей?
>А вам не кажется, что если бы он был таким дерьмом, то на нём не писало бы такое количество людей?Миллионы мух не могут ошибаться в дерьме определенно что-то есть?
>Миллионы мух не могут ошибаться в дерьме определенно что-то есть?Ничего не понял, знаки препинания помогут тебе вдохнуть смысл в сей набор слов.
>>Миллионы мух не могут ошибаться в дерьме определенно что-то есть?
>
>Ничего не понял, знаки препинания помогут тебе вдохнуть смысл в сей набор
>слов.Вы правда никогда не слышали это выражение?
> А вам не кажется, что если бы он был таким дерьмом, то на нём не писало бы такое количество людей?нет не кажется.
Про Windows напомнить? Быдло всегда ищет где поменьше думать надо.
>Про Windows напомнить? Быдло всегда ищет где поменьше думать надо.OMG, это в Пыхе-то думать не надо? Да, там нет строгой типизации, ну и что? Думать там приходится не меньше, чем в других языках, если хочешь написать пристойный код.
>>Про Windows напомнить? Быдло всегда ищет где поменьше думать надо.
>
>OMG, это в Пыхе-то думать не надо? Да, там нет строгой типизации,
>ну и что? Думать там приходится не меньше, чем в других
>языках, если хочешь написать пристойный код.в исходники php загляните чтобы говорить о его "качестве".
>в исходники php загляните чтобы говорить о его "качестве".И что там, в исходниках? Зашифрованный призыв Сатаны?
там почерк создателей, иногда полезно познакомиться чтобы не поддаваться лишним иллюзиям. Не самое страшное конечно, да и другого более-менее работоспособного пока нет, так что используем какой есть. Без лишних восхищений.
>там почерк создателей, иногда полезно познакомиться чтобы не поддаваться лишним иллюзиям. Не
>самое страшное конечно, да и другого более-менее работоспособного пока нет, так
>что используем какой есть. Без лишних восхищений.Во-первых, у них есть нормальное коммунитэ, которое достаточно успешно патчит и багрепортит. Особых восторгов Пыхом я не проявлял кмк?
>>там почерк создателей, иногда полезно познакомиться чтобы не поддаваться лишним иллюзиям. Не
>>самое страшное конечно, да и другого более-менее работоспособного пока нет, так
>>что используем какой есть. Без лишних восхищений.
>
>Во-первых, у них есть нормальное коммунитэ, которое достаточно успешно патчит и багрепортит.
>Особых восторгов Пыхом я не проявлял кмк?кстати, Вам не доводилось им багрепорты слать? Субъективно конечно, может это только мне не везло, не знаю, но такое впечатление что не очень они к своей комьюнити относятся, будто это тебе а не им нужно чтобы их поделие у всех нормально работало.
>кстати, Вам не доводилось им багрепорты слать? Субъективно конечно, может это только
>мне не везло, не знаю, но такое впечатление что не очень
>они к своей комьюнити относятся, будто это тебе а не им
>нужно чтобы их поделие у всех нормально работало.Доводилось, правда один и по хелпу, а не по сырцам. Относятся нормально, пофиксили, правда не сразу, так как мелочь была.
как связана реализация языка (интерпретатор) с качеством написанного на нем кода?
В этом мире все связано. Хуже интерпретатор - медленнее исполняется код. Неэффективная реализация не будет использоваться в высоконагруженных системах -> языком будут пользоваться меньше профессионалов. В итоге на нем пишут только люди неспособные освоить нормальный инструмент -> качество кода соответствующее. А если рассмотреть PHP как язык, он изначально рассчитывался на непрофессионалов. Все это влияет и на язык и тянет его еще дальше вниз.
>А если рассмотреть PHP как язык, он изначально рассчитывался на непрофессионаловтрололо.
кстати, sql тоже изначально рассчитан на непрофессионалов. отказываешься от sql?
>>А если рассмотреть PHP как язык, он изначально рассчитывался на непрофессионалов
>
>трололо.
>
>кстати, sql тоже изначально рассчитан на непрофессионалов. отказываешься от sql?И кто его сечас собственно как язык программирования использует? Это скорее протокол, для взаимодействия приложения с rdbm сервером.
+1да, а ещё количество идиотских багов, нестабильность языка и настроек дефолтного php.ini между версиями и отношение авторов самого php к безопасности приложений которые на нём пишутся - не очень-то он после этого профессионально выглядит. А потом, по поводу каждого "новшества" вроде тех-же неймспейсов в 5.3 - такое чуство что они последние лет десять всякие вкусности из перла и явы кусочек за кусочком к себе перетаскивают которые там с самого начала были - а что, сразу они про них не знали, или кишка тонковата?
очень наивно
местечковые гуру зрят в корень.
все переходим на perl6
А кто вам сказал, что на нем пишут?
99.9% Веб-дезигнеров никогда с нуля не писали - Google -> Шаблоны для сайта скачать. :)
А потом узнают, что это хрень называется PHP, Ruby, JS ...
И давай кричать на сайтах "- Я знаю кунг-фу!!!"
>А кто вам сказал, что на нем пишут?
>99.9% Веб-дезигнеров никогда с нуля не писали - Google -> Шаблоны для сайта скачать. :)
>А потом узнают, что это хрень называется PHP, Ruby, JS ...
>И давай кричать на сайтах "- Я знаю кунг-фу!!!"Форум для разработчиков сказал.
>>А кто вам сказал, что на нем пишут?
>>99.9% Веб-дезигнеров никогда с нуля не писали - Google -> Шаблоны для сайта скачать. :)
>>А потом узнают, что это хрень называется PHP, Ruby, JS ...
>>И давай кричать на сайтах "- Я знаю кунг-фу!!!"
>
>Форум для разработчиков сказал.Они-то и есть 1%
[:::]
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
http://bsd.opennet.ru/openforum/vsluhforumID9/3022.html
И далее -- http://google.ru/search?q=assembler+linux+elf везде.
Странно, что на самом опеннете, никто ничего не искал похожего, а ведь есть пост "Борьба за уменьшения размера (до 300 байт!) программы "Hello,World" (optimization)" -- https://www.opennet.ru/base/dev/smallest_code.txt.html, сам по нему с gcc разбирался.
>Странно, что на самом опеннете, никто ничего не искал похожегоНу дык, даже первую страницу гугля лениво просматривать, не то что подбирать более релевантные запросыP))
---Война-то уже дааавно кончилась, а поезда всё везут и везут раненных анонимов, оптимизирующин на Hello.World[:::>
Наконец-то опомнились. Теперь осталось оптимизировать всего-то миллионы программ.
Золотые слова.
подобные туториалы есть и для виндов, вот это я использовал для написания дипломки. http://uinc.ru/articles/28/
Муха-ха - вспомнилась молодость ...FIDO ... анологичный срач и как результат MS-DOS'овский .com длиной 26 байт включая знаменитую строку ... :)
Прикольно - этот hello, world, собранный на FreeBSD занимает по умолчанию в два раза меньше места, чем в linux.
>Прикольно - этот hello, world, собранный на FreeBSD занимает по умолчанию в
>два раза меньше места, чем в linux.Там может выравнивание секций elf'а отличаться по дефолту. В исполняемых файлах (elf и pe), порой бывает некоторое кол-во мусора ( http://www.codenet.ru/progr/formt/elf_pe.php ):
>>Некоторые особенности так же связаны со страничной организацией памяти.
>>ELF файлы линкуются таким образом, что границы и размеры секций приходятся на 4-х килобайтные блоки файла.
>>А в PE формате, не смотря на то, что сам формат позволяет выравнивать секции на 512 байт, используется выравнивание секций на 4к, меньшее выравнивание в Windows не считается корректным.Здесь, правда не тот случай -- сама программа меньше 4к. :-)
Надо просто сравнить скрипты линкера, и несколько подкрутив, думаю, можно получить сравнимый с фряшным размер и в пингвине.
для этого надо проверить, какие секции в бинарники остаются. а в целом, про удаление ненужностей:http://timelessname.com/elfbin/
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
http://www.codebreakers-journal.com/content/view/280/97/
реальный софт тащит за собой такую кучу библиотек что такая оптимизация не имеет смысла...
хотя нет, имеет-для вирей например :-D