Здравствуйте, Sinix, Вы писали:
S>Ну вот прям щас я смотрю на сервис под типовой нагрузкой. ~20% cpu, из них gc time 0.09% (90й перцентиль), 1.2% (95й перцентиль). Это при условии, что с перфомансом и оптимизацией под gc никто не заморачивался. Ради красивых циферок можно уменьшить обе цифры где-то на треть-половину, но мы вместо этого лучше ещё плюшек клиентам подкинем.
Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения. И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза.
Здравствуйте, alex_public, Вы писали:
_>Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения.
Эт какие?
Всё, что принципиально требует gc: список корней для safepoint (точек, в которой возможен сбор мусора) + способ перебрать managed references для каждого объекта. Вон в ms research интерны на llvm это дело перегоняют и оно вроде бы даже работает.
_>И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза.
2-3 — эт сильно постараться надо. Вот типовой расклад (на .net native не смотрим, там ранняя бета ещё). Основной затык в автоматической векторизации, как минимум до следующего релиза её можно не ждать.
С другой стороны, если есть возможность заметно ускорить код переводом части в натив и это не отражается на стоимости поддержки — кто мешает-то?
Здравствуйте, Sinix, Вы писали:
_>>Дело не во времени отработки самого сборщика мусора (хотя для некоторых задач и оно принципиально, например для обеспечения реального времени), а в том, что для возможности его работы на платформу накладываются очень серьёзные ограничения.
S>Эт какие?
S>Всё, что принципиально требует gc: список корней для safepoint (точек, в которой возможен сбор мусора) + способ перебрать managed references для каждого объекта. Вон в ms research интерны на llvm это дело перегоняют и оно вроде бы даже работает.
Ну на самом деле сборщики мусора бывают разные... К примеру такой как в D не вносит архитектурных ограничений на платформу. Но зато у него у самого с производительностью не очень (правда в D можно и без него работать, так что это не проблема). Если же смотреть на сборщики мусора типа стандартных из jvm или .net, то там сразу возникает множество ограничений (ну например запрет арфметики указателей, дополнительный расход памяти и т.п.). Правда .net в unsafe режиме снимает часть ограничений, но только часть и к тому же тогда теряется часть смысла от использования этой платформы.
_>>И вот уже эти ограничения вполне себе приводят к отставанию в производительности от C++ решений в 2-3 раза. S>2-3 — эт сильно постараться надо. Вот типовой расклад (на .net native не смотрим, там ранняя бета ещё). Основной затык в автоматической векторизации, как минимум до следующего релиза её можно не ждать.
Вообще то цифры по ссылке как раз подтверждают мои слова))) Да, и кстати автовекторизация в C++ к сожалению пока не особо сильная. В моих тестах она не особо отличалась от C# варианта (правда тот подключался только в unsafe режиме, а в обычном не мог подобраться к циклу) и существенно уступал ручной векторизации. Но т.к. ручная тоже в C++ вполне легко реализуется (хотя такое конечно же актуально только для критичных к производительности участков), то это не проблема для C++.
S>С другой стороны, если есть возможность заметно ускорить код переводом части в натив и это не отражается на стоимости поддержки — кто мешает-то?
А в чём смысл использования двух технологий? Если уж потратились на спецов по нативу, то можно и всё им передать. )
Здравствуйте, Stanislaw K, Вы писали:
V>>Прямо на сегодня, на сколько я понял, эта технология хороша как замена флеш-памяти. Но почему-то не вижу характеристик ни времени хранения, ни циклов перезаписи.
SK>Потому что это только концепция. Красивые картинки для инвесторов.
Опытные рабочие образцы есть уже пару лет минимум, в 2014-м они планировали промышленное производство.
Я думаю, дело в том, что быстродействие обычной и флеш-памяти тоже растет, т.е. им придется развивать технологию с опережением до выхода на промышленный уровень.
SK>Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
Вообще-то HP говорит другое: "мы не хотим обрушить рынок флеш-памяти прямо сейчас". Были сделаны большие инвестиции и ими в том числе, походу, хотят отбить вложения. Знач, новую технологию попридержат на лет 5 запросто.
Здравствуйте, vdimas, Вы писали:
SK>>Потому что это только концепция. Красивые картинки для инвесторов. V>Опытные рабочие образцы есть уже пару лет минимум, в 2014-м они планировали промышленное производство.
И что же им помешало?
V>Я думаю, дело в том, что быстродействие обычной и флеш-памяти тоже растет, т.е. им придется развивать технологию с опережением до выхода на промышленный уровень.
Быстродействие тут вообще не при чем. или ты намекаешь что там тактовая частота, у опытных рабочих образцов, меньше 100 мегагерц?
SK>>Там прямо и сказано: "мы хотим разработать" == скоро будет == еще не существует == дайте бабла == очень кушать хочется == не из чего дивиденды акционерам платить.
V>Вообще-то HP говорит другое: "мы не хотим обрушить рынок флеш-памяти прямо сейчас". Были сделаны большие инвестиции и ими в том числе, походу, хотят отбить вложения. Знач, новую технологию попридержат на лет 5 запросто.
С учетом монополии на технологию, патентные и лицензионные отчисления — они за эти пять лет могли бы озолотится трижды. Придержат потому, что ничего нет.
Здравствуйте, Farsight, Вы писали:
F>Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность?
А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Здравствуйте, Sheridan, Вы писали:
S>А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Если в большом проекте используется ручное управление памятью — это дополнительная нагрузка на мозг каждого участника команды разработчиков. Разве нет?
Здравствуйте, Sheridan, Вы писали:
F>>Почему ты считаешь, что там гц, тут гц, здесь гц, еще тут гц и вот тут гц серьёзно влияет на производительность? S>А почему ты думаешь, что я про "серьезно"? Любая дополнительная нагрузка — зло.
Даже если этой дополнительной нагрузки 1 секунда в час?
В общем, если погуглить, то можно прийти к выводу, что это все относится к Memcomputing . Основная идея — хранение и обработка информации в одном месте.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Если вы понимаете, что такое ВП, то должны понимать, что в средах с быстрой, однородной, энергонезависимой памятью она не нужна.
А фрагментация и прочие всякие CoW мапинги?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Privalov, Вы писали:
P>Если в большом проекте используется ручное управление памятью — это дополнительная нагрузка на мозг каждого участника команды разработчиков. Разве нет?
Лучше один раз сжечь мозг программисту за время разработки, чем постоянно дымить процессором при эксплуатации.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Смартпоинтеры не используешь?
я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Здравствуйте, dimgel, Вы писали:
D>Сам-то небось на ассемблере пишешь, раз такие предъявы кидаешь, м?
Я вот иногда пишу. Докладываю, что современный компилятор обогнать в асме малореально.
Один из реалистичных сценариев -- пишешь свой JIT компиллер под задачу...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Muxa, Вы писали:
M>1. одно дело писать простенькие консольные тулзы, где память алоцируется один-два раза в паре мест, и совсем другое писать большие приложения с сотнями тысяч строк кода в тысячах файлов.
Йо! У вас среднем файле сто строк?..
M>2. лишь часть программистов имеют достаточную квалификацию, чтобы не допускать багов с утечкой памяти.
Адекватное восприятие себя и реальности -- это хорошо. Я от, например, иногда таки допускаю...
M>3. почему я пишу такие банальности?
Аутотренинг?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sheridan, Вы писали:
S>я — нет. Считаю что использование смартпоинтеров где попало суть роспись в собственной некомпетентности и полнейшего непонимания разрабатываемого проекта.
Здравствуйте, Sheridan, Вы писали:
S>Лучше один раз сжечь мозг программисту за время разработки, чем постоянно дымить процессором при эксплуатации.
Во все времена сделать так, чтобы процессор не дымил, было одной из важнейших задач. В старые времена ВЦ можно было распознать по обилию кондиционеров в окнах здания. Сейчас для процессоров существует масса систем охлажления, от простых кулеров до жидкостных. Так что сохранить процессор несложно. И даже если, несмотря ни на что, процессор сгорит, его заменить — достаточно дешево.
А вот если сожжешь мозг программисту — огребешь проблем по самые ноздри. Сожженный мозг не вернуть.
Свой-то мозг ты сжигать не торопишься.
UPD. А почему ты рещил, что мозг разработчика никому не понадобится после ввода продукта в эксплуатацию?
Здравствуйте, Privalov, Вы писали:
P>Во все времена сделать так, чтобы процессор не дымил, было одной из важнейших задач. В старые времена ВЦ можно было распознать по обилию кондиционеров в окнах здания. Сейчас для процессоров существует масса систем охлажления, от простых кулеров до жидкостных. Так что сохранить процессор несложно. И даже если, несмотря ни на что, процессор сгорит, его заменить — достаточно дешево.
Экономить ресурсы не любим, ок. Позиция тоже ок: "Нам пофиг как и где оно будет работать, нам пофиг затраты на оборудование, нам пофиг на всё, у нас всё работает"
P>А вот если сожжешь мозг программисту — огребешь проблем по самые ноздри. Сожженный мозг не вернуть. P>Свой-то мозг ты сжигать не торопишься.
С чего ты взял?
P>UPD. А почему ты рещил, что мозг разработчика никому не понадобится после ввода продукта в эксплуатацию?
Понадобится. Только вот вариант что мозг не сгорит, а закалится — тоже присутствует, причём это хороший фильтр получится, отделяющий говнокодеров от программистов.
