Здравствуйте, Mna, Вы писали:
_>>А можно озвучить мощный и свободный язык программирования, который позволит мне осуществлять сложную фильтрацию в реальном времени FHD/4K видео? )
Mna>Если ты про производительность, Mna>то когда нужна производительность выбираешь низкоуровневый язык поближе к железу и не рыпаешься просто нет других вариантов, -- тут понятно, я ничего не смогу предложить : С++/С -- и может даже писать ассемблерные вставки вручную, если С компилятор новые инструкции пока не поддерживает.
Инструкции он все знает. Но не все максимально эффективно использует — есть исключение в виде SIMD. Т.е. если классический код даже хороший спец. по ассемблеру сейчас вряд ли напишет эффективнее компилятора C/C++, то SIMD код написанный руками пока что заметно эффективнее созданного компилятором (так называемая автовекторизация циклов). Надеюсь когда-нибудь и simd будет автоматом на максимуме оптимальности, ну а пока для этого есть ручные спец. инструменты (в том числе и в самом C++).
Mna>Но если С компилятор не поддерживает, то тот же асм можно сгенерировать и функциональными языками программирования, почему нет. может даже и попроще будет.
Так а есть такие готовые платформы? ) Потому как об использование подобного я бы может ещё и задумался, а вот писать самому с нуля — нет спасибо. )))
Mna>А ежели ты про то, что статические ограничения особенно увеличивают производительность, я считаю что пример Haskell-а, самого органичивающего показывает, что ограничения не спасают, и все равно получается медленно.
В Хаскеле у нас сборщик мусора, параметрический полиморофизм и попытка (в реальности конечно полностью не выходит, но даже это замедляет) работы исключительно с иммутабельными данными. Это весьма сомнительный пример.
Да, и ограничения действительно помогают в производительности. В том смысле, что сообщают компилятору необходимую ему для оптимизации информацию.
Mna>Или например С++, его "метапрограммы" жутко медленно компилируются.
Согласен, медленно. Только при этом они потом работают быстрее всех. )
Mna>Нет я бы тоже хотел, чтоб все хорошее в языке было (не важно название) и не было ничего плохого , но приходится выбирать.
Здравствуйте, Mna, Вы писали:
Mna>Или например С++, его "метапрограммы" жутко медленно компилируются.
Причина этому ровно одна — компиляторы не заточены архитектурно под быструю компиляцию метапрограмм.
Они заточены под быструю компиляцию "обычного" кода, где типов мало (и, как следствие, разных воплощений шаблонов тоже мало).
В GCC, например, использовались простые односвязные списки воплощений шаблонов. Соответственно, если ты шаблон воплотил с разными типами тысячу раз — будут тормоза на ровном месте. В какой-то из версий GCC это пофиксили, ускорение, как и следовало ожидать, оказалось алгоритмическим.
Так что постепенно подтянутся.
Ну и язык на месте не стоит.
Те же variadic templates существенно сократили необходимый код и сложность шаблонов с неопределенным количеством аргументов. То есть когда раньше тебе приходилось генерить все возможные варианты шаблона для каждого количества аргументов препроцессором или через рекурсивные шаблоны (что приводило к взрыву в смысле количества вариантов шаблонов и их воплощений), то теперь ты пишешь ровно один шаблон, и компилятор знает, как его обрабатывать, дял любого количечства аргументов.
Или разрешение использовать для воплощения шаблонов локально объявленные типы (ну и полиморфные лямбды туда же). Это позволяет компилятору выкинуть все локальные типы и шаблоны по окончании компилирования данной области видимости (скажем, внутри if) — а раньше приходилось все объявлять в глобальной области видимости и оно все в результате анализировалось всеми остальными частями программы, что, понятно, могло только замедлять компиляцию.
Ну и еще одна причина — модель текстового включения через #include, когда одно и то же компилится по многу раз для разных единиц трансляции. Но это решается прекомпилированными заголовками.
Здравствуйте, Ikemefula, Вы писали:
X>>>абсолютно каждая компания в_которой/с_которой мне приходилось работать — использовали boost. так что я хз, о чем ты... D>>У меня ровно обратное — ни в одной компании boost не использовали. I>Более того — есть конторы где явный запрет использовать в продакшне либы навроде буста.
Ну, такого не видел, но в реальной жизни у меня не было задач, требующих boost больше чем, например, смартпоинтеры. Да, смартпоинтеры мы из буста взяли, они там хорошие, годные. Остальное, наверно, тоже хорошее, но как-то что-то не надо.
Mna>Я всегда говорю: хотите узнать насколько готова среда для реальной настоящей работы, а не исследовательской Mna>или поиграться — посмотрите для этого какие есть средства для отладки в этой среде. Mna>Потому что в реальной жизни всегда есть реальные проблемы, т.е. трудные. Если есть отладчик, Mna>значит тут кто-то был до нас и сделал как надо для работы для решения проблем. а не выпендрежа. Mna>Особенно хорошо если это кто-то был из разработчиков ядра системы, и встроил концепции глубоко и правильно, Mna> а не для собственного прикола, как в данном случае со Страуструпом случилось.
Это интересный вопрос. Я раньше думал, что Страуструп добавил шаблоны только для статического полиморфизма, но теперь понимаю, что этот человек не мог не предвидеть, как шаблоны станут использоваться для метапрограммирования. Хотя в его книге нет упоминания про вычисления в compile time (или я ошибаюсь?), он дал молчаливое согласие на развитие концепций метапрограммирования в С++ и библиотеки boost.
Кстати, хорошая книга по метапрограммированию в С++ (ну или кому хочется убить свое время ): C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond (Abrahams, Gurtovoy)
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Mna, Вы писали:
_>>>А можно озвучить мощный и свободный язык программирования, который позволит мне осуществлять сложную фильтрацию в реальном времени FHD/4K видео? )
Mna>>Если ты про производительность, -- С++/С -- и может даже писать ассемблерные вставки вручную, если С компилятор новые инструкции пока не поддерживает.
_>Инструкции он все знает. Надеюсь когда-нибудь и simd будет автоматом на максимуме оптимальности, ну а пока для этого есть ручные спец. инструменты (в том числе и в самом C++).
интересно было бы узнать что это за штуки
Mna>>Но если С компилятор не поддерживает, то тот же асм можно сгенерировать и функциональными языками программирования, почему нет. может даже и попроще будет.
_>Так а есть такие готовые платформы? ) Потому как об использование подобного я бы может ещё и задумался, а вот писать самому с нуля — нет спасибо. )))
А я, если бы узкая и четко определенная задача, рискнул бы и с нуля написать
Честно говоря, мне такие штуки не пригождались, не искал, единственно что напомнило -- это проект AsmJit, но он написан на С++е
AsmJit is a complete JIT and remote assembler for C++ language. It can generate native code for x86 and x64 architectures and supports the whole x86/x64 instruction set — from legacy MMX to the newest AVX2. It has a type-safe API that allows C++ compiler to do a semantic checks at compile-time even before the assembled code is generated or run.
не знаю насколько подойдет
--
А из примеров на функциональных языках вспоминается проект встроенного решения С-код для которого генерировался из OCaml.
Mna>>А ежели ты про то, что статические ограничения особенно увеличивают производительность, я считаю что пример Haskell-а, самого органичивающего показывает, что ограничения не спасают, и все равно получается медленно.
_>В Хаскеле у нас сборщик мусора, параметрический полиморофизм и попытка (в реальности конечно полностью не выходит, но даже это замедляет) работы исключительно с иммутабельными данными. Это весьма сомнительный пример.
Я Хаскел приводил как пример языка с самыми сильными constraint-ами.
не знаю что есть сильнее или такое же сильно ограничивающее, но чтоб с zero-overhead-ом, я бы на это посмотрел.
Rust?
Zero overhead бывает двух видов, обычно имеется ввиду первый:
1 язык/рантайм не потребляет больше того что реально нужно, получается шустрая программа, ценой трудов программиста по спецификации типов
2 от программиста не запрашивают специфицировать все типы очень детально, и программа получается не такая шустрая, но зато пишется быстрее.
так и напрашивается автоматический выводитель типов. чтоб тип сразу в текст в исходник вписывал.
_>Да, и ограничения действительно помогают в производительности. В том смысле, что сообщают компилятору необходимую ему для оптимизации информацию.
да-да. Python и Cython: Cython быстрый как почти С++.
Mna>>Или например С++, его "метапрограммы" жутко медленно компилируются.
_>Согласен, медленно. Только при этом они потом работают быстрее всех. )
вот от этой медленности люди и сбегают к динамическим интерпретируемым языкам!
Потому что дольше всех работает оптимизатор машинного кода, а машины сейчас быстрые, для множества задач такой скорости и не требуется
Mna>>Нет я бы тоже хотел, чтоб все хорошее в языке было (не важно название) и не было ничего плохого , но приходится выбирать. _>
Здравствуйте, jazzer, Вы писали:
Mna>>Или например С++, его "метапрограммы" жутко медленно компилируются.
J>Причина этому ровно одна — компиляторы не заточены архитектурно под быструю компиляцию метапрограмм.
J>Они заточены под быструю компиляцию "обычного" кода, где типов мало (и, как следствие, разных воплощений шаблонов тоже мало). J>В GCC, например, использовались простые односвязные списки воплощений шаблонов из версий GCC это пофиксили, ускорение, как и следовало ожидать, оказалось алгоритмическим. J>Так что постепенно подтянутся.
Да, интересно.
А мне всегда казалось что проблемы две, сложная вязь из двух: проблемы с мета-компиляцией, что метакомпиляторы постепенно вырастали из обычных С/С++ компиляторов и метакомпиляция не была изначально органично спроектирована,
ну вот что собственно было выше описано,
И смешаны вперемешку с проблемами оптимизатора, оптимизатор хочет сделать самый оптимальный код, а часто и добивается
его, но тратит на свое динамическое программирование, на переборы и оценки деревьев стоимости кучу времени.
Вот такое интуитивное представление
J>Ну и еще одна причина — модель текстового включения через #include, когда одно и то же компилится по многу раз для разных единиц трансляции. Но это решается прекомпилированными заголовками.
Вот этого никак понять не могу. что мешает отказаться в очередной версии стандарта C++ от модели текстового включения?
Пусть поддерживают оба, новый и исторический способ, а рекомендуют пакетное включение, import как в джаве например.
и все довольны?
а внутри по сути такой же прекомпилированный header, только уже переносимый на уровне языка. и реализации уже есть.
Здравствуйте, Mna, Вы писали:
Mna>Вот этого никак понять не могу. что мешает отказаться в очередной версии стандарта C++ от модели текстового включения? Mna>Пусть поддерживают оба, новый и исторический способ, а рекомендуют пакетное включение, import как в джаве например.
Примерно так и хотят сделать. Правда хз когда окончательно решатся.
Здравствуйте, Mna, Вы писали:
Mna>А из примеров на функциональных языках вспоминается проект встроенного решения С-код для которого генерировался из OCaml.
А еще есть проект на Haskell, где хаскеловская программа транслируется в шаблонный метакод С++
Mna>Zero overhead бывает двух видов, обычно имеется ввиду первый: Mna>1 язык/рантайм не потребляет больше того что реально нужно, получается шустрая программа, ценой трудов программиста по спецификации типов Mna>2 от программиста не запрашивают специфицировать все типы очень детально, и программа получается не такая шустрая, но зато пишется быстрее.
Ну так auto же
Mna>вот от этой медленности люди и сбегают к динамическим интерпретируемым языкам!
Для прототипирования динамические языки — самое оно.
Mna>Потому что дольше всех работает оптимизатор машинного кода, а машины сейчас быстрые, для множества задач такой скорости и не требуется
Ну, для таких задач и С++ не нужен тогда.
С другой стороны, вот, скажем, браузеры — ведь сколько скорости ни дай, всё мало же.
Mna>>>Нет я бы тоже хотел, чтоб все хорошее в языке было (не важно название) и не было ничего плохого , но приходится выбирать.
"все хорошее" бывает либо за счет сильной совместимости с другими языками с вытекающими из этого ограничениями (живой пример — С++ по отношению к Си), либо за счет кучи бабла (нанять армию программеров, которые бы на твоем языке воспроизвели все нужные библиотеки, чтоб не было необходимости с тоской смотреть на недоступные сишные)
Здравствуйте, Mna, Вы писали:
_>>Инструкции он все знает. Надеюсь когда-нибудь и simd будет автоматом на максимуме оптимальности, ну а пока для этого есть ручные спец. инструменты (в том числе и в самом C++). Mna>интересно было бы узнать что это за штуки
В C++ это естественно соответствующие intrinsic-функций (https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/X86-Built-in-Functions.html). Это конечно же совсем низкоуровневый инструмент, который по хорошему надо заворачивать в удобные абстракции (в том числе и с помощью тех же шаблонов).
Mna>Честно говоря, мне такие штуки не пригождались, не искал, единственно что напомнило -- это проект AsmJit, но он написан на С++е Mna>
Mna>AsmJit is a complete JIT and remote assembler for C++ language. It can generate native code for x86 and x64 architectures and supports the whole x86/x64 instruction set — from legacy MMX to the newest AVX2. It has a type-safe API that allows C++ compiler to do a semantic checks at compile-time even before the assembled code is generated or run.
Mna>не знаю насколько подойдет
Нууу тут немного другой интерес. Это скорее аналог функции eval из скриптовых языков. Т.е. главное не в быстродействие, а в возможности динамической генерации кода.
Mna>Я Хаскел приводил как пример языка с самыми сильными constraint-ами. Mna>не знаю что есть сильнее или такое же сильно ограничивающее, но чтоб с zero-overhead-ом, я бы на это посмотрел. Mna>Rust?
Я пока с ним не знаком, по нормальному. Но судя по некоторым оценкам может получиться как раз замечательное решение. Или не получиться — там сейчас все правила меняются раз в месяц. )))
Mna>Zero overhead бывает двух видов, обычно имеется ввиду первый: Mna>1 язык/рантайм не потребляет больше того что реально нужно, получается шустрая программа, ценой трудов программиста по спецификации типов Mna>2 от программиста не запрашивают специфицировать все типы очень детально, и программа получается не такая шустрая, но зато пишется быстрее.
Mna>так и напрашивается автоматический выводитель типов. чтоб тип сразу в текст в исходник вписывал.
Так раздражает статическая типизация или требование указывать все типы? ) Это немного разные вещи... Видно по тому же Хаскелю, да и в современном C++ уже можно писать код из одних auto. )))
Mna>вот от этой медленности люди и сбегают к динамическим интерпретируемым языкам! Mna>Потому что дольше всех работает оптимизатор машинного кода, а машины сейчас быстрые, для множества задач такой скорости и не требуется
Нуу а машина разработчика ещё намного быстрее быстрых машин пользователей... ))) Во всяком случае моя. )))
Здравствуйте, alex_public, Вы писали:
_>2. Но если захотим и абстрактный интерфейс использовать, то тоже абсолютно никаких проблем. Я не понял откуда ты взял тот бредовый код с наследованием структурки (а не примеси) от интерфейса. Вот нормальный пример:
Если пример не вписывается в концепцию тем хуже для примера.
_>
_>#define declare_hash int GetHash() {/* здесь код Евгения */}
_>
Слово private убивает его реализацию.
_>А особенно это всё забавно на фоне того факта, что на C++ действительно недоступно множество возможностей МП, которые есть в D/Rust/Nemerle. Но вы в них почему-то не попадаете никак — похоже привыкли демонстрировать превосходство Nemerle над совсем унылым C#, а не над C++.)))
Вы сначала примитив осильте.
_>О, а вот передача параметров в запрос по имени локальной переменной — это действительно выглядит классно. В C++ библиотечке для работы с БД аналогичное делается только по порядку, что значительно менее наглядно. Про проверку синтаксиса я вообще не говорю. )))
Ты ещё создание локальных переменных по именам колонок результата запроса не заметил.
_>Да, а вот на D думаю без проблем делается нечто похожее, хотя готовых реализаций не видел.
А ты в D можешь на этапе компиляции в базу данных сходить?
Если нет. То не делается.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если пример не вписывается в концепцию тем хуже для примера.
Ну если ты покажешь мне ситуацию, в которой в данном примере почему-то может быть запрещено наследование HashImpl от IHash, то тогда твои слова ещё будут иметь какой-то смысл. А так, это просто демагогия.
WH> WH>Слово private убивает его реализацию.
Что-что? )
_>>О, а вот передача параметров в запрос по имени локальной переменной — это действительно выглядит классно. В C++ библиотечке для работы с БД аналогичное делается только по порядку, что значительно менее наглядно. Про проверку синтаксиса я вообще не говорю. ))) WH>Ты ещё создание локальных переменных по именам колонок результата запроса не заметил.
Это я как раз видел, но не особо впечатлился, т.к. аналогичный код на C++ выглядит как-то так:
т.е. ни в чём не уступает по удобству. А возможно даже и превосходит за счёт работы автодополнения.
Вот возможность подстановки локальных переменных в запрос по имени — это действительно удобно и подобных решений я на C++ не видел (а вот на Питоне вроде было что-то такое). Хотя тут как раз Евгений выложил очень любопытную реализацию http://rsdn.ru/forum/cpp/5815557
— возможно на её базе и можно было бы сделать что-то близкое...
_>>Да, а вот на D думаю без проблем делается нечто похожее, хотя готовых реализаций не видел. WH>А ты в D можешь на этапе компиляции в базу данных сходить? WH>Если нет. То не делается.
Это было про захват переменной по имени и т.п. А насчёт работы с БД во время компиляции... Т.е. если в данный момент доступа к БД нет, то и проект не удастся скомпилировать? )
: С++/С -- и может даже писать ассемблерные вставки вручную, если С компилятор новые инструкции пока не поддерживает.
): C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond (Abrahams, Gurtovoy)
