maytonBasil A. Sidorovпропущено...
Из пальца высосали?

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

C++ (gcc/visual c)

Java

.Net

В категориях CPU(computing), Memory Diving, I/O (диск, сетевые сокеты).

Всего должно быть 9 штук оносительных индексов производительности. Почему относительных?
Ну возможно потому что за единицу мы будем просто брать лучший.

Ну насколько я помню, ты ни разу так ничего такого и не сделал. Стоит уйти с форума лет на 5, уже и пароль требуют =)

Высосано не из пальца, а из Инернетов. Я смотрел много тем разных тестов. Все конечно недостоверно, т.к. например тесты скорости дНета микрософтом "запрещены". Тем не менее они в 4й версии подтянулись.

Старые ссылки:
http://www.sql.ru/forum/412782-1/benchmarki-c-c-java-delphi
http://www.sql.ru/forum/776019-1/optimiziruushhie-kompilyatory

Basil A. SidorovЗимарглПо прямой вычислительной производительности Ява и дНет проигрывают С++ примерно в 1.5-2 разаИз пальца высосали?а) Простейшая задач на Яве или дНете сколько мегабайт памяти жрет при старте? Соответственно старт долгий.Пипец ...
Есть реальная система, которая обслуживает от двухсот до четырёхсот пользователей в течении рабочего дня.
Какая половая разница, сколько "жрёт" эта система на старте, если выполняя полезную работу она занимает столько места, сколько требуют обрабатываемые данные?
Какая половая разница, сколько секунд она стартует, если при нормальной работе она вообще не должна перезапускаться?в) Питон в противовесный пример. Он по вычислительной скорости проигрывает С в 100 (сто) раз. Но его вирт машина занимает 3(три) Мб памяти целиком. Потому лагов в интерфейсе например нет.Когда мне потребуется парой гигабайт орудовать - питон останется таким же лёгким и быстрым?
Питон быстрый только на встроенных функциях, которые сишные.

Вопрос половой разницы интересный. Я считаю, что
-если размер обрабатываемых данных в памяти существенно больше кода в памяти, то на сваппинг можно забить
-в остальных случаях - объем кода имеет значение в двух больных местах - вымывании кэша процессоров и page faults

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

Различное кэширование, что [виртуальной] памяти ОС, что кода хотспот-машинами дает только определенный выигрыш, но не лечит проблемы в целом.
Лучше день потерять, а потом за 5минут долететь(с)
Но день то уже потерян.

Хотспоты отлично себя показывают только на всяких синтетических тестах типа цикла ф=ф+1 =)

Для тех кто умеет и хочет потестировать нужно для дНета и Явы:
-на разных задачах сравнить футпринт размещения на диске и в оперативной памяти всего фреймворка.
-оценить, насколько в системах с ВМ, повторно используется код фреймворка в памяти. Т.к.возможность динамического изменения кода может потребовать своей копии каждой задаче.
-засечь page faults при различных задачах (разнообразное использование фреймворка.vs.много обрабатываемых данных) по мере занятости памяти системы

ИзопропилЗимаргл-оценить, насколько в системах с ВМ, повторно используется код фреймворка в памяти. Т.к.возможность динамического изменения кода может потребовать своей копии каждой задаче.
с документацией лучше сначала ознакомиться нужно - того гляди - до тестирования дело не дойдёт
Кидай ссылки, а лучше на статьи практиков их подтверждающие. Вендоры часто умалчивают ненужные им детали.

Желательно на не очень старые версии и на разных платформах.

maytonНу насколько я помню, ты ни разу так ничего такого и не сделал. Стоит уйти с форума лет на 5, уже и пароль требуют =)

Высосано не из пальца, а из Инернетов. Я смотрел много тем разных тестов. Все конечно недостоверно, т.к. например тесты скорости дНета микрософтом "запрещены". Тем не менее они в 4й версии подтянулись.

Старые ссылки:
http://www.sql.ru/forum/412782-1/benchmarki-c-c-java-delphi
http://www.sql.ru/forum/776019-1/optimiziruushhie-kompilyatory
Топики датируются 2007-2010 годом. С того времени много воды утекло. Целая эпоха для некоторых технологий.
Предлагаю не смотреть на их результаты.

Кстати по пункту 1 (CPU) я уже нашёл подходящий тест. Это алгоритм рендеринга 3D-графики на С++ . Достаточно
не сложный чтобы портировать его на шарпы и Java. Он практически не использует память. Но зато плотен в вещественных
вычислениях. Ближе к пятнице я оформлю его как ТЗ в своём тяпничном сообщении.

На объективность в плане ВЫБОРА алгоритма я не претендую. Рад буду услышать предложения и дополнения.
Так можно результаты не смотреть, а перекомпилировать те же исходники на современных платформах.
Не думаю, что твоя задача даст иное распределение, чем SCimark.

К тому же для задач такого типа важнее возможность кластеризации, чем пиковая производительность на отдельной машине.


ИзопропилЗимаргл,

ну поехали, обсудим http://www.ibm.com/developerworks/library/j-multitenant-java/
Отличный пример. В нем написано,что в Jvm7 убрали изолированность в памяти экземпляров кода фреймворка и получили выигрыш в 2.1 раза по памяти и в 1.5 по скорости загрузки приложений.
Что совпадает с моими утверждениями.


Adxв) никакой связи между занимаемой памятью и лагами в интерфейсе нет.
Это неверно. Проверяется следующим образом - щелкаем по интерфесу дНетовской софтинки и смотрим как меняется показатель "Ошибки страниц" в Диспетчере задач. Это подгрузка с диска интерфейсных классов.

Лучше обсуждать не абстрактное "понимание", а факт того, что дНет показывает во всех тестах наихудшие результаты из всех компетиторов.


mayton...
- Прошу вас написать краткую инструкцию по замеру футпринта.

Я сходу не смогу придумать адекватный и _воспроизводимый_ академический метод.
Когда смотрел для себя - просто засекал дельту свободной памяти при выгрузке отработавшего приложения.

В Win7 Это совпадает с показателем "Память - Рабочий набор".
Объем же фреймворка, подлинкованного но не загруженного можно увидеть в "Память - выделенная память". Но боюсь, для языков с широкм использованием динамического связывания это не годится.

maytonЗимаргл,
Так можно результаты не смотреть, а перекомпилировать те же исходники на современных платформах.
Не думаю, что твоя задача даст иное распределение, чем SCimark.
Насколько я понял SCimark гоняет Java-апплет на разных ОС и версиях JRE. Это не то что я хотел.
Это просто кусок вычислительного кода.
http://math.nist.gov/scimark2/index.html