Здравствуйте, Ikemefula, Вы писали:

IT>>>Это хорошо. А второй, который shared?
N>>Тот который шаред — ИМХО антипаттерн.
I>А стоит сказать это в форуме С++, минусов будет на три страницы.

shared_ptr хоть и полезен, но сильно overused.
Многие его используют абсолютно ни к месту — где достаточно unique_ptr, а где-то вообще никакой smart pointer не нужен.

Здравствуйте, Nuzhny, Вы писали:

KP>>>Не совсем. Что на JVM, что на .NET типичный подход выглядит как-то так: "главное задача, памяти бесконечно много, не хватает мощности — поставим на кластер". Умный это подход или глупый, в общем случае, – мне судить сложно. С точки зрения системного C++ разработчика – подход глупый, но, бизнес, вроде как устраивает.

I>>Это не на JVM или .Net, а во вполне определенных областях. Как правило тормозные монстры до того как их сделали на джаве или нете, были еще более тормозными и глючными в своем плюсовом детстве.

N>Как правило после любого переписывания системы она становится лучше и быстрее. И это достоинство не столько инструмента, сколько лучшего понимания проблем и предметной области.

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

Здравствуйте, kaa.python, Вы писали:

C>>А в чём особая разница? Libcurl может делать select (или poll) на нескольких соединениях, события которых потом можно асинхронно обрабатывать.
KP>В реализации и подходе. Асинхронный режим, прием сообщения: создал буфер и сказал тебя позвать когда в нем будут данные; пришли данные, тебя позвали и ты имеешь буффер заполненный данными. Неблокирующий режим, прием сообщения: попросил тебя позвать когда данные будут; тебя позвали, ты вычитал данные и используешь их. Разница в том, что вычитка данных происходит за счет времени твоего приложения, а не за счет ядра. С отправкой аналогично.
Я тебе скажу, что в Линуксе разницы между этими двумя подходами совсем нет. Это если не заниматься экзотикой типа AIO, который один фиг не работает.

KP>Плюс имеются ограничения в функции select на количество одновременно обрабатываемых дескрипторов.
Там используется poll(), который реально ограничений не имеет.

Здравствуйте, Ikemefula, Вы писали:

I>Лично я уходил на дотнет из за наличия инструментов, с помощью которых можно навести порядок в коде. Для С++ их и по сей день нет. Потому древний код, который никто не знает, как должен работать, привести в порядок крайне тяжело.
I>В дотнете, джаве — очень просто, т.к. средства автоматического рефакторинга, тесты всяких сортов, анализаторы кода и тд и тд берут на себя примерно 90% той работы, которую на С++ надо делать руками.
I>Теоретически, на С++ что-то даже есть, но это сильно условно, т.к.
I>благодаря тем техникам, что уже по факту укоренились в С++, ни один тул не может ничего гарантировать, даже простое переименование метода местами даёт проблемы.

Что это за порочные техники такие?

Особенно интересно узнать что сотворит переименование метода? там, что, часть метода в #define написана?

Здравствуйте, Ikemefula, Вы писали:

EP>>Performance bottleneck большинства программ это взаимодействие с иерархией памяти.
EP>>Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже.
EP>>Требуется в 10 раз больше памяти? — косвенный признак тормозов.

I>Это общие слова. Такие вещи имеют вес в основном в числодробилках.

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

I>"лишние аллокации" в менеджед не проблема.

Ну да — именно поэтому разработчики оптимизаторов пыхтят например над escape analysis
Как пример — эти аллокации вылезают по всему коду, при простейших абстракциях — просадка 16x на ровном месте.
Также аллокации ухудшают локальность, что является дополнительной проблемой.
Чтобы бороться с ними, нужно от многого отказываться и работать против языка — этим редко кто занимается, ибо проще взять более подходящий инструмент.

I>Что характерно, быстрый код на С++ это точно так же работа против языка.

Alexander Stepanov:
What do I mean when I say that an algorithm does not "impose any performance penalty"? In other words, how do you know that a generic algorithm is efficient? An algorithm is called relatively efficient if it's as efficient as a nongeneric version written in the same language, and it's called absolutely efficient if it's as efficient as a nongeneric assembly language version.

For many years, I tried to achieve relative efficiency in more advanced languages (e.g., Ada and Scheme) but failed. My generic versions of even simple algorithms were not able to compete with built-in primitives. But in C++ I was finally able to not only accomplish relative efficiency but come very close to the more ambitious goal of absolute efficiency. To verify this, I spent countless hours looking at the assembly code generated by different compilers on different architectures.

I>Почему то самые критичные куски кода пишутся практически на С или подобным образом.

Это распространённый миф

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."

I>Это все басни.

Это реальный опыт крупного проекта

Здравствуйте, Cyberax, Вы писали:

KP>>Да, а вот теперь реально интересующий меня вопрос. Ты что используешь в качестве сетевого уровня? Текущая версия из Rust, мягко говоря, не завершена.
C>Прикрутил libcurl. Заодно разобрался с ARC и разделяемыми ресурсами

А что такое ARC? И в чём состояло прикручивание libcurl?

Здравствуйте, Mazay, Вы писали:

KP>>>Да, а вот теперь реально интересующий меня вопрос. Ты что используешь в качестве сетевого уровня? Текущая версия из Rust, мягко говоря, не завершена.
C>>Прикрутил libcurl. Заодно разобрался с ARC и разделяемыми ресурсами
M>А что такое ARC?
http://dl.rust-lang.org/doc/std/arc.html

M>И в чём состояло прикручивание libcurl?
Аккуратно сделать кэш соединений и диспетчер.

Здравствуйте, Cyberax, Вы писали:

C>Я тебе скажу, что в Линуксе разницы между этими двумя подходами совсем нет. Это если не заниматься экзотикой типа AIO, который один фиг не работает.

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

Здравствуйте, kaa.python, Вы писали:

C>>Я тебе скажу, что в Линуксе разницы между этими двумя подходами совсем нет. Это если не заниматься экзотикой типа AIO, который один фиг не работает.
KP>Как же у вас там все печально
KP>Эту проблему, в году так 2008 грозились вот-вот решить.
Пробовали, для сетей это не имеет большого смысла. Сейчас основной пользователь AIO — это базы данных, которые хотят делать кучу операций с дисковыми массивами.

Здравствуйте, Cyberax, Вы писали:

C>Пробовали, для сетей это не имеет большого смысла. Сейчас основной пользователь AIO — это базы данных, которые хотят делать кучу операций с дисковыми массивами.

Вообще-то, смысл есть, в случае написания сервера, как минимум. С учетом того, что ты писал клиента, особого смысла в использовании асинхронного IO нет, тут я согласен.

Здравствуйте, Ikemefula, Вы писали:

I>А стоит сказать это в форуме С++, минусов будет на три страницы.

Откуда такая уверенность?

Здравствуйте, gandjustas, Вы писали:

G>Почти все десктопные приложения довольно древние, разработаны в году 2005 и ранее.
G>А вот приложения для w8 по большей части .NET (WinRT) и JavaScript.

Ну раз так, то уверен, будет не сложно назвать хотя бы десяток популярных десктопных приложений на .Net? Прошу.

Здравствуйте, gandjustas, Вы писали:

G>Я вот оптимизировал C# код, который получал данные от железки постоянно, проводил небольшие расчеты и складывал в базу.
G>Оптимизации по памяти довольно банальные — убрать лишние аллокации, которые возникают, например, из-за замыканий.
G>Оптимизация производительности — использование правильных структур данных, особенно с учетом многопоточности.
G>Но самая главная оптимизация, которая позволила приложению нагружать процессор на 10% при 100 пакетах в секунду — все общение в внешним миром было сделано асинхронным.

Для дотнетчиков оказывается обработать 100 пакетов в секунду достижение Снимаю шляпу

Здравствуйте, IT, Вы писали:

KP>>Ну разве что только те, кто так и не открыл для себя shared_ptr и unique_ptr

IT>И сколько ещё всяких разных подпорок и затычек нужно для себя открыть?

Почему ты называешь часть языка подпорками? А цикл for — подпорка, а if?

Здравствуйте, gandjustas, Вы писали:

G>А вот для энергопотребления и perceived performance нужно правильно делать ожидания, а не быстрые вычисления, что на C++ непросто.

Это ты о чем вообще? Сказать ОС, что не будить процесс до наступления некоего события одной функцией это сложность?

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, roro, Вы писали:

R>>Здравствуйте, Mystic, Вы писали:

M>>>Здравствуйте, roro, Вы писали:

R>>>>Здравствуйте, Grundik2, Вы писали:

G>>>>>Хочу поиграться с чем-нибудь, чтобы компилилось сразу в native код. Аналог C++'са, но не слишком экзотическое, малоизвестное или вымирающее. На ум приходит только D и Rust. Что порекомендуете?

R>>>>Аналогов С++ имхо нет.

M>>>Чем Ada не вариант? Если брать стандарт 2012 года? Или ее диалект SPARK?

R>>С++ золотой молоток под все виды задач, бешеная производительность и лихая езда по памяти.

R>>Ада, насколько знаю, полная противоположность — медленная безопасная езда в космосе.

M>Ada компилируется в машинный код. Производительность вполне сопоставимая с С++. Если брать стандарт 2012, то за счет предусловий и постусловий может быть доказана exception free для выхода индекса за пределы диапазона, выхода за пределы типа, деления на нуль, численного переполнения. В целом строгость языка дает компилятору куда больше возможностей понять, что происходит к коде, где можно оптимизировать, а где нет.

M>Получить лихую езду по памяти в Ada вполне возможно, только это более многословно. Во-первых, при использовании указателя надо использовать атрибут Unchecked_Access. И еще надо при помощи pragma Convention попросить компилятор сделать указатель C-совместимым. Так же можно использовать System.Address + System.Address_To_Access_Conversions(Node). Получается куча "мамой клянусь" в тексте.

Вы меня заинтриговали.
Поставил себе GPS2013, примеры в нем какие-то странные. demo/matrix_handling строки матрицы выделяет на куче, причем каждую строку по отдельности через calloc, и все это происходит в файле matrix.c

Где бы посмотреть эталонные реализации matrix-vector, KD-tree, ray-intersection, желательно чистые без c/c++ ?

Здравствуйте, MTD, Вы писали:


MTD>Откуда такая уверенность?

Да как бы уже проходили

Здравствуйте, Evgeny.Panasyuk, Вы писали:

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

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

EP>Как пример — эти аллокации вылезают по всему коду, при простейших абстракциях — просадка 16x на ровном месте.

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

EP>Также аллокации ухудшают локальность, что является дополнительной проблемой.
EP>Чтобы бороться с ними, нужно от многого отказываться и работать против языка — этим редко кто занимается, ибо проще взять более подходящий инструмент.

С такими проблемами как ты показал, не надо бороться против языка, наоборот, его надо интенсивно использовать.

EP>

EP>Alexander Stepanov:
EP>For many years, I tried to achieve relative efficiency in more advanced languages (e.g., Ada and Scheme) but failed. My generic versions of even simple algorithms were not able to compete with built-in primitives. But in C++ I was finally able to not only accomplish relative efficiency but come very close to the more ambitious goal of absolute efficiency. To verify this, I spent countless hours looking at the assembly code generated by different compilers on different architectures.

EP>

Это ни о чем. Если производительность понимать исключительно как такты процессора, то еще можно чего то выдумывать. А если скажем сюда внести работу с диском, базой или сетью, все поворачивается ровно наоборот — С++ не в состоянии обеспечить перформанс, например потому что тяжело контролировать асинхронные операции. Всё, до свидания.

I>>Почему то самые критичные куски кода пишутся практически на С или подобным образом.

EP>Это распространённый миф

Это факты.

I>>Это все басни.

EP>Это реальный опыт крупного проекта

Это частный случай. Почему то плюсовики имеют обыкновение яростно отрицать опыт других проектов

Здравствуйте, Mna, Вы писали:

Mna>Что это за порочные техники такие?

Mna>Особенно интересно узнать что сотворит переименование метода? там, что, часть метода в #define написана?

Разумеется. Есть целая куча библиотек, которые используют такой подход.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>shared_ptr хоть и полезен, но сильно overused.
EP>Многие его используют абсолютно ни к месту — где достаточно unique_ptr, а где-то вообще никакой smart pointer не нужен.

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

Помнится это именно ты год назад доказывал мне, что все ровно наоборот — сиплюсники чуть не поголовно используют указатели самым правильным образом.