|
|
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
А. Прошу прщения. В SciMark есть сишная имплементация LU, FFT e.t.c. По тексту репорта совершенно было неочевидно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 14:31 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглСтарые ссылки: http://www.sql.ru/forum/412782-1/benchmarki-c-c-java-delphi Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Но есть нестыковка: ява-код не обновлялся с версии 4.61 (ноябрь 2008) и он однопоточный, а ядер у моего проца два и lzma.exe честно грузит оба. Я считаю, что -если размер обрабатываемых данных в памяти существенно больше кода в памяти, то на сваппинг можно забить -в остальных случаях - объем кода имеет значение в двух больных местах - вымывании кэша процессоров и page faultsВы уже профилировили "пофигу что" или ваше утверждение следует из общей эрудиции и банальной логики? Я, например, знаю пример, когда желание экомонить ресурсы (отложенная инициализация) создало вполне реальные проблемы. Более того, я знаю , что это была экономия на спичечных опилках. -на разных задачах сравнить футпринт размещения на диске и в оперативной памяти всего фреймворка. -оценить, насколько в системах с ВМ, повторно используется код фреймворка в памяти. Т.к.возможность динамического изменения кода может потребовать своей копии каждой задаче. -засечь page faults при различных задачах (разнообразное использование фреймворка.vs.много обрабатываемых данных) по мере занятости памяти системы"Код, сестра! Код!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:06 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, можешь подчеркнуть цифры которые сравниваешь. Ни пса нипонятно в этом отчете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:12 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
mayton, у Це-кода - ~2600Mips против 1700 и (пропало в трёх точках) ~2600 КiB /s против 1450 KB /s на упаковке. На распаковке проигрыш примерно втрое по КБ/сек. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:25 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovНо есть нестыковка: ява-код не обновлялся с версии 4.61 (ноябрь 2008) и он однопоточный, а ядер у моего проца два и lzma.exe честно грузит оба. Для чистоты эксперимента надо ампутировать одно ядро :) В 7-ке вызвать msconfig, вкладка "Загрузка", кнопка "Дополнительно" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:41 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, круть. Спасибо за тестинг. Еще попробуй плиз выставить ключик -XX:CompileThreshold=1. (со ссылкой на http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html) Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:42 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Dima TBasil A. SidorovНо есть нестыковка: ява-код не обновлялся с версии 4.61 (ноябрь 2008) и он однопоточный, а ядер у моего проца два и lzma.exe честно грузит оба. Для чистоты эксперимента надо ампутировать одно ядро :) В 7-ке вызвать msconfig, вкладка "Загрузка", кнопка "Дополнительно" Согласен. Ценное замечание. Я-бы еще поигрался с ключами Код: plaintext 1. Счастливые обладатели пингвина или чорта в кедах - тоже теоретически имеют контроль над защёлкиванием процесса на ядрах но как это сделать щас - не скажу. Не помню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:46 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ИМХУ задача упаковка/распаковка не совсем корректна для таких тестов. Она заточена под прямой доступ к памяти, т.е. изначально в пользу С/С++. Не удивлюсь что еще есть заточка на уровне проца, т.к. задача распространенная и ресурсоемкая, могли какие-нибудь команды для ускорения добавить. Надо что-то что обычно решают на высокоуровневых языках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 16:51 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Как-то я из любопытства разбирал sun-вские пакеты zip/gzip/gif сжатия и дошёл до того что их реализация Deflater сокрыта в виде native кода. Но я надеюсь что в данном тесте это не так. В противном случае этот тест был-бы фикцией т.к не являлся-бы pure-java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 17:01 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
maytonЕще попробуй плиз выставить ключик -XX:CompileThreshold=1 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 17:01 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Dima TИМХУ задача упаковка/распаковка не совсем корректна для таких тестов. Она заточена под прямой доступ к памяти, т.е. изначально в пользу С/С++. Не удивлюсь что еще есть заточка на уровне проца, т.к. задача распространенная и ресурсоемкая, могли какие-нибудь команды для ускорения добавить. А лучше всего под такие задачи на OpenCL писать. Если графическая карточка в компе имеется. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 17:01 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Далеко не все GPU-вычисления "лучше": как только требуется доставить до видимокарты (много) исходных данных и забрать (большой) результат - всё резко плохеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 17:04 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
GPU-вычисления так и останутся в сегменте невостребованного. Там где нужна широкая шина взаимодействия с I/O и портами будет неизбежный провал. Архитектура такова ибо. Ковыряние bitcoin-ов это другое дело. Но как часто нам по жизни оно надо? У меня вот узкое место - это собственно процесс компилляции проекта. Уж чего только не придумывал. Почти принципиально неоптимизируемый процесс. Можно только структуру проекта побить на модули разве что. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 17:11 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
maytonGPU-вычисления так и останутся в сегменте невостребованного. Как раз Ваша идея о проверке производительности CPU с помощью алгоритма рендеринга 3D-графики - классический пример востребованности. ) Работа с графикой и видео - туда же. Проекты Folding@home и Rosetta@home убедительно доказали, что перенос части расчета на GPU дает колоссальный выигрыш и в научных вычислениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 18:45 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
AdxmaytonGPU-вычисления так и останутся в сегменте невостребованного. Как раз Ваша идея о проверке производительности CPU с помощью алгоритма рендеринга 3D-графики - классический пример востребованности. ) Работа с графикой и видео - туда же. Проекты Folding@home и Rosetta@home убедительно доказали, что перенос части расчета на GPU дает колоссальный выигрыш и в научных вычислениях. Я-же говорил что я не претендую на ПРАВИЛЬНОСТЬ обоснования задачи. Предложите ваши варианты. Должны быть охвачены сегменты CPU/Memory/IO. По отдельности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 18:49 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
maytonЯ-же говорил что я не претендую на ПРАВИЛЬНОСТЬ обоснования задачи. Предложите ваши варианты. Должны быть охвачены сегменты CPU/Memory/IO. По отдельности. Ничего против Вашей задачи я не имею. То, что она идеально ложится на связку CPU+GPU не означает, что она не подходит для сравнения языков по CPU. Впрочем, я о классе задач, возможно предложенный Вами вариант на GPU и не ложится. Нужно смотреть детально алгоритм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 18:58 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Исходник на сях уже готов. Возможно сегодня опубликую отдельным топиком. Осталось портировать его на Java/C#/Python. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 19:12 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Если развести философию по теме, то С/С++ такой же фрэймворк/виртуальная машина над ассемблером, как и другие языки. Только наиболее близко опущенный до уровня асма. У каждого проца есть свои плюсы и минусы, но в связи с тем что даже x86/x64 процов целый зоопарк (Intel на каждом шаге добавляет новые команды и оптимизирует старые), то уже никто не заморачивается на подгонку софта под проц. Заметил когда баловался расчетом простых чисел , небольшая подстройка алгоритма меняет скорость работы в разы на одном компе и почти не влияет на другом. Т.е. идеал - подстройка асм-кода под конкретный проц, т.е. учесть имеющийся набор команд, размер кэшей и т.д. Уверен что есть куча рекомендаций от производителей процов по этому поводу, но т.к. писать под весь зоопарк на асме задача неподъемная (большинству), то был придуман С (точнее он был придуман в эпоху предыдущего зоопарка, но не суть). Благодаря его широкому распространению выгодно дорабатывать компиляторы, поэтому тот же самый код собранный более свежим компилятором работает быстрее. На 100% уверен что EXE после современного компилятора не заработает на первом 32-битном проце Intel 386. Более того, пытаясь поставить линукс на не столь старый ноут с Pentium M, удивился что он не встает, т.к. там нет какого-то поднабора команд для работы с большими наборами памяти, интел тогда счел их ненужными для ноутов. Выше приведенный аргумент что виртуальные машины/интерпретаторы/jit-компиляторы написаны на С/С++ не выдерживает никакой критики. А чего не на асме с учетом особенностей конкретного проца? Может было бы быстрее на 10-200%. Тесты производительности тоже ниочем. Ну получили производительность в 2-3 раза быстрее, а завтра надо будет расшириться в 100 раз и все равно упремся в предел, что делать? Какая разница если предел есть? Не важно наступит он завтра или послезавтра, главное что наступит. Поэтому пофиг на чем писать (задачи требующие реалтайм опускаем). Главное писать так чтобы при наступлении пределов был четкий план как их обойти. Вопрос ресурсов тут вторичный, т.е. сколько денег на железо потребуется. Но если это не прогнозировать, то в один прекрасный день наступит понимание что проблема усилением железа не решается и надо начинать разработку с нуля, а это на порядки больше денег. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 19:15 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Dima TЕсли развести философию по теме, то С/С++ такой же фрэймворк/виртуальная машина над ассемблером, как и другие языки. Только наиболее близко опущенный до уровня асма. У каждого проца есть свои плюсы и минусы, но в связи с тем что даже x86/x64 процов целый зоопарк (Intel на каждом шаге добавляет новые команды и оптимизирует старые), то уже никто не заморачивается на подгонку софта под проц. Если ты не в курсе, то ассемблер это не самый нижний уровень. Есть еще уровень внутреннего микрокода конкретного процессора. На нем надо писать. Вообще то я писал, что реальная производительность сейчас упирается не в скорость вычислений (качество компилятора), а в размеры ресурсов для его обслуживания. Т.е. считаем вроде быстро, но следующий кусок кода приходится подгружать с другой планеты (диска). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 20:25 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглЕсли ты не в курсе, то ассемблер это не самый нижний уровень. Есть еще уровень внутреннего микрокода конкретного процессора. На нем надо писать. Если честно - не в курсе. На асме писал 20 лет назад. ЗимарглВообще то я писал, что реальная производительность сейчас упирается не в скорость вычислений (качество компилятора), а в размеры ресурсов для его обслуживания. Т.е. считаем вроде быстро, но следующий кусок кода приходится подгружать с другой планеты (диска). Если мои выводы почитал, то понял бы что пофиг откуда последний кусок кода берется. В итоге такого "успешного" кода будет тупик требующий полной переписки кода. Еще раз: главное алгоритмы позволяющие масштабируемость, на чем они реализованы - вторично, т.е. пофиг на чем написано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 20:32 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглЕсли ты не в курсе, то ассемблер это не самый нижний уровень. Есть еще уровень внутреннего микрокода конкретного процессора. На нем надо писать. Если вы писали - то поделитесь полезными юзкейсами. Ту инфу которую я собирал по этому вопросу можно количественно охарактеризовать как "ноль инфы". Всё недокументировано. Vendor-depends. В некоторых форумах спецы по железу фиксили проблемы конкретных моделей или линеек накатывая микрокод от производителя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2015, 23:12 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглЭто неверно. Проверяется следующим образом - щелкаем по интерфесу дНетовской софтинки и смотрим как меняется показатель "Ошибки страниц" в Диспетчере задач. Это подгрузка с диска интерфейсных классов. Это верно при первом запуске. Пока они не попали в кэш диска ОС. Включил комп. Запускаю MSSQL Managment Studio 2012 (.Net 4.0) Процесс ssms.exe: Хрустит винтом секунд 7-8, Ошибок страниц 38 000. Закрываю. Запускаю снова, 1-2 секунды, ошибок страниц 39 000, винта не слышно. Все потому что нужный код уже в кэше ОС. Формально ошибка страницы это когда код/данные отсутствуют в памяти процесса, а вот откуда они будут подгружаться - это данный параметр никак не учитывает. При достаточном количестве оперативки проблемы чтения с HDD неактуальна. Остается только проблема со скоростью записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 07:11 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
C# пока только начинаю осваивать, поэтому знаю чуть-чуть теории и 0 практики. Как понимаю основные тормоза при старте тяжелого приложения из-за JIT-компиляции, которая идет при каждом запуске. Но этого можно избежать если откомпилировать сборку заранее https://msdn.microsoft.com/ru-ru/library/6t9t5wcf(v=vs.110).aspx Там правда как-то все мутно и не просто, но думаю если разобраться, то вполне применимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 07:48 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Недавно встретил у Лафоре, но не уверен, актуальна ли эта фраза: Robert Lafore OOP in C++ fourth editionOf the object-oriented programming languages, C++ is by far the most widely used. Java, a recent addition to the field of OO languages, lacks certain features-such as pointer, templates, and multiply inheritance - that make it less powerfull and versatile than C++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 09:06 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
SashaMercuryНедавно встретил у Лафоре, но не уверен, актуальна ли эта фраза: Robert Lafore OOP in C++ fourth editionOf the object-oriented programming languages, C++ is by far the most widely used. Java, a recent addition to the field of OO languages, lacks certain features-such as pointer, templates, and multiply inheritance - that make it less powerfull and versatile than C++. Роберту нужно было в начале предложения добавить "ИМХО" Говорить, что Джава "слабее, из-за того, что в ней нет множественного наследования, указателей и шаблонов как-то уж очень холли варно.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 10:24 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39040852&tid=1340912]: |
0ms |
get settings: |
9ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
181ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 489ms |

| 0 / 0 |
