KDevelop пробовал много лет назад. До VS тогда было еще далеко. Если приходится писать на C++, в основном использую emacs + gud-gdb; никак не соберусь прикрутить всплывающаю подсказку к Emacs'у.
Да, IPO здорово может помочь с inline и versioning'ом. Но на практике девиртуализация случается не так часто, как хочется. Кроме того, если в некоторый момент времени девиртуализация перестанет выполняться, узнать об этом можно будет только при анализе ассемблера или на перф.тестах.
А на счет скаляризации в Java — не самая работающая оптимизация в VM, на мой взгляд. Плют такие же проблемы, что сложно отследить, когда перестает выполняться. Т.е. просто дописали код в метод А, а в методе В, вызывающем А, перестала работать скаляризация, т.к. привышен лимит на inline
Ее самую. Тут дело не в сравнительных характеристиках, так как подавляющее большинство разработчиков не используют и десятой части функций современной среды разработки.
Если говорить про мои претензии к VS:
1. VS начинает сильно тормозить на больших проектах
2. Всплывающая подсказка при программировании на C++ работает фундаментально хуже, чем при программровании на Java в виду значительно большей мощности языка (нет в Java даже примерных аналогов метапрограммрования на шаблонах, макросов, перегруженных операторов '->' и '.' и многого другого).
3 VS не работает на линуксе…
Да, согласен. Как я и писал, это всегда trade-of. Чем сложнее модель, тем она будет медленнее работать. И, соответственно, чем быстрее модель, тем она должна быть проще.
Некоторый опят был, но с цифрами пока ответить не готов.
P.S. У Zing'а есть вполне официальный триал — можно взять, скачать, установить и пощупать. Рекомендую.
Кроме C4 там есть Falcon — компилятор на базе LLVM.
Спасибо за ссылку.
Скорость аллокации, действительно, огромная. Но очень неприятно, что вложенные объекты будут скорее всего расположены как дерево ссылок (не берем в рассчет скаляризацию), а не линейная последовательность адресов, что ощутимо влияет на суммарную производительность.
Про переиспользование объектов — возможно мы напишем немного подробнее.
С Azul C4 не все так однозначно :-)
А хранить все в офф-хипе, я думаю, может сильно повлиять на оптимизации в JIT'е: не факт, что компилятор осилит весь alias-анализ.
Про ордера — да, такая проблема есть. Тут есть несколько вещей, которые можно подкрутить в Java: количество вызовой, после которых происходит JIT-компиляция. А вторая возможность ощутимо побороть этот аспект — использовать ReadyNow от AZUL. Эта технология позволяет сохранить информацию динамическом профиле в файл и использовать ее при следующем запуске. Т.е. warm-up сокращается очень ощутимо.
Да, согласен. Но тем не менее, длительность задержки напрямую зависит от размера хипа, а он может достигать ощутимых размеров, т.е. это всего лишь вопрос времени, когда время GC также достигнет ощутимых значений.
Если говорить концептуально, то именно управление памятью — та область, где и у Java и у C++ достоинства — продолжение их недостатков.
Тогда разработчикам нужно раздавать такие же железяки, как PROD сервера, чтобы микроархитектура была такая же. А если не раздавать, то можно наткнуться, что на PROD сервере все компилируется не совсем так, как должно.
Системное программирование/компиляторы/производительность. Замена инструкции А на Б приводит к регрессии на 20% по производительности. Инструкции делают одно и то же, с очень похожими таймингами. Оказалось прицина в code alignment'е. Т.е. скедулинг другой инструкции триггерил проблему совершенно в другом месте. Да и многие проблемы с производительностью из этой корзины.
Или другое: не работает раскрутка стека из обработчика сигналов. Оказалось, что причина в некорректной работе dl'я (dynamic linker). И такие задачи всплывают регулярно.
P.S. А что за коллега? Есть предыдущие публично доступные публикации на эту тему?
>> программистам попадают уже готовые ответы, которые необходимо перевести в код. Алгоритмы все известны.
Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.
Вы действительно считаете, что определение подхода исследовательской задачи (даже без реализации) может быть оценено? Если да — скажите область, интересно. В моей области это нереально, к сожалению.
Рискну сказать, что если методологию внедряют повсеместно плохо, может быть все-таки что-то не так с методологией? Постоянно слышу про «вы неправильно используете Agile/Scrum/...» — покажите мне, где они используются правильно?
P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?
А на счет скаляризации в Java — не самая работающая оптимизация в VM, на мой взгляд. Плют такие же проблемы, что сложно отследить, когда перестает выполняться. Т.е. просто дописали код в метод А, а в методе В, вызывающем А, перестала работать скаляризация, т.к. привышен лимит на inline
Если говорить про мои претензии к VS:
1. VS начинает сильно тормозить на больших проектах
2. Всплывающая подсказка при программировании на C++ работает фундаментально хуже, чем при программровании на Java в виду значительно большей мощности языка (нет в Java даже примерных аналогов метапрограммрования на шаблонах, макросов, перегруженных операторов '->' и '.' и многого другого).
3 VS не работает на линуксе…
P.S. У Zing'а есть вполне официальный триал — можно взять, скачать, установить и пощупать. Рекомендую.
Кроме C4 там есть Falcon — компилятор на базе LLVM.
Скорость аллокации, действительно, огромная. Но очень неприятно, что вложенные объекты будут скорее всего расположены как дерево ссылок (не берем в рассчет скаляризацию), а не линейная последовательность адресов, что ощутимо влияет на суммарную производительность.
С Azul C4 не все так однозначно :-)
А хранить все в офф-хипе, я думаю, может сильно повлиять на оптимизации в JIT'е: не факт, что компилятор осилит весь alias-анализ.
Про ордера — да, такая проблема есть. Тут есть несколько вещей, которые можно подкрутить в Java: количество вызовой, после которых происходит JIT-компиляция. А вторая возможность ощутимо побороть этот аспект — использовать ReadyNow от AZUL. Эта технология позволяет сохранить информацию динамическом профиле в файл и использовать ее при следующем запуске. Т.е. warm-up сокращается очень ощутимо.
А вообще, спасибо за интересный комментарий!
Если говорить концептуально, то именно управление памятью — та область, где и у Java и у C++ достоинства — продолжение их недостатков.
Или другое: не работает раскрутка стека из обработчика сигналов. Оказалось, что причина в некорректной работе dl'я (dynamic linker). И такие задачи всплывают регулярно.
P.S. А что за коллега? Есть предыдущие публично доступные публикации на эту тему?
Ну вот собственно и область применимости Agile. Да, согласен, в таком environment'е Agile будет в самый раз.
P.S. Сколько работал в компаниях, где был «Scrum» — работать было не очень приятно.
P.P.S. Как можно оценить задачу в SP, если она может занять 1 день, а может 1 неделю?