debi12345 писал(а):ей требуется выполнить гораздо меньше инструкций
И что? Кто виноват в том что, JAVA продумана в этой части лучше? Язык Си? Язык Pascal? Или же программисты, которые допустили что, их код выполняет больше инструкций нежели JAVA?
debi12345 писал(а):Это фишка виртуальной машинерии. С/Паскаль такой машины не создают - а значит не могут иметь этой фишки.
И что? Кто виноват? Вывод: С/Паскаль или код систем в целом - плохо продуман программистами, которые допустили что, JAVA... - быстрее системного языка. Всему приходится обучать этих программистов... ох уж и тяжёлая работа у художников...
Вывод: С/Паскаль или код систем в целом - плохо продуман программистами, которые допустили что, JAVA..
С/Pascal полагаются, что роль умной виртуальной машины будет выполнять операционка (в первую очередь LIBC/MSVCRT) - но она (ОСь) не может получать от таких программ контестные "подсказки" какие дают java-проги своей виртуальной машине. В итоге более быстрые LIBC/MSVCRT выполняют в разы больше машинных инструкций, чем JVM (к тому же по-максимуму оптимизирванной , в том числе под новейшие SSE/AVX-инструкции, огромной командой опытнейших высоко-оплачиваемых разработчиков) - и в итоге проигрывают. Что тут можно поделать ? Все и вся переводить на виртуальные машины?
debi12345 писал(а):Все и вся переводить на виртуальные машины?
Для разрешения проблемы замените файл Msvcrt.dll его исходной версией с помощью консоли восстановления Windows XP. И сделайте это пожалуйста, где нить в Линуксе...
vitaly_l писал(а):И сделайте это пожалуйста, где нить в Линуксе...
Это, как раз, не является минусом. Ибо это большой косяк, даже не косяк, а недочет в структуре виндовс, который легко и непринужденно используется для ее взлома.
Добавлено спустя 2 минуты 9 секунд: А для замены библиотеки ее предыдущей версией в линуксе пользуются процедурой даунгрейда.
debi12345 писал(а):грубо говоря - ей требуется выполнить гораздо меньше инструкций
неправда.
debi12345 писал(а):ричем перед выполнением каждого куска машинного кода она точно знает рантайм-контекст (место в программе после всех предыдущих циклов и ветвлений) где находится - оптимизируй по месту не хочу
Повторю еще раз, некоторые оптимизирующие компиляторы тоже так умеют. Сначала генерируется код, затем программа запускается на выполнение и собирается статистика, после чего оптимизация выполняется еще раз. Можно и вручную - это называется профилировка.
Mikhail писал(а):собирается статистика, после чего оптимизация выполняется еще раз
Интересная мысль... в лазарусе я такого не видел... та оптимизация, которая в лазарусе - работает не так... но изложенная Вами оптимизация выполнима, и даже без участия человека(в некоторых случаях)... И в каких IDE такое реализовано?
В Лазарусе (на самом деле в FPC, конечно) бы обычную оптимизацию допилить для начала. А еще лучше LLVM какой-нибудь прикрутить. Насчет автоматической профилировки AOT компилятором интересно, не знал. Но пессимизацию AOT-компилятор произвести не сможет, а значит и набор допустимых оптимизаций меньше, чем у JIT. Тот же виртуальный метод не заинлайнишь.
я запутался. 1. java при запуске требует 2 ядерного современного проца. Иначе тормозит. java при работе требует много оперативной памяти. Памяти будет не хватать, будет юзать файл подкачки := тормоза... 2. в то же время вы пишите, что java работает быстрее С, особенно на числодробительных задачах. ну вот как???
А что будет с С-шной программой при нехватки оперативной памяти?
может я ошибаюсь, но здесь коренное отличие. Запуская программу на С, я, (как Программист) могу посчитать в екселе сколько памяти надо будет для моей программы. Будут какие то неучтенные накладные расходы, но они будут невилики. в java (так как там рулит виртуальная машина) я не могу знать сколько потребляет памяти моя программа.