mayton,

В общем скачал новую платформу VS2015 и пересмотрел Scimark2.

Почти ничего не поменялось - только Си ушел в еще более дальний отрыв. ~1.5 раза быстрее дНета4 и Явы7.

Ну и немного соврал про аутсайдера - это Дельфи7 с троекратным отрывом =)
Кто захочет - пересоберет на новой Дельфе сам.

maytonЗимарглmayton,

В общем скачал новую платформу VS2015 и пересмотрел Scimark2.

Почти ничего не поменялось - только Си ушел в еще более дальний отрыв. ~1.5 раза быстрее дНета4 и Явы7.

Ну и немного соврал про аутсайдера - это Дельфи7 с троекратным отрывом =)
Кто захочет - пересоберет на новой Дельфе сам.
Зимаргл. А есть данные по .Net и Java7 в сравнении? Можешь табличку сделать?
https://code.google.com/archive/p/scimark-delphi/

Там есть готовые .exe под шарп, си и дельфи.

http://math.nist.gov/scimark2/ - тут исходники под Си и Яву.
javac *.java
затем классы сложить в jnt\scimark2\
запускать java jnt.scimark2.commandline


Dima TAdxпропущено...


А Вам не приходило в голову, что Managment Studio грузит сборки не просто так? Что они нужны? Что там полезный код и данные? И что там при старте происходит множество вещей. Не понимаю, почему долгая загрузка сама по себе - это плохо.
Это к чему вообще сказано? Мысли вслух? Разделяю :)

Вообще-то я это Зимарглу писал чтобы показать ошибочность его предположения что загрузка кода с HDD узкое место.
AdxПо ошибкам. Вам (скорее Зимарглу ) не кажется, что большое количество ошибок связано с отсутствие необходимого количества физической памяти?
Подучи матчасть как виндовс устроен. Хорошая книжка Джеффри РИХТЕР "Windows для профессионалов", там все разжевано доступным языком. Вкратце: загрузка DLL в память процесса происходит маппингом файла, т.е. DLL файл выступает файлом подкачки для определенного куска адресного пространства процесса. При этом файл не читается заранее. При обращении в это место (неважно код там или данные), если реально страница памяти не существует - менеджер памяти перехватывает исключение и подгружает нужный кусок (страницу) из файла, это и показывает счетчик "ошибок страниц" в диспетчере.
Именно так. Следовательно, чем больше фремворк, тем больше своппинга. Попал в кэш - хорошо, но чтение из дискового кэша тоже недешевая операция.

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

Не проверял .net native компиляцию, т.к. нет win10 под рукой.

AdxЗимарглТам есть готовые .exe под шарп, си и дельфи.


Готовые exe - не интересно. Нужно смотреть, как написан код, с какими параметрами скомпилирован.
Оптимизация и правильные ключи могут и в полтора раза скорость поднять.

В этом смысле тестовая задача интереснее. Меньше кода, проще посмотреть узкие места.
Там есть исходный код. Бери, компилируй с разными ключами. Смотри код.

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


Dima T.... Запустил свою поделку консольную на C# - 1,4 Мб.
...
Опять же все зависит о задачи. Насколько критично сэкономить 10-100 Мб ОЗУ, фремворк это ж не только занимание памяти, но и облегчение и ускорение разработки.
...

Ты не тот скорее всего параметр смотришь. Минимальный футпринт дНет приложения занимает примерно 10Мб в памяти. Я писал выше, что смотреть в диспетчере задач.
К примеру тот же Скимарк занимает 3Мб в Си варианте и 11Мб в С#.

Насколько критично 50Мб Озу на процесс вебсервера можешь посмотреть в статье про multitenant JVM выше по топику.