Совершенствование средств производства зачастую приводило к росту числа тех, кто их использует.
Мне кажется пример с конвеером в контексте кто кого использует очень не однозначный :). Непонятно это милионы используют конвеер или это владельцы конвеера испльзуют миллионы посредством конвеера.
Кстати конвеер сам по себе тоже очень интересное изобретение, не знаю можно ли сравнивать с ГПТ, но у меня аналогия явно напрашивается.
То есть средства разработки сильно упростятся и станут доступны большему количеству людей.
Как вы считаете физика сильно упростилась после того как была сформулирована теория относительности?
А после открытия транзистора и замены им ламповой техники, насколько упростилась эта техника? А транзисторы ведь проще чем лампы... или нет? Или проще только в каком то смысле?
Не надо ничего придумывать, надо просто вспомнить как что происходило-развивалось раньше.
Кстати лично для меня средства разработки ОЧЕНЬ сильно упростились с начала 90-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Дэниел Лемир, может, и справился бы, но мы (как и авторы всех реализаций, когда я последний раз проверял) — не он
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.
Эта претензия - не к самому языку C++, а лишь к его стандартной библиотеке, которая написана на нем же.
я бы даже дальше пошел в этом направлении:
если это претензия к производительности (скорости исполнения) сгенерированного кода, то это претензия не к языку и не к библиотеке, а к разработчикам конкретной версии компилятора и библиотеки. И, возможно, частично, к тем кто занимается поиском и пользуется разными трюками привязанными к особенностям работы определенной версии компилятора.
Писать код который заточен под особенности работы определенного компилятора мне кажется очень сомнительным направлением приложения усилий.
Все это знание особенностей работы разных компиляторов с точки зрения производительности, оно мимолетно, сегодня одно, завтра другое.
Ворочающий миллионами в день и потенциально могущий привести к очень неприятным судебным процессам код нельзя писать на асме.
Что можно сказать, в общем, разные у нас области применения, и подходы соответственно разные. Всегда интересно познакомиться с чужой проблематикой хотя бы издали.
Я понял что система у вас очень сложная и неодназначная и поэтому вдвойне интересная, спасибо. Глобальные проблемы мы все равно не решим в чате.
вы же вот мне ассемблер демонстрируете, значит вы все равно проверяете что вам компилятор генерирует, только вы каким то косвенным методом работаете, пытаетесь изобрести С++ код по которому компилятор сгенерирует самый лучший ассемблер, так еще и настройки компилятора вам надо контролировать-выписывать.
Раз вы в состоянии проверить что ассемблер хороший, что вам мешает написать этот ассемблер напрямую без капризного посредника в виде С++ компилятора? Нафига вам темплейты сдались? У меня есть только одно объяснение: рассказы про темплейты ценятся гораздо больше чем рассказы про ассемблер. Ассемблер почему то воспринимается как что-то из прошлого века, но только без него ничего не работает в конечном итоге.
вон вы про что! Ну тогда вам точно куски на ассемблере надо писать, а вы взялись темплейты с решениями на виртуальных функциях сравнивать. Не зря вы в начали написали что перешли на что-то другое от темплейтов. Виртуальные функции на этом уровне точно нет смысла применять что там сравнивать то.
10 - 20 даже 100 ассемблерных инструкций всегда проще понять и даже переписать если надо, чем выгребать все сайд эффекты с темплейтами помноженными на оптимизацию в компиляторе которая зависит от десятка настроек, и еще и меняется с версией компилятора. Дело даже не в скорости, темплейты на таком уровне это просто не надежное решение даже.
сообщения от биржи у вас через сокет приходят? три строчки вы не заметите на фоне кода который из сокета читает, мне кажется вы не совсем коректно описываете проблему или причину проблемы которая у вас видимо действительно присутствует, мне кажется.
Попробуйте это сделать с полиморфными пикселями на виртуальных функциях и посмотрите на производительность.
я честно говоря не ожидал что кто-то на уровне пикселей может рассуждать про применений виртуальных функций, пиксели это байты шорты или инты, если попытаться работать с ними как с объектами - это что-то странное для меня, видимо поэтому я вас и не понимаю, теперь я вижу откуда у нас разногласия идут. Но я на уровне обработки пикселей вообще на ассемблере писал тело функции которая вызывается из С++, мне и в голову не приходило применять там темплейты или виртуальные функции, там как раз надо MMX-ы и SSE применять, поэтому без ассемблера никуда.
Если каждый байт-чар, шорт или инт в коде представлен как какая-то структура (объект) как какой-то полиморфный пиксель, тут немудрено огрести проблемы с производительностью. Я никогда такого не делал на таком низком уровне.
Вы наверно не в курсе, был один древний грек, который доказал что Ахилес не сможет обогнать черепаху. Только на способности Ахилеса это доказательство никак не повлияло.
Тоже самое и с вашим примером если он что-то и доказывает то только потому что вы взяли за основу задачу, которая не имеет практического смысла, на приктике такие конструкции не то что никому не нужны , они будут мешать. Поэтому так писать никто не будет, поэтому вы и стесняетесь объяснять в чем смысл вашего кода, потому что объяснения вам самому покажут какая там ерунда написана.
Если бы у этого кода был смысл вы бы смогли его изложить. Дело в том что на бессмысленном примере можно доказать что угодно об этом еще древние греки знали.
Там нет цели минимизировать задержку, топовая производительность там не нужна.
я вам по секрету скажу что вы это сейчас рассказываете тому кто занимался, как раз, там, как раз, достижением Топовой Производительности со всеми MMX-ами, SSE-векторизациями, DirectX-ами, и фиг знает еще с чем. Ваш
лишний indirection в рантайме
это просто какой то ну 5-й класс средней школы по сравнению с какой-то академией если производить сравнение со всеми теми технодогиями который там используются для достижения Топовой Производительности.
еще: если у вас функция на три строчки вызывается 1000 000 раз надо подумать о структуре кода-алгоритма, а не шаблоны городить которые пытаются лечить неэффективно построенный алгоритм.
я ж говорю вы пример приведите реальный я вам покажу как правильно его построить без всяких шаблонов, будет предметный разговор.
Что именно работает? Лишнее время на вызов виртуальной функции и последствия её неинлайнинга?
Лишнее время по сравнению с чем?
Если вы посмотрите в ассемблер то вы не обнаружите сколько нибудь заметной разницы между вызовом виртуальной функции и обычной статической функции. Или вы считаете что дополнительное копирование из памяти в регистр занимает много времени?
и последствия её неинлайнинга
это какое то новое слово в технике программирования, хотелось бы посмотреть пример функции которую вот прям нужно заинлайнить, опять же. Может и new тогда нужно заинлайнить?
Как без шаблонов в одном случае владеть объектом «линейное преобразование входных данных», а в другом — «квадратичное»?
владение объектом с интерфейсом преобразование входных данных нет? не подходит? Почему?
Если бы вы посмотрели как строится плеер видеофайлов (или даже транскодер) вы бы обнаружили что никаких шаблонов там не используется - только интерфейсы при этом нет никаких проблем с производительностью при работе через виртуальные функции, вы же HD кино на компе смотрите? Представляете какой там трафик генерируется-обрабатывается?
Более того если бы видео плеер был построен с использованием шаблонов пришлось бы каждый раз все перекомпилировать при добавлении нового формата данных, нового кодека.
В рантайме? Нет, конечно. Виртуальный вызов много стоит, начиная от прямого оверхеда и заканчивая упущенными возможностями по инлайнингу и прочим последующим оптимизациям.
я вам с удовольствием поверю если вы продемонстрируете какой-то пример в котором это работает так как вы говорите.
Традиционность DSL можно посмотреть по оценке
под DSL вы имеете ввиду domain-specific language ?
Это вроде как язык который надо еще придумать. Я бы даже рассуждать не взялся на такую абстрактную тему.
вот примерно это я и имел ввиду, все кто сталкивался с реальной разработкой с использованием сложных шаблонов рано или поздно от этих шаблонов отказываются в пользу более традиционных (что ли) решений.
Я сам пытался найти смысл применения шаблонов, шаблонов со спецификациями еще в самом начале 2000-х и пришел к выводу что разные формы наследования и владения объектов работают гораздо эффективней шаблонов практически в любой задаче. Вы не найдете шаблонов в WPF например, в OpenGL, что еще привести для примера? Шаблоны хороши только для библиотек функций по коллекциям например.
А можете привести пример адекватной реализации какого-то алгоритма на основе сложных шаблонов? Адекватного в том смысле что его нельзя проще и эффективнее с точки зрения производительности скомпилированного кода переписать без сложных шаблонов?
Мне кажется пример с конвеером в контексте кто кого использует очень не однозначный :). Непонятно это милионы используют конвеер или это владельцы конвеера испльзуют миллионы посредством конвеера.
Кстати конвеер сам по себе тоже очень интересное изобретение, не знаю можно ли сравнивать с ГПТ, но у меня аналогия явно напрашивается.
Как вы считаете физика сильно упростилась после того как была сформулирована теория относительности?
А после открытия транзистора и замены им ламповой техники, насколько упростилась эта техника? А транзисторы ведь проще чем лампы... или нет? Или проще только в каком то смысле?
Не надо ничего придумывать, надо просто вспомнить как что происходило-развивалось раньше.
Кстати лично для меня средства разработки ОЧЕНЬ сильно упростились с начала 90-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
Прогресс идет давно и как-то волнами.
На смену античному рассвету приходит Святая инквизиция,
на смену научным прорывам, период мировых войн...
В общем скрипач, то есть программист не нужен, нужно КЦ.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.
я бы даже дальше пошел в этом направлении:
если это претензия к производительности (скорости исполнения) сгенерированного кода, то это претензия не к языку и не к библиотеке, а к разработчикам конкретной версии компилятора и библиотеки. И, возможно, частично, к тем кто занимается поиском и пользуется разными трюками привязанными к особенностям работы определенной версии компилятора.
Писать код который заточен под особенности работы определенного компилятора мне кажется очень сомнительным направлением приложения усилий.
Все это знание особенностей работы разных компиляторов с точки зрения производительности, оно мимолетно, сегодня одно, завтра другое.
Что можно сказать, в общем, разные у нас области применения, и подходы соответственно разные. Всегда интересно познакомиться с чужой проблематикой хотя бы издали.
Я понял что система у вас очень сложная и неодназначная и поэтому вдвойне интересная, спасибо. Глобальные проблемы мы все равно не решим в чате.
вы же вот мне ассемблер демонстрируете, значит вы все равно проверяете что вам компилятор генерирует, только вы каким то косвенным методом работаете, пытаетесь изобрести С++ код по которому компилятор сгенерирует самый лучший ассемблер, так еще и настройки компилятора вам надо контролировать-выписывать.
Раз вы в состоянии проверить что ассемблер хороший, что вам мешает написать этот ассемблер напрямую без капризного посредника в виде С++ компилятора? Нафига вам темплейты сдались? У меня есть только одно объяснение: рассказы про темплейты ценятся гораздо больше чем рассказы про ассемблер. Ассемблер почему то воспринимается как что-то из прошлого века, но только без него ничего не работает в конечном итоге.
вон вы про что! Ну тогда вам точно куски на ассемблере надо писать, а вы взялись темплейты с решениями на виртуальных функциях сравнивать. Не зря вы в начали написали что перешли на что-то другое от темплейтов. Виртуальные функции на этом уровне точно нет смысла применять что там сравнивать то.
10 - 20 даже 100 ассемблерных инструкций всегда проще понять и даже переписать если надо, чем выгребать все сайд эффекты с темплейтами помноженными на оптимизацию в компиляторе которая зависит от десятка настроек, и еще и меняется с версией компилятора. Дело даже не в скорости, темплейты на таком уровне это просто не надежное решение даже.
сообщения от биржи у вас через сокет приходят? три строчки вы не заметите на фоне кода который из сокета читает, мне кажется вы не совсем коректно описываете проблему или причину проблемы которая у вас видимо действительно присутствует, мне кажется.
да фиг с ним можно без всяких умных слов, простой вопрос:
вы действительно считаете что масив констант запихать на стек в виде:
и делать это при каждом вызове это нормально?
по поводу
я честно говоря не ожидал что кто-то на уровне пикселей может рассуждать про применений виртуальных функций, пиксели это байты шорты или инты, если попытаться работать с ними как с объектами - это что-то странное для меня, видимо поэтому я вас и не понимаю, теперь я вижу откуда у нас разногласия идут. Но я на уровне обработки пикселей вообще на ассемблере писал тело функции которая вызывается из С++, мне и в голову не приходило применять там темплейты или виртуальные функции, там как раз надо MMX-ы и SSE применять, поэтому без ассемблера никуда.
Если каждый байт-чар, шорт или инт в коде представлен как какая-то структура (объект) как какой-то полиморфный пиксель, тут немудрено огрести проблемы с производительностью. Я никогда такого не делал на таком низком уровне.
Вы наверно не в курсе, был один древний грек, который доказал что Ахилес не сможет обогнать черепаху. Только на способности Ахилеса это доказательство никак не повлияло.
Тоже самое и с вашим примером если он что-то и доказывает то только потому что вы взяли за основу задачу, которая не имеет практического смысла, на приктике такие конструкции не то что никому не нужны , они будут мешать. Поэтому так писать никто не будет, поэтому вы и стесняетесь объяснять в чем смысл вашего кода, потому что объяснения вам самому покажут какая там ерунда написана.
Если бы у этого кода был смысл вы бы смогли его изложить. Дело в том что на бессмысленном примере можно доказать что угодно об этом еще древние греки знали.
я вам по секрету скажу что вы это сейчас рассказываете тому кто занимался, как раз, там, как раз, достижением Топовой Производительности со всеми MMX-ами, SSE-векторизациями, DirectX-ами, и фиг знает еще с чем. Ваш
это просто какой то ну 5-й класс средней школы по сравнению с какой-то академией если производить сравнение со всеми теми технодогиями который там используются для достижения Топовой Производительности.
еще: если у вас функция на три строчки вызывается 1000 000 раз надо подумать о структуре кода-алгоритма, а не шаблоны городить которые пытаются лечить неэффективно построенный алгоритм.
я ж говорю вы пример приведите реальный я вам покажу как правильно его построить без всяких шаблонов, будет предметный разговор.
Лишнее время по сравнению с чем?
Если вы посмотрите в ассемблер то вы не обнаружите сколько нибудь заметной разницы между вызовом виртуальной функции и обычной статической функции. Или вы считаете что дополнительное копирование из памяти в регистр занимает много времени?
это какое то новое слово в технике программирования, хотелось бы посмотреть пример функции которую вот прям нужно заинлайнить, опять же. Может и new тогда нужно заинлайнить?
владение объектом с интерфейсом преобразование входных данных нет? не подходит? Почему?
Если бы вы посмотрели как строится плеер видеофайлов (или даже транскодер) вы бы обнаружили что никаких шаблонов там не используется - только интерфейсы при этом нет никаких проблем с производительностью при работе через виртуальные функции, вы же HD кино на компе смотрите? Представляете какой там трафик генерируется-обрабатывается?
Более того если бы видео плеер был построен с использованием шаблонов пришлось бы каждый раз все перекомпилировать при добавлении нового формата данных, нового кодека.
я вам с удовольствием поверю если вы продемонстрируете какой-то пример в котором это работает так как вы говорите.
под DSL вы имеете ввиду domain-specific language ?
Это вроде как язык который надо еще придумать. Я бы даже рассуждать не взялся на такую абстрактную тему.
вот примерно это я и имел ввиду, все кто сталкивался с реальной разработкой с использованием сложных шаблонов рано или поздно от этих шаблонов отказываются в пользу более традиционных (что ли) решений.
Я сам пытался найти смысл применения шаблонов, шаблонов со спецификациями еще в самом начале 2000-х и пришел к выводу что разные формы наследования и владения объектов работают гораздо эффективней шаблонов практически в любой задаче. Вы не найдете шаблонов в WPF например, в OpenGL, что еще привести для примера? Шаблоны хороши только для библиотек функций по коллекциям например.
А можете привести пример адекватной реализации какого-то алгоритма на основе сложных шаблонов? Адекватного в том смысле что его нельзя проще и эффективнее с точки зрения производительности скомпилированного кода переписать без сложных шаблонов?