Есть ли будущее у DELPHI?

Цитата Adil @ 10.11.12, 08:24

Кстати, со всякими Steem и Store эта проблема решается и для многих пропиетарщиков.

Они компилят на серваке? Или на клиенте во время установки?

Добавлено 10.11.12, 09:28

Цитата D_KEY @ 10.11.12, 08:47

korvin, ты так говоришь, как будто не существует llvm и прочих libjit'ов.

Существует, но пользуются ли ими? Какая С++-программа джитит llvm-байткод на клиенте во время установки например или через некоторое время после использования программы и сбора статистики?

Цитата korvin @ 10.11.12, 09:25

Существует, но пользуются ли ими? Какая С++-программа джитит llvm-байткод на клиенте во время установки например или через некоторое время после использования программы и сбора статистики?

Если не используют, значит не надо. У меня существуют большие сомнения, что к написанным программам на С++ имеется много претензий в отношении производительности
Кстати, на тех же маках же собирается все через clang(и C и C++ и Objective-C) и нет никаких препятствий для использования llvm во всю... Или я ошибаюсь?

Цитата Adil @ 10.11.12, 08:24

Ну да, проблемы разработчиков пропиетарного ПО - это проблемы ЯП.

Ну Java все равно быстрее может быть ибо может перекомпилироваться в рантайме в зависимости от поступающих данных. В C++ придется использовать llvm

Цитата korvin @ 10.11.12, 08:07

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

korvin, ты аццки жжёшь Всё там прекрасно оптимизируется, всем жабам на зависть. Просто идёт код и с, например, SSE, и с FPU. Какой использовать, определяется при старте.

Цитата D_KEY @ 10.11.12, 09:33

Если не используют, значит не надо. У меня существуют большие сомнения, что к написанным программам на С++ имеется много претензий в отношении производительности

Кстати, на тех же маках же собирается все через clang(и C и C++ и Objective-C) и нет никаких препятствий для использования llvm во всю... Или я ошибаюсь?

К ФФ в свое время было довольно много претензий по производительности. Сейчас он вроде стал достаточно быстр.

На сколько я знаю, только Debug-версии. Release собирается GCC. Вот во FreeBSD да, перешли на clang, но я пока не видел там возможности ставить софт транслируя его из llvm-байткода, скаченного с репозитория. Кроме того, говорят, в llvm-байткоде таки имеется весьма ненулевое количество платформо-зависимых инструкций.

Цитата Adil @ 10.11.12, 07:51

Почему-то ты для Java называешь кодом тексты на Java, а для C++ считаешь кодом - уже скомпилированный машкод? Нормально написанный код на С++ будет "работать" как на Core-i7, так и на Core 2 Duo/Pentium 4, так и на AMD. Нужно просто собирать под соответствующую архитектуру - спроси у гентушников. C++ - как это не удивительно - кроссплатформенный язык.

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

Цитата D_KEY @ 10.11.12, 09:33

У меня существуют большие сомнения, что к написанным программам на С++ имеется много претензий в отношении производительности

Ээээ, Windows?

Цитата MyNameIsIgor @ 10.11.12, 12:56

Просто идёт код и с, например, SSE, и с FPU. Какой использовать, определяется при старте.

Это если при сборке используется свой ассемблерный код. Насколько мне известно, компиляторы не могут генерить оптимальный код сразу под несколько архитектур с опциональным выбором при старте.

Да и размер экзешника при этом растет. И если программа старая, но запущена на новом поколении процессоров, такая "оптимизация" - до одного места.

Еще хочу обратить внимание, что здесь спор не о Java vs C++, а о Delphi. А Delphi медленнее Java, это факт.

Добавлено 10.11.12, 15:06

Цитата korvin @ 10.11.12, 13:03

К ФФ в свое время было довольно много претензий по производительности. Сейчас он вроде стал достаточно быстр.

Половина ФФ написана на собственном скриптовом языке (XUL)
Сейчас уже для него запилили конечно JIT, но все равно чисто нативный Хром - быстрее.

Цитата [S]mike @ 10.11.12, 15:05

Да и размер экзешника при этом растет.

по сравнению с размером jvm - это мелочь.

Цитата [S]mike @ 10.11.12, 15:05

Половина ФФ написана на собственном скриптовом языке (XUL)

Тебя не смущает, что XUL основан на XML?
XUL только определяет интерфейсы, сама морда написана он на JS.

Цитата jack128 @ 10.11.12, 15:07

по сравнению с размером jvm - это мелочь.

Под JVM можно запустить туеву хучу проектов. При этом один дельфийский экзешник в 20-30 метров - это вполне реально. Скайп весит 17 метров. Если заюзать DevExpress - апликуха тоже будет весить метров 15-30.

Цитата Мяут-Настоящий @ 10.11.12, 15:41

XUL только определяет интерфейсы, сама морда написана он на JS.

Какая разница? Все равно интерпретация (с примитивным JIT-компилятором в последней версии). Даже Firefox, написанный на Java, смотрелся бы более выгодно.

Цитата [S]mike @ 10.11.12, 16:19

Под JVM можно запустить туеву хучу проектов. При этом один дельфийский экзешник в 20-30 метров - это вполне реально.

под дельфискими пакетами тоже можно тучу проэктов запустить.

Цитата jack128 @ 10.11.12, 16:50

под дельфискими пакетами тоже можно тучу проэктов запустить.

Ололо! Только скомпилированные _ОДНОЙ_ версией Дельфи (причем не исключено, что нужен тот же сервис-пак или апдейт). Или нужно иметь кучу старого хлама - также неоптимизированного ни под современные ОС, ни под современные процы.
А вот с последней JVM можно запускать как старые JAR-ники, так и самые последние. А выйдет новая JVM, оптимизированная под новые процы - можно будет и под ней.

Сообщение отредактировано: [S]mike - 10.11.12, 16:58

хотя по мне все эти разговоры о размере экзешника - туфта. В 99% случаев - это вообще никакого не волнует.

Сообщение отредактировано: jack128 - 10.11.12, 17:00

Цитата jack128 @ 10.11.12, 16:59

хотя по мне все эти разговоры о размере экзешника - туфта. В 99% случаев - это вообще никакого не волнует.

Так о размере говорить начал ты. А я говорил о преимуществах в плане оптимизации и кроссплатформенности. Выложил джарник - и можешь запустить его под Windows, Linux, MacOS. А код можешь и под Андроид заюзать. Исполняемый же код будет работать под любой архитектурой: x86, 64 бита, ARM, MIPS и прочие.

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

Сообщение отредактировано: [S]mike - 10.11.12, 17:36

Цитата [S]mike @ 10.11.12, 17:27

Так о размере говорить начал ты

Цитата [S]mike @ 10.11.12, 15:05

Да и размер экзешника при этом растет.

?

Ну это я вскользь упомянул всего лишь. Как дополнительный негативный фактор "компиляторной" оптимизации под конкретную платформу.

Факт один - managed code сейчас рулит и разруливает. В производительности при грамотном использовании как правило не только не уступает нативному, но и бывает что опережает. А также идет в ногу со временем, с оптимизацией исполняемых сред под новые процы. А про безопасность, возможности отладки, рантайм оптимизации - вообще молчу: небо и земля.