The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Компания Apple прекращает возврат наработок в GCC ?, opennews (ok), 10-Сен-10, (0) [смотреть все]

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


2. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от Аноним (-), 10-Сен-10, 21:20 
А что gcc является основным инструментом при разработке под MacOS ?
Ответить | Правка | Наверх | Cообщить модератору

4. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от Аноним (-), 10-Сен-10, 21:30 
Вообще то да. GCC и CLANG
Ответить | Правка | Наверх | Cообщить модератору

64. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от аноним (?), 10-Сен-10, 22:39 
да уже какбэ и нет - http://developer.apple.com/technologies/tools/whats-new.html...
>what's new in x-code 4.......
>LLVM Compiler 2.0
>The LLVM compiler is the next-generation, open source compiler technology, being used in high-performance projects around the world, and is led by engineers on Apple’s compiler team. With LLVM compiler 2.0, the full compiler stack - from the front end parser, to the back end code optimizer - completely supports C, Objective-C, and C++.
>LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster.

ну как бы воспользовались пока была нужда, а теперь можно уже и не заигрывать с сообществом.

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

62. "Компания Apple прекращает возврат наработок в GCC ?"  –5 +/
Сообщение от arcade (ok), 10-Сен-10, 22:36 
>А что gcc является основным инструментом при разработке под MacOS ?

Уже нет, их задрало что оно дико тупит на больших файлах. Теперь вот свой компилятор подняли.

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

67. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от аноним (?), 10-Сен-10, 22:42 
задрало их явно не это :D
зы:
тут вот oebs от оракла идёт на ~40 dvd для линуха. ничего, не пужаются. :D
Ответить | Правка | Наверх | Cообщить модератору

188. "Компания Apple прекращает возврат наработок в GCC ?"  +1 +/
Сообщение от User294 (ok), 11-Сен-10, 12:06 
>Уже нет, их задрало что оно дико тупит на больших файлах.

1. Это какого же размера должен быть файл чтобы гцц на нем ступил?
2. За такой кодинг стайл без разбивки на сущности - надо подвешивать за выступающие части тела и оставлять на съедение мухам. Вы когда-нить пробовали въехать в сишный файл где 250 кило одним куском? Я пробовал. Это ужасно. Давайте вон линух выпустим одним жиииииирным сишным файлом? :)

> Теперь вот свой компилятор подняли.

Жаба и нежелание делиться творят чудеса велосипедостроения у проприетарщиков.

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

194. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от Школьник (ok), 11-Сен-10, 12:17 
Про метапрограммирование благородный дон когда-нибудь слышал? Про то, что есть программы, генерирующие другие программы?
Ответить | Правка | Наверх | Cообщить модератору

195. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от fr0steremail (ok), 11-Сен-10, 12:20 
>Про метапрограммирование благородный дон когда-нибудь слышал? Про то, что есть программы, генерирующие
>другие программы?

Такие чудеса получаются иногда.

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

198. "(offtopic) петаграммирование"  +/
Сообщение от Michael Shigorinemail (ok), 11-Сен-10, 12:27 
>Про метапрограммирование благородный дон когда-нибудь слышал?
>Про то, что есть программы, генерирующие другие программы?

Дяденька Школьник, здесь многие про МП не только слышали :)

Тут вот пилю нечто, порождающее дистрибутивные профили, из которых затем можно собирать более или менее непохожие друг на друга дистрибутивы (http://www.altlinux.org/Mkimage/Profiles/next и http://www.altlinux.org/WhiteLabel)...

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

234. "(offtopic) петаграммирование"  +3 +/
Сообщение от Школьник (ok), 11-Сен-10, 17:55 
Я не сомневаюсь, что здесь знающих о МП много. Мой комментарий относился только к User294 и в основном вот к этому:

>2. За такой кодинг стайл без разбивки на сущности - надо подвешивать за выступающие части
>тела и оставлять на съедение мухам. Вы когда-нить пробовали въехать в сишный файл где 250
>кило одним куском? Я пробовал. Это ужасно. Давайте вон линух выпустим одним жиииииирным
>сишным файлом? :)

Что делать человеку, у которого генерируется код, например, из спецификации конечного автомата? Особенно когда у него нет времени/возможности/способностей подправить генератор и заставить его генерировать вместо одного несколько модулей компиляции?

Я могу еще согласиться с тем, что при кривом проектировании сложного проекта часто возникают излишние межмодульные зависимости. И получается, к примеру, в начале каждого C++-файла по 15 include'ов, причем они еще и разные, и не всегда даже прекомпилированные заголовки спасают. В итоге после препроцессора модуль компиляции такой здоровый, что любой компилятор, а не только gcc, будет тормозить и кушать память.

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

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

259. "(offtopic) петаграммирование"  +/
Сообщение от Школьник (ok), 12-Сен-10, 00:29 
>можешь конечно попробовать доказать, что это политический ход (у любителей бзд - эппл,
>гугля - это принято), но всё же попробуй.

Лично тебе я ничего не должен доказывать. Мне без разницы, был ли это политический ход или нет.

Альтернатива здесь - либо llvm, у которого свои проблемы, либо улучшение gcc. Хотел бы я в этом поучаствовать, но даже Dragon Book так до сих пор и не прочитал. Хотя не уверен, что с моими способностями смог бы сделать лучше, чем то, что сейчас в gcc, даже если бы и прочитал.

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

283. "(offtopic) петаграммирование"  +/
Сообщение от Школьник (ok), 12-Сен-10, 17:38 
>но критиковать нужно аргументированно. а то получается развёрнутый, но с тем же
>смыслом вариант "не_нужен".

Я нигде не говорил, что gcc "не нужен". Более того, я нигде даже не пожаловался на его скорость, поскольку имею возможность периодически сравнивать время его работы с Microsoft C/C++ compiler, и сравнение по моим личным ощущениям получается не в пользу последнего.

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

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

287. "(offtopic) петаграммирование"  +/
Сообщение от аноним (?), 12-Сен-10, 19:43 
>Я нигде не говорил, что gcc "не нужен". Более того, я нигде даже не пожаловался на его скорость, поскольку имею возможность периодически сравнивать время его работы с Microsoft C/C++ compiler, и сравнение по моим личным ощущениям получается не в пользу последнего.

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

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

291. "(offtopic) петаграммирование"  –2 +/
Сообщение от аноним (?), 12-Сен-10, 21:11 
Тем не менее, приложения, собранные родным микрософт компилером в составе экспресс выпуска студии, работают лучше, чем собранные гсс, такой вот факт, невзирая на приятную для некоторых лицензию
Ответить | Правка | Наверх | Cообщить модератору

298. "(offtopic) петаграммирование"  –1 +/
Сообщение от аноним (?), 12-Сен-10, 23:11 
ложь. вот такой вот факт.
зы:
вы даже не знаете о чём говорите. иначе сформулировали бы иначе.
Ответить | Правка | Наверх | Cообщить модератору

299. "(offtopic) петаграммирование"  –2 +/
Сообщение от аноним (?), 12-Сен-10, 23:15 
>приложения, собранные родным микрософт компилером

ну если он вам родственник, то... сразу видно - объективное мнение.

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

297. "(offtopic) петаграммирование"  +/
Сообщение от fr0ster (??), 12-Сен-10, 23:05 
>User294 высказал сомнение в целесообразности размещения больших кусков кода в одном файле,
>я же просто указал на то, что не всегда и не
>у всех есть возможность избежать этого. Что я сделал не так?
>

И он таки прав. А метапрограммирование тут нисколько ему не противоречит.

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

620. "(offtopic) петаграммирование"  +/
Сообщение от User294 (ok), 23-Сен-10, 01:25 
>User294 высказал сомнение в целесообразности размещения больших кусков кода в одном файле,
>я же просто указал на то, что не всегда и не у всех есть возможность избежать этого.

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

Лично моя точка зрения:
1) Куски кода почти в мег на вход компилера в общем то слегка идиотизм. Безусловно, можно еще и не так выгнуться. Можно и 100 мегов нагенерить - дурное дело не хитрое. Только на все краевые случаи такого плана не надергаешься. Компилер штука фичастая, си и тем более плюсы позволяют архидофига всего. Может я завтра инициализированный массив на 100 мегабайтов захочу. А послезавтра - пару миллионов переменных мне отсыпьте пожалуйста. И десяток-другой тыщ функций заверните. И чтоб быстро, быстро! :) Должны ли авторы компилера этим заморачиваться? ИМХО только в случае когда они почти достигли идеала и более важных дел у них не осталось (а такое вообще бывает?).

2) Почему-то все кто обсирает gcc слегка забывают одну мелочь. Альтернативу указать. Ну да - тыкают пальцем в шланг, только вот почему-то все как один забывают доложить о том что случится если такие простыни на метр ему на вход подать. Что как-то не очень красиво выглядит со стороны.

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

203. "Компания Apple прекращает возврат наработок в GCC ?"  –4 +/
Сообщение от User294 (ok), 11-Сен-10, 12:33 
>Про метапрограммирование благородный дон когда-нибудь слышал? Про то, что есть программы, генерирующие
>другие программы?

Слышал, только так и не понял вашу мыслю - вы считаете нормальным если компилеру скармливается многометровая портянка? Или чего?

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

211. "Компания Apple прекращает возврат наработок в GCC ?"  +2 +/
Сообщение от Andrew Kolchoogin (?), 11-Сен-10, 13:04 
Хм.
Я так погляжу, User294 никогда ничего сам не компилировал.
Ибо, если бы компилировал, слышал бы про такой чудесный программный продукт, как OpenH323. Е про его преемника, Opal.
Там C++'ные исходники генерируются из ASN.1 грамматик специальным кодогенератором. И на моих серверах их можно собрать только от root'а. Потому, что пользователям через login.conf поставлены разумные лимиты на виртуальную память.
И попытка собрать OpenH323 (Opal) -- единственная задача, где этих лимитов пользователю не хватает -- gcc вываливается по "virtual memory exhausted".
А C++'ничек-то -- всего каких-то 800 килобайт получается. GCC его "пережёвывает" примерно 20 минут с -O (с -O2 OpenH323 вообще не собирается), отжирая примерно полтора гигабайта виртуальной памяти.
Ответить | Правка | Наверх | Cообщить модератору

231. "Компания Apple прекращает возврат наработок в GCC ?"  –1 +/
Сообщение от User294 (ok), 11-Сен-10, 16:06 
>Хм. Я так погляжу, User294 никогда ничего сам не компилировал.

(ехидно глядя на запущеный Kate и лог компила в оном):  А вы сегодня жжоте, уважаемый. Прямо какая-то телепатия, только в обратную сторону. ЗвиздецЪ :)))). Интересно, как вас угораздило на столь идиотский комент прямо в момент когда мне попрограмить приспичило? :)))

>Ибо, если бы компилировал, слышал бы про такой чудесный программный продукт, как
>OpenH323. Е про его преемника, Opal.

Про такой продукт я только СЛЫШАЛ, но нафиг мне ЭТО? Если меня не подводит склероз, H.323 это какой-то древний стандарт VoIP с рядом дебилизмов унаследованных от PSTN. К счастью меня такое не интересует как класс.

>Там C++'ные исходники генерируются из ASN.1 грамматик специальным кодогенератором.

И что, получается сильно большая портянка? Кстати да, вот си++ гццом жуется медленно и пичкать большими портянками оный - не очень приятно.

>И на моих серверах их можно собрать только от root'а. Потому, что пользователям через
>login.conf поставлены разумные лимиты на виртуальную память.

Ха, сами себе создали проблем, сами себе решили их. Молодец. Медаль себе купител, чтоли. Или к чему это все?

>И попытка собрать OpenH323 (Opal) -- единственная задача, где этих лимитов пользователю
>не хватает -- gcc вываливается по "virtual memory exhausted".

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

> А C++'ничек-то -- всего каких-то 800 килобайт получается.

Нихрена себе всего. Человек такую портянку вообще ниасилит прочесть и осознать, имхо.

> GCC его "пережёвывает" примерно 20 минут с -O (с -O2 OpenH323
> вообще не собирается), отжирая примерно полтора гигабайта виртуальной памяти.

Эээ вы кое-что забыли. В этом месте очевидно должен быть success story который поведает нам как LLVM и шланг побили в хлам мерзкий гцц и все такое прочее. За себя скажу что меня крайне мало колебет потребление ресурсов в момент билдования - для редких случаев билдования я их гарантированно наскребу. Меня куда больше колебет сколько ресурсов при работе будет сожрано программой при работе т.к. на том же сервере она будет работать постоянно или периодически, без моего контроля. И вот там уже никакие окончания памяти и влеты в лимиты недопустимы.

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

239. "Компания Apple прекращает возврат наработок в GCC ?"  +3 +/
Сообщение от Alex (??), 11-Сен-10, 20:58 
Вчера собрал OpenH323 на VDS с лимитом в 384M под GCC 4.1 . Что я делаю не так?
Ответить | Правка | К родителю #211 | Наверх | Cообщить модератору

235. "Компания Apple прекращает возврат наработок в GCC ?"  –1 +/
Сообщение от Школьник (ok), 11-Сен-10, 17:56 
Ответил чуть выше (234)
Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

249. "Компания Apple прекращает возврат наработок в GCC ?"  –1 +/
Сообщение от аноним (?), 11-Сен-10, 23:21 
видели. учись дальше.
Ответить | Правка | Наверх | Cообщить модератору

260. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от Школьник (ok), 12-Сен-10, 00:30 
>видели. учись дальше.

Обязательно.

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

216. "Компания Apple прекращает возврат наработок в GCC ?"  +1 +/
Сообщение от Аноним (-), 11-Сен-10, 13:18 
Компилятор как бы работает не с оригинальным кодом программиста, а с кодом обработанным препроцессором. Поэтому GCC давится на больших проектах, пусть даже в компилируемом файле не будет ничего кроме #include.

Жаба и нежелание делиться тут совсем ни при чем. LLVM идет под открытой лицензией, clang - тоже. Кроме того LLVM изначально задумывалась как фреймворк для построения компиляторов и разного рода инструментации, что собственно Apple и нужно для создания удобной системы разработки софта под их ОС.

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

221. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от аноним (?), 11-Сен-10, 14:41 
>Компилятор как бы работает не с оригинальным кодом программиста, а с кодом обработанным препроцессором.

а к другим компиляторам это что, не относится?
http://clang.llvm.org/doxygen/Preprocessor_8cpp-source.html

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

208. "Компания Apple прекращает возврат наработок в GCC ?"  +1 +/
Сообщение от Карбофос (ok), 11-Сен-10, 12:55 
вы компилите гигабайтные исходники? или вы про работу с fopen с большими файлами? в последнем случае порой вычучает читать маны. да и интернет под рукой, если вы читать не любите. вот только проблема: нужно толково сформулировать проблему. только в этом случае можно найти достаточно быстро ответ на многие вопросы.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

247. "Компания Apple прекращает возврат наработок в GCC ?"  –6 +/
Сообщение от letsmac (ok), 11-Сен-10, 22:00 
>Уже нет, их задрало что оно дико тупит на больших файлах. Теперь
>вот свой компилятор подняли.

Их задрало хреновое качество кода и наплевательское отношение к стандартам со стороны GCC. Так что патчат свой 4.2 и нормально.

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

250. "Компания Apple прекращает возврат наработок в GCC ?"  +2 +/
Сообщение от аноним (?), 11-Сен-10, 23:24 
угу. особенно (согласно сабжу) их задрало наплевательское отношение к обдж-си.
зы:
как же вы тролли надоели.
такие примитивные.
Ответить | Правка | Наверх | Cообщить модератору

277. "Компания Apple прекращает возврат наработок в GCC ?"  +/
Сообщение от kshetragia (ok), 12-Сен-10, 12:20 
Всё гораздо проще. В связи с тем, что clang/llvm допилен до вменяемого состояния и лучше удовлетворяет требованиям Apple нет никакого смысла пилить gcc.
Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру