Здравствуйте, landerhigh, Вы писали:
L>А с каких это пор OpenSSL вошел в стандарт C++?
Я про доверие к несамописным библиотекам.
Стандарт описывает только интерфейс и контракты. Кто будет писать имплементацию стандарт не определяет.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>А с каких это пор OpenSSL вошел в стандарт C++? CC>Я про доверие к несамописным библиотекам.
А кто говорил про доверие к несамописным библиотекам?
CC>Стандарт описывает только интерфейс и контракты. Кто будет писать имплементацию стандарт не определяет.
Здравствуйте, jazzer, Вы писали:
J>ну т.е. претензии к реализации, а не к самой библиотеке. ОК.
То как она спроектирована (всё на шаблонах) даёт основания считать что сделать нормальную реализацию некоторых алгоритмов (того же мерсена, который крайне выигрывает от правильно написанного SSE) будет геморно, поэтому никто делать её просто не станет. А нафига — и так ведь сносно работает.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>Т.е. у тебя претензии не к стандартной библиотеке (т.е. к интерфейсу) производства комитета по С++, а к конкретной реализации производства конкретного компиляторостроителя?
1. Любая реализация будет ограничена заданными рамками интерфейса.
2. В проект пойдёт код из "конкретной реализации" а не абстрактный стандарт.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Т.е. у тебя претензии не к стандартной библиотеке (т.е. к интерфейсу) производства комитета по С++, а к конкретной реализации производства конкретного компиляторостроителя?
CC>1. Любая реализация будет ограничена заданными рамками интерфейса. CC>2. В проект пойдёт код из "конкретной реализации" а не абстрактный стандарт.
Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию?
Здравствуйте, landerhigh, Вы писали:
L>А кто говорил про доверие к несамописным библиотекам?
Ты
L>Да-да, надо использовать самописные...
Мы тут обсуждаем твою конкретную претензию к источнику кода. После того как выясним что самописные библиотеки ничем не хуже не-самописных можно будет двигаться дальше.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>ну т.е. претензии к реализации, а не к самой библиотеке. ОК. CC>То как она спроектирована (всё на шаблонах) даёт основания считать что сделать нормальную реализацию некоторых алгоритмов (того же мерсена, который крайне выигрывает от правильно написанного SSE) будет геморно, поэтому никто делать её просто не станет. А нафига — и так ведь сносно работает.
Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать).
Здравствуйте, jazzer, Вы писали:
J>Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию?
Думаю что можно. Но это будет геморройнее, поэтому вряд ли кто либо это станет делать ради стандартной либы.
Куда проще будет сделать нешаблонную версию и забацать её как полагается.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, jazzer, Вы писали:
J>Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать).
Можешь попробовать реализовать.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Т.е. ты фактически утверждаешь, что в рамках описанного в Стандарте интерфейса невозможно написать эффективную реализацию? CC>Думаю что можно. Но это будет геморройнее, поэтому вряд ли кто либо это станет делать ради стандартной либы. CC>Куда проще будет сделать нешаблонную версию и забацать её как полагается.
и что же помешает позвать эту нешаблонную версию из соответствующей специализации стандартной функции?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, jazzer, Вы писали:
J>>Э-э-э... Специализации для SSE-совместимых типов никто не отменял (SSE все равно только с конкретными типами будет работать). CC>Можешь попробовать реализовать.
Ну если бы мне это было нужно, реализовал бы. Например, некоторые stl-ные алгоритмы я специализировал для конкретных типов, полет нормальный.
В общем, в сухом остатке, претензий к самой библиотеке у тебя нет, есть претензии к конкретным реализациям, и есть смутные подозрения, что подсунуть правильную реализацию, оставаясь в рамках интерфейса, будет трудно.
Я правильно резюмировал?
Здравствуйте, CreatorCray, Вы писали:
L>>А кто говорил про доверие к несамописным библиотекам? CC>Ты CC>
L>Да-да, надо использовать самописные...
CC>Мы тут обсуждаем твою конкретную претензию к источнику кода. После того как выясним что самописные библиотеки ничем не хуже не-самописных можно будет двигаться дальше.
Кому, надо, тот понял, что я имею в виду. А дальше кормить тролля я не намерен.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
Эээ... А почему не Б3-21? Еще сильнее к экономии приучит. У него, ЕМНИП, 7 регистров против 14 у 34-ки.
BZ>в общем, я считаю что компиляторы и калькуляторы — это зло. и начать бороться с ними надо с детсада. вместо айфона выдавать каждому ребёнку бз-34, это и для мускулов нагрузка, и для ума
даешь тачку-смартфон и чемодан с аккумулятором в массы!
80% людей оценивают свое мастерство выше среднего...
__>>Что же в вашей "реальности" по другому?
SVZ>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно).
Ты что, GUI приложения пишешь?
Ощущается так.
Шаблоны позволяют писать БОЛЕЕ БЫСТРЫЙ код. Шаблоны дают компилятору возможность соптимизировать код под определённый тип, и это значительно ускоряет.
Например, пишешь ты массив через шаблоны. Ну или кэш подкачки с диска. Дела это не меняет.
Если бы ты писал универсальный код на С, адресация (*) разложилась на ассемблере как
mov eax, index
mov edx, sizeof(ParameterType)
mul eax
add eax, base
здесь операция умножения mul весьма медленная!!! это будет работать плохо и долго
А для шаблона с параметром длиной 9 компилятор сможет записать
lea eax, [edx][edx*8]
это ЗНАЧИТЕЛЬНО увеличивает скорость доступа!!! К кэшу или к массиву, например.
При этом подобные оптимизации компилятор способен делать для большинства длин типов, например, для 3, 5,7,8 и так далее
И для типа каждой длины компилятор сгенерит оптимальный код. Индивидуально.
Плата за это — это раздувание кода: шаблон не создаёт тип, тип создаётся для каждой вариации шаблона.
И компилер для каждого набора параметров будет генерить свой код массива, например.
Использовал код массива для 20 типов — получил 20 наборов функций для работы с массивом.
И вообще: то, что вы не умеете пользоватся инструментом, ещё не значит, что он не нужен. Просто нужно знать свой манёвр: когда и какой инструмент использовать хорошо, когда плохо, а когда на вкус разработчика.
Резюмирую: шаблоны мощное средство написания оптимального кода, приводящее к раздуванию размера итогового исполнимого файла.
Здравствуйте, Molchalnik, Вы писали: M>Здравствуйте, Stanislav V. Zudin, Вы писали:
__>>>Что же в вашей "реальности" по другому? SVZ>>А в реальности 90% кода пишется под конкретную задачу и шаблоны там ничем не помогут. Вот сделать код нечитабельным — это запросто (таких примеров предостаточно). M>Ты что, GUI приложения пишешь? M>Ощущается так.
Хе-хе, не совсем. Хотя и гуя предостаточно. M>Шаблоны позволяют писать БОЛЕЕ БЫСТРЫЙ код. Шаблоны дают компилятору возможность соптимизировать код под определённый тип, и это значительно ускоряет.
M>Например, пишешь ты массив через шаблоны. Ну или кэш подкачки с диска. Дела это не меняет.
. M>В массиве пишешь адресацию типа
M>ParameterType & address_of_type = base[index]; (*)
M>Задаёшь написанный массив для типа длинной 9 бит
M>Если бы ты писал универсальный код на С, адресация (*) разложилась на ассемблере как
M>mov eax, index M>mov edx, sizeof(ParameterType) M>mul eax M>add eax, base
M>здесь операция умножения mul весьма медленная!!! это будет работать плохо и долго
M>А для шаблона с параметром длиной 9 компилятор сможет записать
M>lea eax, [edx][edx*8]
M>это ЗНАЧИТЕЛЬНО увеличивает скорость доступа!!! К кэшу или к массиву, например.
M>При этом подобные оптимизации компилятор способен делать для большинства длин типов, например, для 3, 5,7,8 и так далее
M>И для типа каждой длины компилятор сгенерит оптимальный код. Индивидуально.
M>Плата за это — это раздувание кода: шаблон не создаёт тип, тип создаётся для каждой вариации шаблона.
M>И компилер для каждого набора параметров будет генерить свой код массива, например.
M>Использовал код массива для 20 типов — получил 20 наборов функций для работы с массивом.
Превосходно, ты привел пример контейнера, который используется для 20 разных типов. В данном случае логично использовать шаблоны. Кстати, если бы ты был чуточку внимательнее, я этот случай упоминал в сообщении строчкой выше:
В основном из повторяющегося это контейнеры, какие-нибудь адаптеры и небольшие низкоуровневые алгоритмы.
Т.е. "кирпичики".
А если задача стоит, ну скажем, написать восстановление электрической схемы из геометрических примитивов, то куда ты присобачишь шаблоны? Задача одна, выполняется для одного вполне определенного набора данных и параметризировать ее смысла нет. А таких задач, что у меня, что у топикстартера как раз примерно 90% от общего кода. M>И вообще: то, что вы не умеете пользоватся инструментом, ещё не значит, что он не нужен. Просто нужно знать свой манёвр: когда и какой инструмент использовать хорошо, когда плохо, а когда на вкус разработчика.
Да ладно, что нас старых попрекать-то, кодим как можем... M>Резюмирую: шаблоны мощное средство написания оптимального кода, приводящее к раздуванию размера итогового исполнимого файла.
Все-таки не удержусь и проедусь по твоему примеру.
Ну вот имеем мы твой массив
std::vector<ParameterType> base;
Куда нужно воткнуть шаблон, чтобы компилятор поменял вычисление смещения?
Или я неправильно понял и ты имел в виду работу с массивом байт, типа такого:
т.к. размер типа известен на этапе компиляции и поэтому код подвергается дополнительным оптимизациям на ассемблерном уровне.
Первый же код хорош тем, что он будет существовать в единственном экземпляре для всех типов. Объём кода меньше.
SVZ>Или я неправильно понял и ты имел в виду работу с массивом байт, типа такого: SVZ>
уточняю: нет разницы между конкретной реализацией и реализацией шаблона. Шаблон — лишь метод получения конкретной реализации кода.
Разница возникает, когда ты пишешь универсальный код в стиле C++ vs универсальный код в стиле C
В первом случае компилятор знает размер типа на этапе компиляции, и поэтому может эффективно оптимизировать.
Во втором размер типа передаётся как параметр, что требует дополнительно пушить параметр в стек, неоптимально выполнять вычислительные действия с ним и так далее.
Здравствуйте, jazzer, Вы писали:
J>В общем, в сухом остатке, претензий к самой библиотеке у тебя нет
К многим её частям есть — overcomplicated и overengineered интерфейс, который тянет за собой множество проблем реализации.
J> есть претензии к конкретным реализациям
Имеются, верно.
Надо заметить что во многом реализации сделаны чтоб удовлетворять требованиям интерфейса. Кстати я допускаю что в этих рамках сделано максимально хорошо.
Но overall результат получается увы довольно средний.
Далеко ходить не надо, уже кстати обсасывали — стандартный std::sort ускоряется в несколько раз если научить его принимать tree way comparison operator вместо operator < (). И чем тяжелее компаратор — тем лучше это видно.
На том же самом алгоритме.
Выходит в угоду интерфейсу сделано намеренное ухудщение О характеристик алгоритма. Я кстати в той теме показал как можно было сделать sort внутри с 3-way а снаружи сделать стаб для less only.
J> и есть смутные подозрения, что подсунуть правильную реализацию, оставаясь в рамках интерфейса, будет трудно.
Не смутные, а так верно, да.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
.
