Здравствуйте, __kot2, Вы писали:
V>>А по мне так OpenCV прекрасно работает, и даже с CUDA нет никаких проблем. __>я не в курсе как он работет, если честно.
Хорошо работает, не идеально, но хорошо. Причина: тесты, огромная база пользователей, поддержка множества платформ (как программных, так и аппаратных).
__>у со своей колокольни кому сказать что куча научного софта на самом деле гавно, которое прдюсит невалидный кал огромных обьемов, загрязнящий что то осмысленное. кал этот совершенно бесполезно испавлять. только его аффтар понимает в этих макаронах хоть что-то. это называется job security, да, когда только тпкущие разработчики могут что-то там сделать, а остальные потеряются где-то пытаясь понять что имелось в виду во всей вот этой вот бадяге.
Куча научного софта реализует достаточно сложные алгоритмы, которые даже идеально написанные будут непонятны без глубокого знания бэкграунда.
Здравствуйте, Кодт, Вы писали:
V>>Ну или разработчики OpenCV как вариант.
К>Такое впечатление, что разработчики OpenCV просто перепёрли сишный код на плюсы — да и то, лишь ради самоочистки пяти локальных массивов.
Это было верно для OpenCV 2.xx. Там как раз начало появляться С++ API. Собственно, поэтому поводу версия и сменилась на двойку.
Для версии 3.хх твоё утверждение уже не верно.
Здравствуйте, Kernan, Вы писали:
K>Ничего не надо писать на С. Везде можно использовать С++ и по производительности он будет как С-шный код если ты умеешь писать на С++.
Чтобы крестовый код только догнал по производительность хорошо написанный чисты С придется отказаться от шаблонов, исключений, классов и еще кучи всего. Ну и смысла тогда морочиться с крестами если сишный код получается гораздо чище и намного легче читается?
Здравствуйте, Кодт, Вы писали:
К>Такое впечатление, что разработчики OpenCV просто перепёрли сишный код на плюсы — да и то, лишь ради самоочистки пяти локальных массивов.
Код действительно перенесли на С++ с Си, у них там образовалось два варианта использования.
Здравствуйте, Nuzhny, Вы писали: N>Хорошо работает, не идеально, но хорошо. Причина: тесты, огромная база пользователей, поддержка множества платформ (как программных, так и аппаратных).
обычо жизненный цикл подобных проектов таков:
из за всех этих захаржкоженных констант и спагеттей багов там конечно навалом. но так как сами результаты нечеткие в глаза это так не бросается. но конечн люди их фиксят потихоньку. однако из-за невозможности понять реальную причину бага будут фиксить симптоматически. если из ф-ии выходит 2, а нужно 3, то вставят просто if после ф-ии, который инкрементит результат. в итоге через несколько лет код так усложнится, что люди годами будут занимться только какими-то рефакторингом не сдвигаясь с места. как например с Нетскейпом было. Пройдут годы, рефакторинг так и не закончится, а opencv будет забыт и замещен другим продуктом. может потом, когда команда говнарей полностью сменится, то проект вынырнет из проруби и снова получит некую популярность, как это стало с Netscape-Mozilla-Firefox. но уже позднвато будет. а все потому что ручки кривые у текущих программистов
__>>у со своей колокольни кому сказать что куча научного софта на самом деле гавно, которое прдюсит невалидный кал огромных обьемов, загрязнящий что то осмысленное. кал этот совершенно бесполезно испавлять. только его аффтар понимает в этих макаронах хоть что-то. это называется job security, да, когда только тпкущие разработчики могут что-то там сделать, а остальные потеряются где-то пытаясь понять что имелось в виду во всей вот этой вот бадяге.
N>Куча научного софта реализует достаточно сложные алгоритмы, которые даже идеально написанные будут непонятны без глубокого знания бэкграунда.
когда делаешь всегда надо понимать смысл того что делаешь. если общего смысла не видно, то его и искать не стоитю нет его. просто какая-то подгонметрия под нужные результаты
Здравствуйте, __kot2, Вы писали:
__>обычо жизненный цикл подобных проектов таков: __>из за всех этих захаржкоженных констант и спагеттей багов там конечно навалом. но так как сами результаты нечеткие в глаза это так не бросается. но конечн люди их фиксят потихоньку. однако из-за невозможности понять реальную причину бага будут фиксить симптоматически. если из ф-ии выходит 2, а нужно 3, то вставят просто if после ф-ии, который инкрементит результат. в итоге через несколько лет код так усложнится, что люди годами будут занимться только какими-то рефакторингом не сдвигаясь с места. как например с Нетскейпом было. Пройдут годы, рефакторинг так и не закончится, а opencv будет забыт и замещен другим продуктом. может потом, когда команда говнарей полностью сменится, то проект вынырнет из проруби и снова получит некую популярность, как это стало с Netscape-Mozilla-Firefox. но уже позднвато будет. а все потому что ручки кривые у текущих программистов
Ну, прямо с OpenCV такая ситуация вряд ли сложится.
Он, во-первых, не так плохо написан.
Во-вторых, он модульный, очень даже хорошо модульный. Не какая-то единая библиотека, а набор библиотек.
В-третьих, вменяемых альтернатив пока не видно.
Здравствуйте, Nuzhny, Вы писали:
N>Во-вторых, он модульный, очень даже хорошо модульный. Не какая-то единая библиотека, а набор библиотек.
OpenCV можно воспринимать даже не как набор библиотек, а как набор независимых друг от друга функций, для удобства разделённых на модули. Для пользователя это значит сверхнизкий порог входа.
N>В-третьих, вменяемых альтернатив пока не видно.
Судя по описанию OpenCV клиенты и поддержка была от Intel, NVidia, Microsoft. Предположу, что это IPP, CUDA и Kinect. Альтернативы есть, но гораздо более слабые, причём речь идёт о наличии огромного количества функционала.
Могу так же предположить, что сделай они изначально всё на шаблонах C++, у них бы получилось лучше. Проблема в том, что при таком подходе OpenCV скорее всего бы загнулся, так как помимо предметной области возникла бы потребность в изучении очень мощных программных концепций. Это в свою очередь повлекло бы поиск специалистов, что крайне затруднительно в условиях, когда нет постоянных источников дохода.
Здравствуйте, pestis, Вы писали:
P>Чтобы крестовый код только догнал по производительность хорошо написанный чисты С придется отказаться от шаблонов, исключений, классов и еще кучи всего. Ну и смысла тогда морочиться с крестами если сишный код получается гораздо чище и намного легче читается?
Использовать или не использовать исключения право каждого программиста, возразить нечего по поводу того, что они замедлят работу по сравнению с тем кодом, который написан без исключений. Но что касается шаблонов С++ абсолютно не согласен. Мы же не об ООП говорим, как в случае тех же исключений. Шаблоны С++ это просто генератор кода. Как по вашему он замедляет работу?
Внутри всё оптимизировано, хотите используйте динамический массив vector, если нужен статический, то пожалуйста array. Итераторы для разных видов контейнеров, тех же последовательных или ассоциативных, оптимизированы по максиму. Важно научиться различать используемые операторы, и тогда скорость алгоритмов не уступят Си ни на такт. Потому что внутри генерируется доступ по тем же указателям, просто есть возможность не парить себе мозги и доверить реализацию оптимального способа в каждом конкретном случае разработчикам STL. Ну и собственные алгоритмы и библиотеки алгоритмов станут иными.
А по поводу легче читается или нет тоже большой вопрос. Я могу только сказать, что кодогенерации научиться сложнее, так как это следующий уровень абстракций, а значит и следующий уровень программиста. На мой взгляд программисты использующие шаблоны С++ стоят по уровню умений выше чистых сишников, так как первым в случае необходимости опустится ниже легче, чем вторым поднятся. Хотя процесс этот неоднозначен. Как-то помог студенту решить завершающую курс задачу на Борланде С++ 3.1, весь исплевался. Здесь очевидно так же.
И ещё есть множество книг по шаблонам C++, и я вполне понимаю, почему сишники их не читают. Особенно, когда знакомство начинается с Александреску, а это всё, туши свет. Потому я бы крайне рекомендовал прочесть книгу STL для программистов на C++ — Леен Аммерааль, а не всяких Страуструпов, Мейерсов, Вандевурдов с Джосаттисами и прочих весёлых ребят. А иначе новичку трудно понять трансформацию кода из Си в С++ и почему последнее в итоге лучше. Вместо этого сразу начинается жёсткая кодогенерация, у сишника рвотный рефлекс, и далее мы имеем множество людей хающих шаблоны С++, но не имеющих о них реального представления.
Здравствуйте, velkin, Вы писали:
V>Использовать или не использовать исключения право каждого программиста, возразить нечего по поводу того, что они замедлят работу по сравнению с тем кодом, который написан без исключений.
zero-cost exceptions на happy-path могут быть даже быстрее чем раскиданные по всему коду if(errorX) goto ERROR_X;
V>Важно научиться различать используемые операторы, и тогда скорость алгоритмов не уступят Си ни на такт.
Конечно можно выписывать на C каждый вариант вручную (либо генерировать) чтобы получить код не медленнее чем на C++ — но по факту уходят в медленный runtime полиморфизм — например, или взять тот же qsort — отсюда и тормоза.
V>И ещё есть множество книг по шаблонам C++, и я вполне понимаю, почему сишники их не читают. Особенно, когда знакомство начинается с Александреску, а это всё, туши свет. Потому я бы крайне рекомендовал прочесть книгу STL для программистов на C++ — Леен Аммерааль, а не всяких Страуструпов, Мейерсов, Вандевурдов с Джосаттисами и прочих весёлых ребят. А иначе новичку трудно понять трансформацию кода из Си в С++ и почему последнее в итоге лучше. Вместо этого сразу начинается жёсткая кодогенерация, у сишника рвотный рефлекс, и далее мы имеем множество людей хающих шаблоны С++, но не имеющих о них реального представления.
Это где же жёсткая кодогенерация у Страуструпа? Его книжки как раз подходят новичкам. А Майерс это вообще что-то типа common pitfalls, а не учебник.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это где же жёсткая кодогенерация у Страуструпа? Его книжки как раз подходят новичкам.
А вот и зря, ещё в 1999 году его купил, Язык программирования С++ 3-е издание. Его можно рассматривать как отличный справочник, но не как учебное пособие. Моё мнение, человек начитавшись Страуструпа освоит языковые конструкции, голый синтаксис, но третья часть "Стандартная библиотека" не даст понимания глубинного смысла всего этого действа. Жёсткая кодогенерация в Александреску. Вместо Страуструпа можно было бы прочитать словарь по английскому языку, начиная от A до Z. Тоже польза, если хочешь стать языковым экспертом, но удастся ли заговорить сделав лишь это?
EP>А Майерс это вообще что-то типа common pitfalls, а не учебник.
У меня это идёт как-то так:
Наиболее эффективное использование C++ 35 новых способов улучшить стиль программирования 1-е издание
Эффективное использование C++ 50 рекомендаций по улучшению ваших программ и проектов 2-е издание
Эффективное использование STL (речь об этой книге)
Проблема в том, что все его материалы даны в виде советов, даже про STL. Сначала мне думается нужно научиться использовать STL и понять его смысл, а уже потом изучать советы как дополнение.
Мне просто непонятно, почему хают кодогенерацию называя её медленной, вот и размышляю. По всем прикидкам скорость исполнения программ такая же как в Си, но выражения гораздо более лаконичные и вкладываются друг в друга. Просто генератор, ничего сверхъестественного. Понятно, что не всем по вкусу, но так и против истины идти не нужно.
Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>Это где же жёсткая кодогенерация у Страуструпа? Его книжки как раз подходят новичкам. А Майерс это вообще что-то типа common pitfalls, а не учебник.
Страуструп может представлять только исторический интерес. Глядя на его код просто умиляешься, как будто "Повесть о полку Игореве" читаешь.
Нет, от чтения, конечно, хуже не будет, но не надо воспринимать его буквально.
Из дурацких книг по С++ отдельно могу отметить "решение несуществующих задач" Саттера.
Здравствуйте, __kot2, Вы писали:
__>Из дурацких книг по С++ отдельно могу отметить "решение несуществующих задач" Саттера.
У меня в коллекции Саттер Герб:
Новые сложные задачи на C++ 40 новых головоломных примеров с решениями
Решение сложных задач на C++ 87 головоломных примеров с решениями
Стандарты программирования на C++ 101 правило и рекомендация
Это видимо вольная интерпретация, так же как "Новые несуществующие задачи на C++".
Здравствуйте, velkin, Вы писали:
EP>>Это где же жёсткая кодогенерация у Страуструпа? Его книжки как раз подходят новичкам. V>А вот и зря, ещё в 1999 году его купил, Язык программирования С++ 3-е издание. Его можно рассматривать как отличный справочник, но не как учебное пособие. Моё мнение, человек начитавшись Страуструпа освоит языковые конструкции, голый синтаксис, но третья часть "Стандартная библиотека" не даст понимания глубинного смысла всего этого действа.
Нет, это не справочник. Там большая часть это именно обучение хорошему стилю.
Вот взять например главу про парсер/калькулятор — там сначала строится один вариант, показываются недостатки, потом через ввод дополнительных средств показывается следующий вариант, и эмнип так несколько раз. Это разве справочник? А вот его C++ ARM — это как раз справочник.
Да и вообще, у Страуструпа TC++PL это не единственная книга. TC++PL это скорее средний уровень нежели начальный.
Для совсем начинающих у него есть "Programming — Principles and Practice Using C++", причём это не просто для начинающих C++, а для начинающих программировать вообще.
EP>>А Майерс это вообще что-то типа common pitfalls, а не учебник. V>... V>Проблема в том, что все его материалы даны в виде советов, даже про STL. Сначала мне думается нужно научиться использовать STL и понять его смысл, а уже потом изучать советы как дополнение.
Мой комментарий был про то, что у Майерса не шаблонное метапроргаммирование и кодогенерация, а всего лишь набор советов.
С тем что начинать изучение STL нужно не с советов — полностью согласен.
V>Мне просто непонятно, почему хают кодогенерацию называя её медленной, вот и размышляю. По всем прикидкам скорость исполнения программ такая же как в Си, но выражения гораздо более лаконичные и вкладываются друг в друга.
Это известный и крайне популярный миф, мол если нужна скорость — то нужно переписать на C. На практике же получается что код на C медленней. Страуструп, кстати, постоянно борется с этим мифом — раскрывает тему в своих статьях, презентациях.
Почему программисты так охотно в верят в этот миф? Думаю эта вера основывается на следующей эвристике: "Чем больше абстракций — тем медленней код. Чтобы получить быстрый код — нужно принести абстракции в жертву богу Performance, щедро полив его алтарь boilerplate'ом и lines of code'ом, сгорбившись над клавиатурой выстрачивая C код" Причём для многих языков эта эвристика действительна справедлива.
Проверить, убедится, осознать что в C++ получилась вишенка — крайне дешёвые и зачастую бесплатные абстракции — видимо не позволяет невежество.
http://www.stepanovpapers.com/BYTE_com.htm
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.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Evgeny.Panasyuk, Вы писали: EP>>Это где же жёсткая кодогенерация у Страуструпа? Его книжки как раз подходят новичкам. А Майерс это вообще что-то типа common pitfalls, а не учебник. __>Страуструп может представлять только исторический интерес. Глядя на его код просто умиляешься, как будто "Повесть о полку Игореве" читаешь.
Это про какой код, и чему конкретно умиляешься?
У него есть свежие издания книг. Да и в TC++PL старого третьего издания ничего ужасного/ветхого не помню (с поправкой на старый стандарт)
Здравствуйте, velkin, Вы писали:
N>>Во-вторых, он модульный, очень даже хорошо модульный. Не какая-то единая библиотека, а набор библиотек. V>OpenCV можно воспринимать даже не как набор библиотек, а как набор независимых друг от друга функций, для удобства разделённых на модули. Для пользователя это значит сверхнизкий порог входа.
Почти так. Сейчас это набор функций и классов с зависимостью от opencv_core, в котором реализована матричная математика.
N>>В-третьих, вменяемых альтернатив пока не видно. V>Судя по описанию OpenCV клиенты и поддержка была от Intel, NVidia, Microsoft. Предположу, что это IPP, CUDA и Kinect. Альтернативы есть, но гораздо более слабые, причём речь идёт о наличии огромного количества функционала.
Intel и AMD своими силами пилят OpenCL часть. NVidia добавила поддержку CUDA, есть отдельная ветка чисто для Tegra. Майкрософт, вроде, ничего не делает, поддержкой Кинекта занимается сам ITSeez, так как у них основной бизнес — навигация мобильных роботов.
OpenCV сейчас стал практически стандартом в своей области, тот же Khronos разрабатывал openvx с оглядкой на OpenCV.
V>Могу так же предположить, что сделай они изначально всё на шаблонах C++, у них бы получилось лучше. Проблема в том, что при таком подходе OpenCV скорее всего бы загнулся, так как помимо предметной области возникла бы потребность в изучении очень мощных программных концепций. Это в свою очередь повлекло бы поиск специалистов, что крайне затруднительно в условиях, когда нет постоянных источников дохода.
Изначально OpenCV была открытой альтернативой IPP, но медленной, глючной с небольшим числом добавочного функционала. А потом, когда Интел отказался от разработки, развитие пошло как снежный ком.
---один раз сойдет (как уже писали), но меня смущает прекрасное оформление этого кода. То ли корпоративные стандарты оформления свято блюдутся даже для одно-минутных поделок, то ли код был написан
Здравствуйте, velkin, Вы писали:
V>Использовать или не использовать исключения право каждого программиста, возразить нечего по поводу того, что они замедлят работу по сравнению с тем кодом, который написан без исключений. Но что касается шаблонов С++ абсолютно не согласен. Мы же не об ООП говорим, как в случае тех же исключений. Шаблоны С++ это просто генератор кода. Как по вашему он замедляет работу?
Очевидно, генерирует неоптимальный код.
V>Внутри всё оптимизировано, хотите используйте динамический массив vector, если нужен статический, то пожалуйста array. Итераторы для разных видов контейнеров, тех же последовательных или ассоциативных, оптимизированы по максиму. Важно научиться различать используемые операторы, и тогда скорость алгоритмов не уступят Си ни на такт. Потому что внутри генерируется доступ по тем же указателям, просто есть возможность не парить себе мозги и доверить реализацию оптимального способа в каждом конкретном случае разработчикам STL. Ну и собственные алгоритмы и библиотеки алгоритмов станут иными.
Откуда разработчикам STL знать как нужно оптимизировать код для МОЕЙ задачи? Да и практический опыт говорит в мою пользу: если выкинуть стандартную коллекцию и написать свою, глубоко заточенную на конкретную задачу, то производительность вырастает в несколько раз.
V>А по поводу легче читается или нет тоже большой вопрос. Я могу только сказать, что кодогенерации научиться сложнее, так как это следующий уровень абстракций, а значит и следующий уровень программиста. На мой взгляд программисты использующие шаблоны С++ стоят по уровню умений выше чистых сишников, так как первым в случае необходимости опустится ниже легче, чем вторым поднятся. Хотя процесс этот неоднозначен. Как-то помог студенту решить завершающую курс задачу на Борланде С++ 3.1, весь исплевался. Здесь очевидно так же.
Очевидно что код на С делает ровно то что написано, ровно так как написано. Поэтому его легко писать, легко читать и легко оптимизировать. Если нужны абстракции более высокого уровня, совершенно необязательно пытаться выразить их на C. Существуют такие прекрасные языки, как Python, OCaml, Haskel, Java, Scala, которые легко и прозрачно интегрируются с С сохраняя его производительность и чистоту кода. В такой архитектуре написан numpy который сочетает изумительную производительность С и уникальную скорость кодирования python.
Причём для многих языков эта эвристика действительна справедлива.
