Всё решает кэш, всё остальное - понты?

вот как-то даже и сказать нечего
вообще нечего

Также получается, что си и с++ быстрее явы

citation needed

только из-за того, что их структуры занимают меньше места в памяти, поэтому попадание в кэш происходит чаще, а использование мегатормозной памяти - реже?

В Java код вообще не имеет фиксированую форму в памяти и JVM может все перекомпилить в любой момент по новому на основе PGO

вообще нечего

В смысле я прав или что?

https://en.wikipedia.org/wiki/Comparison_of_Java_and_C++ http://www.jelovic.com/articles/why_java_is_slow.htm

В Java код вообще не имеет фиксированую форму в памяти и JVM может все перекомпилить в любой момент по новому на основе PGO

Причёт тут? Основное ждущее память - это данные.

сложилось впечатление, что память - это основной botlneck после подгрузки данных с накопителя (PCI-e SSD)

Отродясь так было, откуда ты выпал? Люди ещё до всяких кэшей стремились данные по регистрам распихать - когда ещё данных было столько, десятка регистров хватало.

что си и с++ быстрее явы только из-за того, что их структуры занимают меньше места в памяти

Си и кресты не быстрее жабы в общем случае.

попадание в кэш происходит чаще, а использование мегатормозной памяти - реже

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

Отродясь так было, откуда ты выпал?

Я ж весьма ньфаг: на бзде всего 15 лет сижу.

Люди ещё до всяких кэшей стремились данные по регистрам распихать - когда ещё данных было столько, десятка регистров хватало.

Это как? Регистров на всех не хватит в любом случае.

Си и кресты не быстрее жабы в общем случае.

Но не в случае, когда много данных.

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

Примеры?

Кстати, а как можно узнать, какая грануляция у кэшей? Они же не 4Кб-странцы кэшируют.

Я думал ты о кешах кода. А почему тогда в Java они занимают больше? Конкретная структура не занимает больше.

Там все сложнее, у Java приложения больше footprint из-за особенностей того как GC располагает занятые участки памяти. Так же он может складывать их в кучу специально для улучшения вероятности попадания в кеш. В такое стабильное состояние много приложений попадают после начального разогрева

вообще - да, ты прав
в количественном смысле

Примеры?

Loop skewing, loop tiling? Polytope model?

Кстати, а как можно узнать, какая грануляция у кэшей?

Прогнать тест с разным страйдом?

Разные задачи, разная нагрузка. Я у себя на компьютере редко вижу 100% загрузки. Может и в диск упираться, может и в память, может и в скорость процессора.

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

Опять же смотря на каких задачах. Вполне может быть, что GC джавы расположит все данные рядом, а дефолтный C++-ный malloc раскидает по всем углам и в C++ будет хуже.

У интела есть профайлер, который показывает, чем занимался процессор — ожиданием памяти, неправильными предсказаниями перехода или ещё чем-то. Другой вопрос, что делать с этой информации при программировании на Java.

а всё остальное - понты

Еще зависит от того как с тредами работаешь и аппаратурой. Если юзаешь CAS и thread affinity, заместо мьютексов и отпуская треды на волю случая, то можешь серьезно получить буст перформанса. Если юзаешь прямой доступ к сетевому стеку, в обход ядра, то опять же получишь буст перформанса.

Также получается, что си

В Си нет ООП, так что потенциально оно может быть быстрее Java и С++, ибо нет оверхедов в виде RTTI и virtual methods.

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

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

то он обычно на уровне Java или даже медленее

Ява быстрее ассемблера (с) чо уж там.

Также получается, что си и с++ быстрее явы только из-за того, что их структуры занимают меньше места в памяти

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

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

и DDR4

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

Получается, что для всех современных (т.е. «жирных») задач - всё решается кэш (и DDR4), а всё остальное - понты?

Да.

Жаба - интерпретируемый язык, остальное - компилируемый. Разницу между работой интерпретатора и выполнением машинного кода надо объяснять? Да, типа есть прекомпиляция в байт-код. Разницу в работе такого прекомпиленного байткода и чистого машинного кода, работающего без JVM объяснять надо? Собственно, оверхед по памяти и кеша ты считаешь только от объема данных, а не от дополнительных сущностей, жрущих ресурсы?

сложно запихнуть в 8-16Мб памяти все данные приложения

А... Ты где такой кэш нашёл в 8 Мбайт? У меня на сравнительно новом проце L3 3 мегабайта. Мне сдаётся, ты не совсем понимаешь, что такое кэш и для чего используется, а самое главное, как.

Ты про jit не слыхал, да?

оооо. JIT - великая весчь. Так сколько твоя программа на жабе после запуска раз перекомпилирована будет? Исходный код -> байткод, байткод -> машинный код. А этот машинный код один хрен работает сквозь JVM -> просадка по производительности.

JAVA - быстрая разработка, легкая поддержка, но никак не скорость. Я до сих пор в шоке с того, как много дебилов, пихающих это в embedded.

А этот машинный код один хрен работает сквозь JVM -> просадка по производительности.

Сквозь какую jvm? Ты идиот?

оооо. JIT - великая весчь. Так сколько твоя программа на жабе после запуска раз перекомпилирована будет?

Какая разница? Все равно ты времени компиляции не заметишь.

Сквозь какую jvm? Ты идиот?

Java Virtual Machine. Идиота я пока вижу здесь только в тебе. Без JVM оно не будет работать в любом случае. Да, ускорение на повторяющихся операциях. Да, он меньше, чем если бы JIT не было. Но ты так говоришь, как будто, время затрачиваемое на компиляцию ничего не стОит.

Какая разница? Все равно ты времени компиляции не заметишь.

Ты идиот? Оно что, такты процессора не расходует? Память не жрёт в этот момент? Преобразования происходят на отдельно взятом квантовом компьютере с бесконечной производительностью и не вносят оверхед?

JIT может заставить работать программу быстрее, чем если бы она статически скомпилирована была, но только за счет компиляции под целевую систему, чего не делает ни одна существующая на данный момент реализация. Так же динамическая компиляция может быть быстрее в некоторых специфических случаях, которые в общем применимы не всегда и не везде. В большинстве же случаев никакая динамическая компиляция не ускоряет ПО в сравнении со статической.

Ты идиот? Оно что, такты процессора не расходует? Память не жрёт в этот момент?

Какая разница, расходует или нет, если ты этого никак не сможешь заметить? Ну съело оно сотню мегабайт памяти из десятка террабайт и отожрало секунду работы процессора из десятка часов, что дальше?

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

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

Java Virtual Machine. Идиота я пока вижу здесь только в тебе. Без JVM оно не будет работать в любом случае. Да, ускорение на повторяющихся операциях. Да, он меньше, чем если бы JIT не было

Ну что Java Virtual Machine? Какие операции Java Virtual Machine совершает, что скомпилированный код ВНЕЗАПНО становится медленнее? Нопы расставляет или как оно по-твоему?

JIT может заставить работать программу быстрее, чем если бы она статически скомпилирована была, но только за счет компиляции под целевую систему, чего не делает ни одна существующая на данный момент реализация.

Во-первых, не только, читай про трассирующие джиты. во-вторых - с чего ты взял, что не делает?

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

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

Какие операции Java Virtual Machine совершает

Она висит в рантайме. Т.е. переключение контекста + расход памяти как минимум.

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

И при чем тут джит? При запуске джит вообще не работает, а «периодически тормозит» гц, а не джит. Программа на сишке в эти моменты, кстати, где джава «тормозит» ликает память или валится с сегфолтом.

Программа на сишке в эти моменты, кстати, где джава «тормозит» ликает память или валится с сегфолтом.

Да, расскажи мне ещё сказок.

Для сервера 100 метров памяти это 10 (!) дополнительных клиентов, которые приносят деньги.

Это не сказки, это реальность. Тормозящая из-за гц программа - это недоработка прогарммиста. Разница между манагед-языками и сишкой состоит в том, что если манагед-языки в случае недоработки программиста тормозят, то сишка вдобавок еще будет плеваться сегфолтами.

Если же мы сравниваем программу на сишке, которая не сегфолтится, то есть написана качественно, то ее надо сравнивать с программой на жабке, написанной качественно, логично, нет?

Разница между манагед-языками и сишкой состоит в том, что если манагед-языки в случае недоработки программиста тормозят, то сишка вдобавок еще будет плеваться сегфолтами.

Т.е. ты приплетаешь программиста. Молодец. В случае, если программа обращается в памяти не туда, куда нужно - она работать не должна, процесс должен быть прерван. Понимаешь?

логично, нет?

Логично. Теперь давай разберёмся, что же в реальности у жабки делает jit?

Логично. Теперь давай разберёмся, что же в реальности у жабки делает jit?

В реальности джит делает везде то, что и должен делать - компилирует байткод в машкод.

Т.е. ты приплетаешь программиста. Молодец. В случае, если программа обращается в памяти не туда, куда нужно - она работать не должна, процесс должен быть прерван. Понимаешь?

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

В реальности джит делает везде то, что и должен делать - компилирует байткод в машкод.

И в реальности такой код работает медленнее в большиснтве случаев, чем если бы был скомпилирован статически.

а если

Вот о чем я и говорю. Выдумал что-то в себе и доказывает.

Лучше пусть тормозит, чем падает, нет?

Лучше нанять квалифицированного программиста?

И в реальности такой код работает медленнее в большиснтве случаев, чем если бы был скомпилирован статически.

Ты уже заебал. Еще раз - тормоза джавы НЕ ИЗЗА ДЖИТА. Машкод скомпилированный джитом - это тот же машкод, который работает ТОЧНО так же как обычный статически скомпилированный машкод. Затраты на саму компиляцию джитом - пренебрежимо малы. Ты никогда не сможешь в слепом тесте отличить статически скомпилированный код от байткода с джитом.

Лучше нанять квалифицированного программиста?

Да памяти купить дешевле, чем квалифицированного программиста нанимать. Вон, ты сам выше сказал - по 2гб на машину впихнуть всего 4кк стоит.

тормоза джавы НЕ ИЗЗА ДЖИТА

Но JIT никак не быстрее статической компиляции в ней. Я не говорю, кстати, что тормоза джавы из-за него. Тормоза они у неё архитектурные.

Затраты на саму компиляцию джитом - пренебрежимо малы

Расскажи это процессорам Intel Atom.

Да памяти купить дешевле, чем квалифицированного программиста нанимать. Вон, ты сам выше сказал - по 2гб на машину впихнуть всего 4кк

При условии, что программист напишет приложение значительно дешевле. Так как я показал прямые затраты, а так - там только обрудование учтено, а не учтена работа эникеев, саппорта, админов... Плюс это надо еще логистику напрячь, раскидать по филиалам. Или ты думаешь, что там только планки столько стОили? Нет, там местами пришлось менять всё железо, ибо железо не умело много памяти. Плюс еще под это потребуется создание ЗИП. Знаешь, что это такое? А знаешь, что в РФ в среднем ИТР получает не более 400к в год? Просвещайся, пока у меня есть время и я добрый.

Но JIT никак не быстрее статической компиляции в ней.

Он _может_ бысть быстрее (потенциально). Но это исключение, в общем джит = обычный машкод по скорости, да.

Расскажи это процессорам Intel Atom.

Что рассказать? Затраты на джит пренебрежимо малы по сравнению с затратами на сам исполняемый код, это на любых архитектурах.

При условии, что программист напишет приложение значительно дешевле.

А может и не напишет. В то время как память поставил - и все гарантированно работает. Потому джаву и используют. Дешево и надежно.

пренебрежимо малы

Ты это сам придумал?

Потому джаву и используют. Дешево и надежно.

Порог вхождения низкий. Соответственно специалисты по жабе дешевле.

В то время как память поставил - и все гарантированно работает

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

Ты это сам придумал?

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

Порог вхождения низкий. Соответственно специалисты по жабе дешевле.

Правильно, о чем я и говорю. У неквалифицированного сишника программа будет сегфолтиться, квалифицированный - дорог. Неквалифицированный жабист напишет несегфолтящуюся, но тормозную программу, а тормоза решаются покупкой памяти. Связка жабист+память дешевле, чем сишник. И надежнее, более предсказуема в эффекте. А в бизнесе даже не столько затраты важны, сколько предсказуемость.

Если задачу определить - будет не сферический конь в вакууме.

Ты, напомню, пару постов назад вообще говорил о «сферической джаве в вакууме». Теперь уже до тебя дошло что есть задачи и есть инструменты. Вижу прогресс. Может, и челвоеком станешь.

Так ты ж на частности скатываешься, куда деваться. Ты ж опять вместо JS (тоже джава) начал мне про JIT рассказывать.

Связка жабист+память дешевле, чем сишник.

И это не отменяет того, что в общем случае софт на жабе медленнее. Понимаешь?

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

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

Ты ж опять вместо JS (тоже джава) начал мне про JIT рассказывать.

1. о джите начал говорить не я

2:

вместо JS (тоже джава)

JS (тоже джава)

JS

тоже джав

JS

ясно, я все жто время разговаривал с дегенератом

ясно, я все жто время разговаривал с дегенератом

Да нет. Ты просто начал гнуть свою линию.

он просто будет показывать 100% загрузки, тогда как реально процессор 90% времени ожидает память.

В Linux-системе оно, скорее всего, будет показывать 100% загрузки System. Так что можно увидеть, да.

Да ладно, обосрался со своим «джаваскрипт - тоже джава» так обосрался. Со всеми бывает.

Мальчик, ты дебил? Хотя бы даже младшие Зионы видел?

Мальчик, ты таки реально дебил.

Все решают понты, остальное кэш.

Думал с утра царя дочитаю, а тут вместо него какое-то унылое подобие Бати.

у меня сложилось впечатление, что память - это основной botlneck после подгрузки данных с накопителя

Пф... тоже блин открытие... График оцтавания RAM от кэша во всех мануалах по оптимизации. Алсо иерархию памяти ни разу не вчера придумали. Харэ уже будоражить сенсациями.