Здравствуйте, IT, Вы писали:
_>>Скорее за счёт времени компиляции. В быстродействие unique_ptr не уступает голым указателям. )
IT>Это хорошо. А второй, который shared?
shared медленнее голых указателей при копировании, ибо счётчик ссылок по указателю плюс сам указатель на счётчик ссылок. Но необходимое число копирований обычное не велико. Реально копирование shared_ptr-а необходимо только один раз на каждый акт появления/исчезновения нового владельца объекта. В остальных случаях его нужно передавать по ссылке или через move-semantic.
Здравствуйте, Cyberax, Вы писали:
C>В D проблема с конкурентностью — о ней никто не думал, потому получилась yet another native Java с общим хипом. Отсюда и проблемы с GC, которые неустранимы по дизайну.
Да, куча общая, и это плохо. Но зато есть изолированные системой типов процессы (потоки), обменивающиеся сообщениями а-ля Эрланг, плюс файберы для уделывания всяких нодежсов в асинхронности. Плюс все глобальные переменные по умолчанию thread local. Плюс можно более аккуратно работать с памятью (в том числе переопределить new), чтобы устроить локальные мини-кучи в потоках и не нагружать без нужды общий GC. Короче, не эрланг и не раст, но все ж неплохо.
C>Если на это пофиг, то стоит посмотреть на Go.
Сколько раз смотрел, так и не смог понять, ради чего на него стоит смотреть. Там же все отвратительно. И все хорошее легко воспроизводится в том же D.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
G>>Средний ноут, в том числе ультрабук, имеет 2-4 гб памяти, которые толком занять нечем. Какой смысл для пользователя от экономии 100мб?
N>>>На планшетах тем более ресурс, никто не хочет жить на зарядке. G>>Память? А причем тут зарядка?
EP>Performance bottleneck большинства программ это взаимодействие с иерархией памяти.
Это ты про какие программы?
Среднее дсктопное приложение более 90% времени проводит в ожидании пользователя. Еще 9% в ожидании завершения IO.
EP>Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже.
Бросай читать книжки 80-х годов.
EP>Требуется в 10 раз больше памяти? — косвенный признак тормозов.
Спорный вопрос. Если в памяти кешируется результат чтения с диска, то я предпочту в 10 раз больше памяти.
EP>Чтобы делать быстрый код в "управляемых средах" — нужно работать против языка, отказываться от многих средств выражения идей, спускаясь на крайне низкий уровень (даже ниже чем C).
Покажи пример чтоли?
Я вот оптимизировал C# код, который получал данные от железки постоянно, проводил небольшие расчеты и складывал в базу.
Оптимизации по памяти довольно банальные — убрать лишние аллокации, которые возникают, например, из-за замыканий.
Оптимизация производительности — использование правильных структур данных, особенно с учетом многопоточности.
Но самая главная оптимизация, которая позволила приложению нагружать процессор на 10% при 100 пакетах в секунду — все общение в внешним миром было сделано асинхронным.
Где тут низкий уровень?
И это кстати пример программы, которая работает все время.
Кстати выше я уже писал что для десктопного приложения важен perceived performance, а не объем памяти или скорость вычислений.
Во времена C++Builder люди жаловались на Visual Studio, что она компилирует медленно, а кот C++Builder быстро. Так вот МС это услышал, взял программу и замерил время компиляции с секундомером. Оказалось что VS быстрее.
Но люди жаловались, потому что VS компиляцию проводила молчав фоне, без visual feedback, а у С++Builder бежали циферки количества скомпилированных строк.
Здравствуйте, roro, Вы писали:
R>Здравствуйте, Mystic, Вы писали:
M>>Здравствуйте, roro, Вы писали:
R>>>Здравствуйте, Grundik2, Вы писали:
G>>>>Хочу поиграться с чем-нибудь, чтобы компилилось сразу в native код. Аналог C++'са, но не слишком экзотическое, малоизвестное или вымирающее. На ум приходит только D и Rust. Что порекомендуете?
R>>>Аналогов С++ имхо нет.
M>>Чем Ada не вариант? Если брать стандарт 2012 года? Или ее диалект SPARK?
R>С++ золотой молоток под все виды задач, бешеная производительность и лихая езда по памяти.
R>Ада, насколько знаю, полная противоположность — медленная безопасная езда в космосе.
Ada компилируется в машинный код. Производительность вполне сопоставимая с С++. Если брать стандарт 2012, то за счет предусловий и постусловий может быть доказана exception free для выхода индекса за пределы диапазона, выхода за пределы типа, деления на нуль, численного переполнения. В целом строгость языка дает компилятору куда больше возможностей понять, что происходит к коде, где можно оптимизировать, а где нет.
Получить лихую езду по памяти в Ada вполне возможно, только это более многословно. Во-первых, при использовании указателя надо использовать атрибут Unchecked_Access. И еще надо при помощи pragma Convention попросить компилятор сделать указатель C-совместимым. Так же можно использовать System.Address + System.Address_To_Access_Conversions(Node). Получается куча "мамой клянусь" в тексте.
Здравствуйте, D. Mon, Вы писали:
DM>Да, куча общая, и это плохо. Но зато есть изолированные системой типов процессы (потоки), обменивающиеся сообщениями а-ля Эрланг, плюс файберы для уделывания всяких нодежсов в асинхронности. Плюс все глобальные переменные по умолчанию thread local. Плюс можно более аккуратно работать с памятью (в том числе переопределить new), чтобы устроить локальные мини-кучи в потоках и не нагружать без нужды общий GC. Короче, не эрланг и не раст, но все ж неплохо.
Для "не плохо" есть C++. Для хорошо, хочется надеятся, будет Rust
Здравствуйте, jazzer, Вы писали:
M>>>Сейчас добавились умные указатели (shared, unique, weak и intrusive) и rvalue-ссылки. N>>Мне нравится слово "сейчас"
J>Ну в Стандарте — действительно "сейчас". Соответственно, для бустофобов тоже только "сейчас".
Я не скажу, что я бустофил, но shared, unique, weak и intrusive использовал ещё до того как узнал о бусте (>10 лет). В велосипедной реализации.
EP>Performance bottleneck большинства программ это взаимодействие с иерархией памяти. EP>Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже. EP>Требуется в 10 раз больше памяти? — косвенный признак тормозов.
Это общие слова. Такие вещи имеют вес в основном в числодробилках. "лишние аллокации" в менеджед не проблема. Проблемой являются долгоживущие объекты, объекты большого размера и большое количество тех и других. Зато гораздо проще сделать качественное кеширвание IO операций, уменьшить количество таких, легче сделать многопоточный процессинг, асинхронное ожидание и тд и тд и тд.
EP>Чтобы делать быстрый код в "управляемых средах" — нужно работать против языка, отказываться от многих средств выражения идей, спускаясь на крайне низкий уровень (даже ниже чем C). EP>В C++ же производительность и выразительность это не враги — можно делать много слоёв удобных абстракций, которые при компиляции практически исчезнут в пучине inline'ов — Light-weight abstraction programming language.
Что характерно, быстрый код на С++ это точно так же работа против языка. Почему то самые критичные куски кода пишутся практически на С или подобным образом.
EP>
EP>Andrei Alexandrescu: "The going word at Facebook is that 'reasonably written C++ code just runs fast,' which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier."
Это все басни. В менеджет не оптимизируют потому что "память не русурс, не хватит мощности, добавим кластер, памяти и тд", а в С++ не оптимизируют потому что "всё и так быстро".
Здравствуйте, Nikе, Вы писали:
N>Здравствуйте, jazzer, Вы писали:
M>>>>Сейчас добавились умные указатели (shared, unique, weak и intrusive) и rvalue-ссылки. N>>>Мне нравится слово "сейчас"
J>>Ну в Стандарте — действительно "сейчас". Соответственно, для бустофобов тоже только "сейчас".
N>Я не скажу, что я бустофил, но shared, unique, weak и intrusive использовал ещё до того как узнал о бусте (>10 лет). В велосипедной реализации.
Как и все мы. Но Boost.SmartPtr была в бусте с самого его начала в 1999 году (когда еще и релизов не было), а то и в 1998, 15 лет назад
Здравствуйте, Ikemefula, Вы писали:
KP>>Не совсем. Что на JVM, что на .NET типичный подход выглядит как-то так: "главное задача, памяти бесконечно много, не хватает мощности — поставим на кластер". Умный это подход или глупый, в общем случае, – мне судить сложно. С точки зрения системного C++ разработчика – подход глупый, но, бизнес, вроде как устраивает.
I>Это не на JVM или .Net, а во вполне определенных областях. Как правило тормозные монстры до того как их сделали на джаве или нете, были еще более тормозными и глючными в своем плюсовом детстве.
Как правило после любого переписывания системы она становится лучше и быстрее. И это достоинство не столько инструмента, сколько лучшего понимания проблем и предметной области.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Grundik2, Вы писали:
KP>>>А почему ты считаешь что это хорошо?
G>>Не прийдется его учить.
Ops>А вместо русского какой учил?
Здравствуйте, kaa.python, Вы писали:
C>>Прикрутил libcurl. Заодно разобрался с ARC и разделяемыми ресурсами KP>Ясно, тогда не очень интересно. Я, почему-то, подумал ты не только параллельное, но и асинхронное приложение запилил
Оно асинхронное — libcurl умеет
Здравствуйте, alex_public, Вы писали:
C>>Максимальный контроль компилятора над используемыми данными и изоляция данных между потоками. _>Ну изоляция то на уровне компилятора это не так что бы особо круто (это можно и административными мерами решать). Гораздо интереснее как реализован обмен данными между потоками. Лично мне больше всего нравится эрланговская модель и я прямо её и использую в C++.
Ты будешь удивляться, но в Rust как раз подобная модель. Только более продуманная.
Здравствуйте, kaa.python, Вы писали:
C>>Оно асинхронное — libcurl умеет KP>Насколько я помню, она может работать в неблокируемом режиме, но никак не в асинхронном. Там же select внутри. Или я что-то путаю?
А в чём особая разница? Libcurl может делать select (или poll) на нескольких соединениях, события которых потом можно асинхронно обрабатывать.
Здравствуйте, Cyberax, Вы писали:
C>А в чём особая разница? Libcurl может делать select (или poll) на нескольких соединениях, события которых потом можно асинхронно обрабатывать.
В реализации и подходе. Асинхронный режим, прием сообщения: создал буфер и сказал тебя позвать когда в нем будут данные; пришли данные, тебя позвали и ты имеешь буффер заполненный данными. Неблокирующий режим, прием сообщения: попросил тебя позвать когда данные будут; тебя позвали, ты вычитал данные и используешь их. Разница в том, что вычитка данных происходит за счет времени твоего приложения, а не за счет ядра. С отправкой аналогично.
Плюс имеются ограничения в функции select на количество одновременно обрабатываемых дескрипторов.
Здравствуйте, gandjustas, Вы писали:
N>>>>На планшетах тем более ресурс, никто не хочет жить на зарядке. G>>>Память? А причем тут зарядка? EP>>Performance bottleneck большинства программ это взаимодействие с иерархией памяти. G>Это ты про какие программы? G>Среднее дсктопное приложение более 90% времени проводит в ожидании пользователя. Еще 9% в ожидании завершения IO.
Я имел ввиду performance "активной" работы процессора. Плохая работа с памятью -> процессор будет дольше находится в "активном" режиме.
EP>>Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже. G>Бросай читать книжки 80-х годов.
Поясни
EP>>Требуется в 10 раз больше памяти? — косвенный признак тормозов. G>Спорный вопрос. Если в памяти кешируется результат чтения с диска, то я предпочту в 10 раз больше памяти.
Речь шла об одинаковых алгоритмах и структурах в разных языках.
Сравнивать производительность сред/языков по разным алгоритмам и структурам как-то совсем неправильно.
EP>>Чтобы делать быстрый код в "управляемых средах" — нужно работать против языка, отказываться от многих средств выражения идей, спускаясь на крайне низкий уровень (даже ниже чем C). G>Покажи пример чтоли?
Например возьми java, и сравни скорость создания массива int, допустим 32M элементов, и создание массива (размером 16M) объектов в каждом из которых содержатся два int, т.е.:
class Point2D
{
public int x,y;
}
Это простейшая абстракция, на которую в java будет сильное penalty как по памяти, по скорости создания (на 1-3 порядка), так и по скорости доступа.
G>Я вот оптимизировал C# код, который получал данные от железки постоянно, проводил небольшие расчеты и складывал в базу. G>Оптимизации по памяти довольно банальные — убрать лишние аллокации, которые возникают, например, из-за замыканий. G>Оптимизация производительности — использование правильных структур данных, особенно с учетом многопоточности. G>Но самая главная оптимизация, которая позволила приложению нагружать процессор на 10% при 100 пакетах в секунду — все общение в внешним миром было сделано асинхронным. G>Где тут низкий уровень? G>И это кстати пример программы, которая работает все время.
То что ты достиг скорости приемлемой для твоей задачи, вовсе не означает что программа использует ресурсы эффективно (что естественно не является самоцелью), и что её производительность нельзя улучшить на пару порядков.
Да, использование алгоритмических оптимизаций, уменьшение сложности — это всё важно, и особо не зависит от языка.
Но я имею в виду то, что сравнивая одинаковые алгоритмы на разных языках — на C++ гораздо легче написать код который выжимает максимум из железа, в то время как в "управляемых средах" это будет работа против языка, отказ от абстракций (см пример выше) и т.п.
G>Кстати выше я уже писал что для десктопного приложения важен perceived performance, а не объем памяти или скорость вычислений.
Так я с этим и не спорил
Да, есть приложения, будь они хоть замедленны в 1000 раз — не перестали бы решать поставленную задачу. Реально эффективный код нужен далеко не везде.
