Здравствуйте, Олег К., Вы писали:
I>>>А стоит сказать это в форуме С++, минусов будет на три страницы.
MTD>>Откуда такая уверенность?
ОК>Нормальные софтвере инженеры в тот форум редко, если вообще когда, заглядывают. Это больше место для школоты до которой не доходит и вряд ли дойдет что большинство фич из плюсов не нужны для нормального кода.
А подробнее? Что именно, "нормальный софтверный инженер", исключил бы из нововведений с++11?
Здравствуйте, gandjustas, Вы писали:
G>Так вот и вопрос в том как во время ожидания делать полезную работу, не плодя потоки. У твоем коде поток большую часть времени будет ждать в методах Send и TimedRead. Как ты будешь делать полезную работу в этот момент?
Здравствуйте, Олег К., Вы писали:
IT>>>Это стандартные домыслы, с ними нет смысла спорить.
KP>>Это не стандартные домыслы. Это утверждение, которое очень часто приводится в дискуссиях как довод в пользу управляемых языков.
IT>>>ЗЫ. А ты сам с "Дураков, пишущих на плюсах не меньше, а может быть даже больше..." тоже получается согласен?
ОК>Имхо ты загнул тут. Чтобы писать на Джаве или Шарпе неэффективный код, это надо постораться. А вот в плюсах пожалуйста! Верни к примеру тяжелый контейнер из функции или создай неявно какой-нибудь временной объект. Такого уродского кода как на плюсах мне не приходилось поддерживать. Впрочем я не виню язык — сам язык мне нравится. Я виню конкретные руки которые, не исключенно, могут вот так разглогольствовать на форумах.
Ты отстал от жизни. Почитай о rvalue references и move-семантике, прежде чем брызгнать слюной и показывать свою некомпетентность.
Здравствуйте, MTD, Вы писали:
G>>Так вот и вопрос в том как во время ожидания делать полезную работу, не плодя потоки. У твоем коде поток большую часть времени будет ждать в методах Send и TimedRead. Как ты будешь делать полезную работу в этот момент?
MTD>Натурально детский сад. Сам как думаешь?
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, gandjustas, Вы писали:
G>>Так вот и вопрос в том как во время ожидания делать полезную работу, не плодя потоки. У твоем коде поток большую часть времени будет ждать в методах Send и TimedRead. Как ты будешь делать полезную работу в этот момент?
MTD>Натурально детский сад. Сам как думаешь?
Я думаю что без потоков не как, а это жопа для масштабируемости.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Еще раз: продолжения+детерминированная финализация. Вместе, а не по-отдельности. В общем случае нельзя придумать способ гарантированной очистки памяти. Продолжение может просто не вызваться и будет держать ссылку на замыкание.
FR>GC же тоже будет держать в таких случаях.
Ссылок не найдет — освободит.
G>>В некоторых условиях можно, но условия будут постоянно меняться от структуры кода. замучаешься следить. FR>Как показывает практика использования тех же замыканий в C++ следить не сложно.
Ага, только используются они крайне мало, именно по причине выше.
Здравствуйте, gandjustas, Вы писали:
G>Я думаю что без потоков не как, а это жопа для масштабируемости.
Во-первых, вариантов масса, например есть неблокируемый ввод-вывод, во-вторых потоки — жопа только для очень нагруженных приложений, уж чтение из COM-порта — эталон высокопроизводительных приложений на .Net (шучу, извини), в такие задачи точно не входит.
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, gandjustas, Вы писали:
G>>Я думаю что без потоков не как, а это жопа для масштабируемости.
MTD>Во-первых, вариантов масса, например есть неблокируемый ввод-вывод, во-вторых потоки — жопа только для очень нагруженных приложений, уж чтение из COM-порта — эталон высокопроизводительных приложений на .Net (шучу, извини), в такие задачи точно не входит.
Так ты (или не только ты) же сам утверждаешь что C++ быстрее всего, а сам предлагаешь априори неэффективный по масштабируемости способ.
Здравствуйте, gandjustas, Вы писали:
G>Так ты (или не только ты) же сам утверждаешь что C++ быстрее всего,
Может и ссылку покажешь, где я утверждаю?
G>а сам предлагаешь априори неэффективный по масштабируемости способ.
1. Ссылку покажешь, где я предлагаю?
2. Зачем оптимизировать когда в этом нет необходимости?
3. А еще, прикинь, я Питон использую, а сейчас за Java мне деньги платят. А почему? Да потому, что выбираю инструмент согласно задаче и религиозных предрассудков у меня нет.
Здравствуйте, Ikemefula, Вы писали:
EP>>Это передёргивание — та задача о которой ты говоришь будет решением другой задачи, та в свою очередь и т.п. В итоге выйдем на задачу "прибыльный бизнес". EP>>Группировка разнотипных данных вездесуща в императивных языках — зачем это отрицать что это задача? На определённом уровне это вполне себе задача I>Группировки они разные бывают. Внятно дай задачу в терминах пользователя. Ты пока что привел решение этой задачи непойми в каких терминах.
Например есть массив элементов, где каждый элемент это {float32,int16,int8}.
Этот массив нужно обходить как рандомно(например есть второй массив пар индексов задающих вектора, и нужно посчитать сумму векторов или ещё что-нибудь), так и последовательно (например найти min/max по каждой компоненте).
Самое естественное — реализовать обычный массив элементов Element[].
I>>>Для полноценных замыканий нужен GC, ибо не совсем ясно, где и когда ты будешь память освобождать. EP>>Зависит от. Где-то будет подсчёт ссылок, где-то копирование, где-то move, а где-то вообще полностью pre-allocated с выделением целого блока на задачу и очистка всего блока по завершению. I>То есть, стратегия использования памяти зависит от того кода,который пишешь. Об чем и речь, это и есть кастрированые замыкания.
Ну так я о чём и говорю — если нужна производительность, то в большинстве случаев необходима адекватная работа с памятью, должен использоваться правильный подход. C++ как раз и предоставляет возможность использовать много разных подходов.
Как ты из этого сделал вывод об "кастрированых замыканиях" — я не пойму
EP>>Ты написал: EP>>
EP>>Почему то самые критичные куски кода пишутся практически на С или подобным образом.
EP>>Я привел пример number-crunch проекта где это далеко не так, и при этом он составляет конкуренцию коммерческим решениям. I>И ты утверждаешь, что именно это и есть типичный с++ код ? Как бы не так. Прямо в этом форуме, в КСВ, в С++ полно людей которые считают использование не то что буста, а темплейтов преступлением.
А где я утверждал что это типичный C++ код? Ещё раз, ты написал подчёркнутое. Я же тебе показал конкретный пример показывающий обратное.
К чему эта демагогия про Boost, шаблоны, и типичный код?
I>Уже все сказано. На одном проекте 40 индусов майнтейнят либу для линейного программирования, а на другом один человек майнтейнит такую же либу да же пачку из других областей. Вопрос — какой код считать типичным для этого примера ?
Здравствуйте, Ikemefula, Вы писали:
EP>>Это ты все эти CD-ejector'ы разрабатывал? С отзывчивым UI и корректностью, ага I>Это все писалось на С и С++, потому что люди просто не могут нормально реализовать асинхронщину.
Я не вижу связи между тем что до запятой и что после
EP>>>>Суть в том, что tight memory layout существенно влияет на производительность, пример с массивом структур это лишь одна часть проблемы, а ведь есть ещё композиция объектов, объекты на стеке. I>>>Для каких приложений это критично ? EP>>Критично там где нужна производительность I>Назови такие приложения.
CAD/CAE/CAM, web-браузеры, компиляторы, JIT, СУБД, обработка массивов данных(например c лидаров и т.п.), числодробилки, игры, low-latency processing, сервера, embedded, обработка видео/изображений/3D, распознавание образов, etc, etc, etc
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Есть много приложений, которые максимум что делают так это считывают три байтика с диска, показывают формочку, и складывают две цифирьки — и да, нужны люди которые будут писать такие приложения, много людей G>Угу, и зачем им C++?
А где я говорил что им нужно обязательно использовать C++? Ты сектант-моноязычник?
Видимо придётся себя процитировать
Ты не поверишь, для некоторых задач я советую людям изучить/использовать C#, а сам частенько использую Python.
[sarcasm mode]только не рассказывай ребятам с форума C++, а то они меня побьют и заберут партбилет[/sarcasm mode]
G>>>А если требует то важна не сама скорость работы, а perceived performance. EP>>Если вычисление идёт 30 минут, вместо возможных десяти секунд, то ты хоть как украшай progress bar рюшечками — это не поможет. G>30 минут надо считать на сервере, клиент может столько и не прожить.
Что за плоское представление о мире? Кто говорил что в этом случае вообще есть сервера?
G>>>Например ты делаешь приложение, которое делает graph layout — довольно сложные алгоритмы. Как ты думаешь что больше приглянется пользователям: молчаливый расчет всего за 10 сек потом отображение результата, или рисование узлов графа по мере вычисления позиций в течение 15 секунд? G>>>100% пользователей предпочтут второе, хотя реально оно в 1,5 раз медленнее. EP>>Пользователи предпочтут рисование по мере вычисления за пол-секунды G>Увы, 10 сек это максимум что можно выжать, даже при экстремальной оптимизации.
Это разговор о конях в вакууме. Я так полагаю ты что-то там пытался оптимизировать, и где-то получилось 10 сек — и из этого ты делаешь вывод что это максимум?
G>>>При замедлении алгоритма perceived performance растет. G>>>В C++ увы такими оптимизациями сложно заниматься, потому что требуется совмещать продолжения EP>>Ты вроде как толком не ответил, что не так с продолжениями в C++ G>то что их просто нет, а если сделать, то бестолку. Ибо комбинировать продолжения с передачей данных будет сложно, придется париться с освобождением памяти. Да и тупо может продолжение не прийти.
Почему сложно? Почему парится с освобождением памяти? Куда продолжение может не прийти?
G>Еще раз: продолжения+детерминированная финализация. Вместе, а не по-отдельности. В общем случае нельзя придумать способ гарантированной очистки памяти. Продолжение может просто не вызваться и будет держать ссылку на замыкание.
Давай конкретный пример.
G>>>Самое важное тут: как ты будешь получать этот массив и как обрабатывать. Если у тебя обработка ограниченного количества элементов за раз, то может вообще нет смысла держать в памяти все 32М, а читать с диска, на лету обрабатывать и выводить. EP>>Нет, каждый элемент нужно обрабатывать много раз. Причём такие элементы будут хранится не только в массиве — это общий пример на простой абстракции в виде группировки элементов G>Ниче не понял, приведи пример.
Есть группа логически связанных данных Element. Приложению нужны массивы/деки/мэпы Element'ов.
G>>>А зачем? Цель не оптимизация сама по себе, цель — чтобы программа работала достаточно быстро. EP>>А я и не говорил что оптимизация это самоцель — действительно, если тебе нужно обрабатывать 90 байтиков в секунду, то можешь хоть visual basic взять G>Среднее десктопное приложение обрабатывает и того меньше. G>Ты сам доказываешь что C++ не нужен и это совсем не мейнстрим.
Где я это доказывал?
Там где нужна производительность — у C++ пока практически нет конкурентов, там где не нужна — можно использовать либо C++, либо что-то другое — зависит от конкретной задачи
Здравствуйте, Grundik2, Вы писали:
G>Хочу поиграться с чем-нибудь, чтобы компилилось сразу в native код. Аналог C++'са, но не слишком экзотическое, малоизвестное или вымирающее. На ум приходит только D и Rust. Что порекомендуете?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например есть массив элементов, где каждый элемент это {float32,int16,int8}.
ля-ля-ля, это не задача, это _решение_ задачи. Поскольку ты сам задачу поставить не можешь, сделаю это за тебя. Смотри, как все просто — реализовать оконное FFT. Чуть более чем весь код для этого в сишном стиле. А вот то что ты показываешь это отстой.
I>>То есть, стратегия использования памяти зависит от того кода,который пишешь. Об чем и речь, это и есть кастрированые замыкания.
EP>Ну так я о чём и говорю — если нужна производительность, то в большинстве случаев необходима адекватная работа с памятью, должен использоваться правильный подход. C++ как раз и предоставляет возможность использовать много разных подходов. EP>Как ты из этого сделал вывод об "кастрированых замыканиях" — я не пойму
Очень просто — возможность ручного тюнинга "скомпенсирована" обязательностью такого тюнига, то есть, лямбды просто нельзя применять так, как они применяются в других языках. Это ж очевидно — GC отсутствует, стало быть передавать лямбды наверх нельзя, нужно обязательно обкладывать костылями, например счетчиком ссылок, а стало быть надо писать специальный код для управления этим счетчиком. Если хочешь, можешь порассуждать на тему "В С++ все разрабы настолько круты, что циклические ссылки это плевое дело".
EP>А где я утверждал что это типичный C++ код? Ещё раз, ты написал подчёркнутое. Я же тебе показал конкретный пример показывающий обратное. EP>К чему эта демагогия про Boost, шаблоны, и типичный код?
Если твой пример не является типичным, то его незачем и рассматривать. Типичный код это такой, с которым имеет дело большинство. Не усредненный, по количеству строчек, а некоторая мода(статистика, а не одежда).
I>>Уже все сказано. На одном проекте 40 индусов майнтейнят либу для линейного программирования, а на другом один человек майнтейнит такую же либу да же пачку из других областей. Вопрос — какой код считать типичным для этого примера
EP>Вопроса не понял. Какого примера?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Это ты все эти CD-ejector'ы разрабатывал? С отзывчивым UI и корректностью, ага I>>Это все писалось на С и С++, потому что люди просто не могут нормально реализовать асинхронщину.
EP>Я не вижу связи между тем что до запятой и что после
Асинхронщина в менеджед работает на раз, тому миллионы примеров. А вот на С++ куда ни ткни, то какое то бедствие — результатов нет.
EP>>>Критично там где нужна производительность I>>Назови такие приложения.
EP>CAD/CAE/CAM, web-браузеры, компиляторы, JIT, СУБД, обработка массивов данных(например c лидаров и т.п.), числодробилки, игры, low-latency processing, сервера, embedded, обработка видео/изображений/3D, распознавание образов, etc, etc, etc
CAD/CAE/CAM это ты промахнулся, я таким больше 10 лет занимался, могу сам тебе рассказать чего к чему. С++ там в основном в силу исторических причин.
Игры — они разные, нынче все больше игр уходит в менеджед или подобные вещи. Скажем в ворлдофтанс вагоны питоновского кода в самом ядре.
low-latency для начала требует корректную обработку, смотри в Эрланг — самый что ни есть менеджед.
embedded — здесь уже давно джава, дотнет и даже джаваскрипт
Серверы — питон почему то используется в т.ч. Надо полагать просто так ?
Компиляторы — это мимо кассы, компилятор С# доказывает
Итого, остаётся — веб-браузеры, там кстати очень много на джаваскрипте сделано, все что надо для перформанса это рендеринг, парсинг и сама скриптовая машина, обработка видео, звука, изображений, 3Д, распознавание образов.
Здравствуйте, Ikemefula, Вы писали:
EP>>Например есть массив элементов, где каждый элемент это {float32,int16,int8}. I>ля-ля-ля, это не задача, это _решение_ задачи. Поскольку ты сам задачу поставить не можешь, сделаю это за тебя. Смотри, как все просто — реализовать оконное FFT. Чуть более чем весь код для этого в сишном стиле. А вот то что ты показываешь это отстой.
Если сложение векторов это _решение_ задачи, то FFT — это точно такое же _решение_ задачи, а не задача
EP>>Как ты из этого сделал вывод об "кастрированых замыканиях" — я не пойму I>Очень просто — возможность ручного тюнинга "скомпенсирована" обязательностью такого тюнига, то есть, лямбды просто нельзя применять так, как они применяются в других языках. Это ж очевидно — GC отсутствует, стало быть передавать лямбды наверх нельзя,
Кто тебе такую чушь сказал?
I>нужно обязательно обкладывать костылями, например счетчиком ссылок, а стало быть надо писать специальный код для управления этим счетчиком.
Так код-то уже есть в библиотеках. Помимо счётчика ссылок есть другие варианты — copy, move, move-on-copy, generalized capture.
Почему ты называешь наличие выбора, а не его отсутствие — "кастрацией"?
EP>>А где я утверждал что это типичный C++ код? Ещё раз, ты написал подчёркнутое. Я же тебе показал конкретный пример показывающий обратное. EP>>К чему эта демагогия про Boost, шаблоны, и типичный код? I>Если твой пример не является типичным, то его незачем и рассматривать. Типичный код это такой, с которым имеет дело большинство. Не усредненный, по количеству строчек, а некоторая мода(статистика, а не одежда).
Так, давай заново:
I>Что характерно, быстрый код на С++ это точно так же работа против языка. Почему то самые критичные куски кода пишутся практически на С или подобным образом.
Я правильно понимаю, что ты имел ввиду что человек знающий и C и C++ предпочтёт писать быстрый код практически на C, ограничивая себя в выразительных средствах C++?
I>>>Уже все сказано. На одном проекте 40 индусов майнтейнят либу для линейного программирования, а на другом один человек майнтейнит такую же либу да же пачку из других областей. Вопрос — какой код считать типичным для этого примера EP>>Вопроса не понял. Какого примера? I>Выделил.
Есть две одинаковых либы ("такую же либу") — одну поддерживает 1 человек, а другую 40, так?
Что ты подразумеваешь под "типичным кодом"? Две либы делают одно и тоже — почему? Эти команды никак не общаются?
MTD>>>Откуда такая уверенность?
ОК>>Нормальные софтвере инженеры в тот форум редко, если вообще когда, заглядывают. Это больше место для школоты до которой не доходит и вряд ли дойдет что большинство фич из плюсов не нужны для нормального кода.
M>А подробнее? Что именно, "нормальный софтверный инженер", исключил бы из нововведений с++11?
В С++ 98-го более чем достаточно фич чтобы писать нормальный код. Лично я еще С++11 даже и не открывал но скоро открою и лишь только по одной причине; на интервью может попасться какой-нибудь очередной идиот который знает все новомодные фишки и считает что раз он пихает их все куда ни попадя, так и все остальные должны их также пихать. Вообще перечитай еще раз мой ответ выше, может дойдет.
Ты сектант-моноязычник?
