Подводные камни clang

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

Да подохни ты уже наконец, невменяемая, некомпетентная сучка.

Ко-ко-ко. Какая ты резкая, обоссалась и сразу заголосила?

Ты на этот Си смотрела, блядина рваная?

Похоже ты и не смотрела.

Ну посмотри.

Посмотри.

Там только тесты

Т.е. на жабе даже тесты хрен напишешь - ок.

тупой загрузчик.

Хренасе тутой - там полная вм, рантайм и дожопы чего. Если ещё посчитать строки сишного рантайма - там просто сишного кода будет больше, чем жабы.

Я конечно понимаю, что ты анскильная питушиная балаболка, которая прочитала про пускалку и теперь мне что-то рассказывает.

Там коркод не полноценная жаба, а ссанина - обкромсанный жабасишный деалект, который к жабе не имеет никакого отношения. На которой захреначена говножава, единственное, что там написанно на жабе - это всякий обосанный обвес.

Т.е. на сишке написана пускалка для для недоязычка(который почему-то ты называешь жабой), на котором написан весь кор и реализация «полноценной» жабы.

Какой жопой это жабанажабе я не понимаю, хотя что ещё может кукарекать нулёвая ссанина.

Чёж ты, обоссался и сделал вид - типа никто не заметил? А так яро кукарекал.

Неловко то как.

Да забей. Кстати, это лучше, чем у меня

Насколько ты скиллен в C?

Может нам сделать клуб клонов короля рок-н-ролла^W^W царя сишки-н-скилла?

JAVA и иже с ними не нужны

это почти вся IT индустрия исчезнет без Java, и даже этот сайт.

А вот C, C++, Vala, LISP, LUA, BASH те нужны.

это смешно. ладно Lua (хотя вообще спорно) но Vala ... а LISP в этом списке только что-бы другие не придирались к этому списку?

почки, печень, кишки - не нужны, сердце, легкие, селезёнка - нужны

примерно так прочитал

Clang пока не поддерживает OpenMP, правда не знаю, нужен ли он вам вообще или нет :)

Плохой пример, это же дикие тормоза, их только на хорошем железе можно использовать, MVS лучше же в разы.

8 ГБ ОЗУ и четырёхъядерный процессор считаются хорошим железом для Java-разработчика? Однако же в середине 2000-х в основном на Java разрабатывали, сидя на 2-4 ГБ ОЗУ и двухъядерном процессоре. Eclipse компилировалась из исходников за пятнадцать-двадцать минут, а OpenOffice (написанный на С++) за 4 часа — размер исходников одинаков. Сейчас ситуация такая же!

Вот только для компиляции OpenOffice требуется свободного пространства порядка 20 ГБ на жёстком диске, а Eclipse достаточно пары гигабайт для развёртывания исходников и компилированного кода.

Не знаю, какой ногой пишется Thunderbird, но раньше он собирался за 15-20 минут на Athlon XP 2500+, а сейчас для сборки последних версий требуется ДВА часа машинного времени четырёхъядерного процессора.

Eclipse компилировалась из исходников за пятнадцать-двадцать минут, а OpenOffice (написанный на С++) за 4 часа — размер исходников одинаков

Внезапно, Eclipse компилируется при каждом запуске, а OpenOffice - только один раз.

Такое ощущение, что это суперхаккиллер срется сам с собой.

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

Учитывая то, что: «стоит отметить, что во всякой синтетике скорость работы джавы ближе всего к скорости работы С++ т.к. такие тесты зачастую используют её встроенные (а потому и быстрые) типы данных, заместо классов.», — оверхед у байткода Java небольшой, а всю основную работу выполняет как раз-таки код, написанный на C++. ;-)

А теперь скажите, вы готовы отказаться от Java и заменить все приложения, написанные на нём, на приложения (и программистов) C++? ;-) Боюсь, в этом случае всё будет очень уныло и тормозно, несмотря на «полуручные» оптимизации. По крайней мере сроки написания приложений возрастут в 3-4 раза по сравнению с Java-проектами такого же объёма. Включите сюда издержки на программистов C++, которые должны знать огромный талмуд стандарта C++ (иначе они просто не справятся с теми задачами, которые решаются на Java).

С++ — не масштабируемый язык. Зачем для компиляции Chromium'а нужно 11 ГБ свободного места на диске? Что в нём такого, чего по сути нет внутри библиотек OpenJDK?!

Внезапно, Eclipse компилируется при каждом запуске, а OpenOffice - только один раз.

Но субъективно по скорости работы оба одинаковы, ведь так? ;-)

Внезапно, Eclipse компилируется при каждом запуске, а OpenOffice - только один раз.

Но субъективно по скорости работы

Ты не скорость работы сравнивал.

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

оверхед у байткода Java небольшой, а всю основную работу выполняет как раз-таки код, написанный на C++. ;-)

Ладно, я уже понял, что хрень сказал. Просто у меня жгучий бугугрт от джавы и того, что на ней написано. Я правда не видел ни одного приложения на джаве, которое бы работали быстро и гладко, не поглащая тонны памяти. Чего нельзя сказать о подавляющем числе C++ приложений, производительность которых меня устаивает.

А теперь скажите, вы готовы отказаться от Java и заменить все приложения, написанные на нём, на приложения (и программистов) C++? ;-) Боюсь, в этом случае всё будет очень уныло и тормозно, несмотря на «полуручные» оптимизации. По крайней мере сроки написания приложений возрастут в 3-4 раза по сравнению с Java-проектами такого же объёма. Включите сюда издержки на программистов C++, которые должны знать огромный талмуд стандарта C++ (иначе они просто не справятся с теми задачами, которые решаются на Java).

Не совсем понял. Если лично отказаться от приложений на джаве, то я это УЖЕ сделал. Если заменить глобально (переписать) - конечно же нет, это непосильная задача. Сроками написания я пренебрёг, ровно как и издержками на программистов С++, виноват.

С++ — не масштабируемый язык. Зачем для компиляции Chromium'а нужно 11 ГБ свободного места на диске? Что в нём такого, чего по сути нет внутри библиотек OpenJDK?!

Честно? Понятия не имею, а от предположений откажусь, чтобы не ляпнуть очередную фэспалмовую чушь.

С++ — не масштабируемый язык. Зачем для компиляции Chromium'а нужно 11 ГБ свободного места на диске? Что в нём такого, чего по сути нет внутри библиотек OpenJDK?!

Автор - наркоман?

Если бы у бабушки был бы %%% то она была бы дедушкой.

Кстати, мне знакомы реализации того же mapreduce (~hadoop), которые написаны на «нормальных» языках. Они, внезапно, не работают в два раза быстрее и не потребляют в два раза меньше ресурсов, а примерно сравнимы с hadoop, который написан на «не кошерной» java.

Вроде были новости о запиливании openmp. Зато clang для разработки более подходит, так как пишет более адекватные сообщения об ошибках и содержит первичные версии санитайзеров (а не вторичные бекпорты как gcc)

первичные версии санитайзеров

Где о этом почитать?

Я был на докладе разработчика.

А, ок, я тогда просто на него тут схожу. Что-то я пропустил, хром уже на шланге девелопят?

Рано или поздно допилят нейроинтерфейс и будет достаточно мозга.

Объясните мне, пожалуйста, почему Eclipse и Netbeans работают в 3 раза медленнее, чем Codeblocks или VisualStudio? И почему качалка Jdownloader запускается в 4 раза медленне чем Uget или виндовый DownloadMaster? Не уж то там разработчики такие криворукие?

Объясните мне, пожалуйста, почему Eclipse и Netbeans работают в 3 раза медленнее, чем Codeblocks или VisualStudio?

Как проводились замеры?

И почему качалка Jdownloader запускается в 4 раза медленне чем Uget или виндовый DownloadMaster?

java приложения медленно стартуют, такова особенность технологии, но про «в 4 раза» похоже на самовнушение.

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

Последние версии VS тоже совсем не летают, а CodeBlocks просто нихрена не умеет.

Ну до VS и по скорости и по умениям всем Eclipse и Netbeans как до Китая раком. А CB умеет достаточно для своей ниши. Что особенного и полезного для плюсов или си умеет Eclipse и Netbeans, что не умеет CB?

Что особенного и полезного для плюсов или си умеет Eclipse и Netbeans, что не умеет CB?

Нормальную навигацию и дополнение кода.

А что есть в CB кроме текстового редактора и интеграции с компилятором? Вот IDE от Jetbrains написаны на Java и работают абсолютно нормально, так что язык это дело десятое.

А что нужно кроме нормального текстового редактора (ну и формошлепства)? Отладчик? В CB он есть, формошлепство тоже есть, профилирование тоже есть, автодополнение есть (хотя в Netbeans оно лучше, вот только тупит), статический анализ кода есть, браузер классов есть. ну а если человек код пишет так, что по нему без поиска ничего не найти (наверное в один большой файл без объявлений и хедеров?), то это уже его проблемы.

Зачем для компиляции Chromium'а нужно 11 ГБ свободного места на диске? Что в нём такого, чего по сути нет внутри библиотек OpenJDK?!

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

Действительно, если большой и не влезает, то можно смазать.

А все-таки, зачем? Криво сборка настроена?

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

Если у тебя основная система собрана с gcc библиотекой С++, то будут вылезать косяки, особенно с boost'ом.

Ну тут и с gcc могут быть проблемы. Если используешь с++11 в проекте то иногда можно словить геморрой, т.к. системный буст собран без поддержки c++11 :)

Страничная трансляция адресов аппаратная и о оверхеде от неё думать не надо - это проблемы разработчиков процессоров. Иначе логичнее не от неё отказываться, а на RISC вместо x86 переходить (с точки зрения архитектуры процессора упрощение системы команд до уровня RISC гораздо важнее, чем убирание не такого уж сложного модуля страничной трансляции).

Кольца безопасности дают оверхед лишь на операциях ввода-вывода. А они как правило далеко не самое узкое место (приложение считает гораздо больше, чем пишет-читает). А если узкое, то не потому что системные вызовы долгие, а потому что аппаратура (SSD и HDD) тормозят.

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

Линус недавно посчитал, что эта аппаратная проблема имеет цену в районе 1000 циклов

А в процентах это сколько?

А кольца дают оверхед на любой системный вызов, да и на многозадачность в принципе.

Переписывание всего на managed-языках тоже дает нехилый оверхед %)

Ну до VS

VS, начиная с 10 версии стало лютым пиздецом. 11ая еще более или менее, но на довольно небольшом проекте (~30 мег исходников) оно просто люто тормозит и тупит. еклипс с этом плане намного шустрее крутится, по символам бегает резво.

всё нормально с clang-ом
если какие-то существующие библиотеки/программы не собираются - значит ребята подстраивались под особенности gcc а не стандарты. Такие ошибки уже в портах freebsd поправили.

Так что не переживай - пользуйся.

Ну вот я пока пользуюсь, полет нормальный, очень понятные мне сообщения о ошибках. В каких IDE/редакторах лучше и проще всего настраивается clang-based сompletion. Что-то в Sublime все сложно

vim, emacs, QtCreator. Везде норм.

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

Версия JDK? Опции запуска JVM? (для NetBeans, например, по умолчанию весьма пессимистичный объём памяти выделяется — его нужно увеличивать в несколько раз для приемлемой работы)

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

У меня много ОЗУ. Почему для компиляции С++ программ тратится место на медленном HDD, а быстрое ОЗУ остаётся свободным? Если я выделяю в ОЗУ место под RAM-диск требуемого объёма, то скорость компиляции C/C++ программ НЕ_УВЕЛИЧИВАЕТСЯ — вот это для меня большая загадка, в противоположность Java, где скорость работы программы в прямой зависимости от объёма ОЗУ, а свопинг на диск из-за нехватки места в маленьком ОЗУ — самая дорогая операция.

всё нормально с clang-ом

В базовой системе FreeBSD продолжает оставаться GNU binutils.

% ld -v
GNU ld 2.17.50 [FreeBSD] 2007-07-03

Если я выделяю в ОЗУ место под RAM-диск требуемого объёма, то скорость компиляции C/C++ программ НЕ_УВЕЛИЧИВАЕТСЯ — вот это для меня большая загадка, в противоположность Java, где скорость работы программы в прямой зависимости от объёма ОЗУ

Нихрена себе... ты правда не понимаешь таких простых вещей?

Eclipse компилировалась из исходников за пятнадцать-двадцать минут

а Eclipse достаточно пары гигабайт

The build itself takes around 2 hours on a Core i5 machine with SSD, so of course time is required for this. Also approximately 25 Gigs of free space and 4 Gigs of RAM are required on the hardware-side.

http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#buil...

Переписывание всего на managed-языках тоже дает нехилый оверхед %)

Зачем переписывать? Есть же emscripten ^_^

А в процентах это сколько?

5% при выполнении обычной задачи Линуса (компиляция ядра), 80% на синтетическом тесте. Микрософтовцы в своё время оценили этот оверхед в 20%.

20% быстрее * 20% медленнее (оверхед на managed) = 0.8 * 1.2 = 0.96 = 4% быстрее.

PS: размышления основаны на «science fiction / comedy / absurdist / completely serious talk» The Birth & Death of JavaScript

Зачем переписывать? Есть же emscripten ^_^

размышления основаны на «science fiction / comedy / absurdist / completely serious talk» The Birth & Death of JavaScript

А, так ты просто петросянишь...

В каждом петросянстве есть доля петросянства. В конце концов не зря бородатые дяди экспериментируют со штуками вроде сингулярити.

не зря бородатые дяди экспериментируют со штуками вроде сингулярити

Эксперимент закончен, диссеры написаны. Забудь.