M>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
Я вчера как раз кейген написанл на с++, правда кейген верхнего уровня все равно на пхп
Здравствуйте, Mamut, Вы писали:
M>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Mamut, Вы писали:
M>>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
DM>Ну, некоторые (гугл, яндекс) таки пишут на С++.
у них небось недостаточно нагруженные системы для .net
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
M>>Это давно уже не проблема, VDS стоит недорого. Но почему-то все пишут на чем угодно — питоне, руби, пхп, яве, сишарпе, но только не на С++. Почему бы это?
DM>Ну, некоторые (гугл, яндекс) таки пишут на С++.
Ну, эти монстры — всем монстрам монстры, и использование С++ там оправдано, имхо
Прошу прощение за запоздалый ответ, не было времени написать benchmark раньше.
E>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>Выделенное еще надо доказать.
Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты:
Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
G>Часто бывает так что выгоднее создать дополнительную копию данных, расположенных в другом проядке, чтобы увеличить быстродействие.
Я полагал, что мы сейчас говорим не о случаях, когда за оптимизацию расхода памяти отвечает программист, а о случаях, когда на программу накладываются дополнительные накладные расходы помимо того, что сделал программист. В языках со сборкой мусора такими накладными расходами является не убранный GC мусор -- пока GC не пройдется этот объем может вызывать промахи мимо кэша. А может и не вызывать.
E>>Конечно, управляемые среды могут противопоставить compacting GC фрагментации памяти в C++. Но в любом случае, сейчас вопросам потребления и работы с памятью придется уделять гораздо больше внимания, чем несколько лет назад. G>Но это не значит что память стоит экономить.
Я очень удивлен тем, что из сказанный мной слов вы все-таки сделали вывод о том, что сейчас память не стоит экономить.
Ну и еще о том, что C++ гордятся низким потреблением памяти...
We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a noncopying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
Мне кажется, что причины для этого таки есть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas
E>Прошу прощение за запоздалый ответ, не было времени написать benchmark раньше.
E>>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>>Выделенное еще надо доказать.
E>Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты: E>
E>Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
Так это касается только конкретной реализации std::mapю
G>>Часто бывает так что выгоднее создать дополнительную копию данных, расположенных в другом проядке, чтобы увеличить быстродействие.
E>Я полагал, что мы сейчас говорим не о случаях, когда за оптимизацию расхода памяти отвечает программист, а о случаях, когда на программу накладываются дополнительные накладные расходы помимо того, что сделал программист. В языках со сборкой мусора такими накладными расходами является не убранный GC мусор -- пока GC не пройдется этот объем может вызывать промахи мимо кэша. А может и не вызывать.
Мусор тут вообще ни при чем, гораздо больше зависит от самого алгоритма.
E>Ну и еще о том, что C++ гордятся низким потреблением памяти...
E>Cуществует исследование Quantifying the Performance of Garbage Collection vs. Explicit Memory Management, в котором, в частности, говорится: E>
E>We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a noncopying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
E>Мне кажется, что причины для этого таки есть.
Конечно есть. Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно. GC рассчитан на то чтобы в среднем случае работать не хуже стандартных аллокаторов.
Здравствуйте, eao197, Вы писали:
E>Вот простой тест. Создается std::map, в котором случайным образом обновляются элементы. В случае маленьких std::map, помещающихся в кэши процессора, обновления должны проходить быстрее, чем в случае больших std::map. У меня на машине с 4Mb L2 получаются следующие разультаты: E>
Здравствуйте, gandjustas, Вы писали:
E>>>>Времена, когда память была RAM, давно прошли (за подробностями обращайтесь к мегапостам remark-а в "Философии программирования"). Сейчас, с многоуровневым доступом через разные кэши к медленной памяти, чем меньше памяти потребляет программа и чем более последовательно она по ней ходит, тем быстрее она работает. Посему, чем больше памяти отжирает программа, чем чаще промахи мимо кэша, тем дольше программа ждет данных и тем медленее работает. G>>>Выделенное еще надо доказать.
E>>Видно, что по мере разростания дерева поиска скорость работы с одним элементом падает.
G>Так это касается только конкретной реализации std::mapю
Вы усомнились в том, что при работе с большими объемами данных скорость может серьезно падать только из-за промахов мимо кэша процессора. Я привел пример, который это наглядно демонстрирует. Можете списать его на детали реализации std::map, если вам так проще.
Ситуация, однако, такова, что при современной организации доступа к памяти программистам придется даже пересматривать свое отношение к традиционно-используемым структурам данных. Например, к таким, как двоичные деревья поиска или даже одномерные массивы.
G>Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно.
Пожалуйста, продолжайте придерживаться этого мнения и дальше. У меня складывается впечатление, что чем больше Java/.Net-разработчиков будут так думать, тем дольше будет сохраняться спрос на C++ников.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Вы усомнились в том, что при работе с большими объемами данных скорость может серьезно падать только из-за промахов мимо кэша процессора. Я привел пример, который это наглядно демонстрирует. Можете списать его на детали реализации std::map, если вам так проще.
Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
G>>Во многих случаях ручное распределение памяти может оказаться быстрее, чем сборщик мусора. Но для этого придется писать кастомный аллокатор для каждого конкретного куска кода, что очень затратно. E>Пожалуйста, продолжайте придерживаться этого мнения и дальше. У меня складывается впечатление, что чем больше Java/.Net-разработчиков будут так думать, тем дольше будет сохраняться спрос на C++ников.
Всегда будут люди, которые думают что на C++\С\ассемблере можно написать код быстрее.
Здравствуйте, gandjustas, Вы писали:
G>Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
Еще раз. Речь не идет об ухищрениях, на которые идет программист для повышения производительности. Если человек решил продублировать данные в памяти для повышения производительности конкретной операции, то здесь не суть важно, использует ли он C++ или Java -- это решение человека. Речь идет о том, какие накладные расходы может наложить GC на приложение в современных условиях. Например, захочет GC построить граф достижимости объектов, прошерстит 100Mb данных в памяти и выкинет из кэша процессора все нужные в данный момент страницы. Может такое быть или нет?
G>Всегда будут люди, которые думают что на C++\С\ассемблере можно написать код быстрее.
Я категорически требую включения в этот список еще и Фортрана, т.к. он до сих пор рулит в области HPC и конкурентов, по сути, не имеет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Я знаю что промахи кеша снижают производительность, но увеличение размеров используемой памяти далеко не всегда приводит к увеличению количества промахов. Есть даже обратные примеры.
E>Еще раз. Речь не идет об ухищрениях, на которые идет программист для повышения производительности. Если человек решил продублировать данные в памяти для повышения производительности конкретной операции, то здесь не суть важно, использует ли он C++ или Java -- это решение человека. Речь идет о том, какие накладные расходы может наложить GC на приложение в современных условиях. Например, захочет GC построить граф достижимости объектов, прошерстит 100Mb данных в памяти и выкинет из кэша процессора все нужные в данный момент страницы. Может такое быть или нет?
Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах.
А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет.
Здравствуйте, gandjustas, Вы писали:
G>Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах. G>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет.
При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Когда у вас 100мб данных, то вам надо не о кеше процессора беспокоиться, а о страницах памяти. Кеш процессора играет роль на значительно меньших объемах. G>>А по поводу GC — вам стоит почитать как он работает, просто так он шерстить 100 метров не будет. C>При полном цикле GC — будет. Поэтому GC абсолютно не совместим со swap'ом.
Что такое полный цикл GC? Как вызвать полный цикл?
Здравствуйте, gandjustas, Вы писали:
А>>>Paint.NET — 155 Mb А>>>MS Paint — 145 Mb А>>>SnagIT — 55 Mb
G>Специалисты пограмотнее, чем у адобы видимо. G>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!).
А почему это хорошо?
Фотошоп хитро очень с памятью и дисками работает. И любит хавать "про запас". Но это только если памяти реально много...
Честно такой тест провести: Заводить RAM диски разных размеров, чтобы память отъесть и смотреть на СКОРОСТЬ РАБОТЫ того и другого в условиях разной степени жёсткости дефицита памяти...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
А>>>>Paint.NET — 155 Mb А>>>>MS Paint — 145 Mb А>>>>SnagIT — 55 Mb
G>>Специалисты пограмотнее, чем у адобы видимо. G>>на нескольких компах проверил как работает paint.net и сравнил с фотошопом. На одних и техже операциях paint.NET хавает меньше памяти (!).
E>А почему это хорошо? E>Фотошоп хитро очень с памятью и дисками работает. И любит хавать "про запас". Но это только если памяти реально много...
чем больше памяти отжирает программа, чем чаще промахи мимо кэша(не я сказал).
Кстати фотошоп абсолютно одинаково хавает память независимо от объема установленной.
E>Честно такой тест провести: Заводить RAM диски разных размеров, чтобы память отъесть и смотреть на СКОРОСТЬ РАБОТЫ того и другого в условиях разной степени жёсткости дефицита памяти...
Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
Здравствуйте, gandjustas, Вы писали:
G>Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
Странно, мы с женой запускаем. Просто в поездки с собой проще ноут брать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Где вы сейчас дефицит памяти нашли, она стоит как грязь. 2 гига поставить вообще ничего не стоит. А на машинах, которые не могут себе позволить много памяти, как нетбуки например, приложения типа фотошопа не запускают.
E>Странно, мы с женой запускаем. Просто в поездки с собой проще ноут брать...
Читайте внимательнее. Я говорил про нетбуки.
Здравствуйте, gandjustas, Вы писали:
G>Читайте внимательнее. Я говорил про нетбуки.
Я думал ошибка.
Ну да у нас и на ноуте мало памяти
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
