Сообщения на форуме пользователя Andrey (49 стр.)
Почему я никогда не буду использовать STL. | 7 июня 2010 | 21:33 | #329 |
---|
Xunter
>map вот обеспечивает поиск значения по ключу и вставку пары ключ-значение за логарифмическое время и предоставляет >доступ к парам в определенном >порядке. всё. а по-твоему если не для поиска по ключу, а для хранения - то зачем это вообще >надо "хранить"? и если на то пошло - то хранить лучше в массиве >пары - оверхед меньше, итерация по быстрее.
ты пост за постом умные вещи говоришь. Не надо фрагментировать память нодовыми контейнерами. сложили в массив далее std::sort. нужно искать std::lower_bound
Pushkoff
> все строки известны на этапе компиляции (мы их получаем из файла локализации)
> складываем их все одну за другой в буфер, в таблице индексов указываем смещения
> от начала буфера... в файл выгружаем сначала таблицу индексов, потом буфер со
> строками, загружаем аналогично...
Отличное решение! Не нужны динамические строки.
>map вот обеспечивает поиск значения по ключу и вставку пары ключ-значение за логарифмическое время и предоставляет >доступ к парам в определенном >порядке. всё. а по-твоему если не для поиска по ключу, а для хранения - то зачем это вообще >надо "хранить"? и если на то пошло - то хранить лучше в массиве >пары - оверхед меньше, итерация по быстрее.
ты пост за постом умные вещи говоришь. Не надо фрагментировать память нодовыми контейнерами. сложили в массив далее std::sort. нужно искать std::lower_bound
Pushkoff
> все строки известны на этапе компиляции (мы их получаем из файла локализации)
> складываем их все одну за другой в буфер, в таблице индексов указываем смещения
> от начала буфера... в файл выгружаем сначала таблицу индексов, потом буфер со
> строками, загружаем аналогично...
Отличное решение! Не нужны динамические строки.
Почему я никогда не буду использовать STL. | 4 июня 2010 | 16:34 | #212 |
---|
xDimka
> Изучая движки десятилетней давности можно бесконечно удивляться, как же все красиво и компактно написано. Но попробуйте туда прикрутить рендеринг или >физику в отдельном потоке, сделать шаг вправо или влево в использовании их контейнеров, и вы сразу все поймете, что код этот проще выкинуть и переписать на >STL. При этом он станет компактным, читаемым и понимаемым !миллионами! людей.
Движок так-же свалится со стандартным STL, где ты видел примитивы синхронизации или атомарные операции в стандартном STL ?
>Можно конечно до бесконечности проверять поинтеры на 0, перед тем как делать delete, или возвращаемые значения после new,
в Time Critical код это ни кто не делает, ставится assert и все отлавливается на этапе Debug сборке. В release версии все это считается ошибкой, в этом создается Crash Dump с Call Stack и отправляется отчет разработчикам.
>а можно открыть последние стандарты С++ и STL, прочитать книжку о которой я писал в посте 166, справочники к компиляторам и наконец понять, что мир уже не >такой как 10 лет назад.
мир такой-же как и раньше, а именно: лишние ветвления убивают предсказатель переходов, кэш промахи были всегда, проблемы нехватки памяти не должны проверять контейнеры, это должно быть сделано сверху. Требования за 10 лет увеличились, поэтому контейнеры лучше иметь специализированные.
Майерса читал, книга хоршая, на asm код подтверждает что конструкторы копий в STL это проблема...
> Изучая движки десятилетней давности можно бесконечно удивляться, как же все красиво и компактно написано. Но попробуйте туда прикрутить рендеринг или >физику в отдельном потоке, сделать шаг вправо или влево в использовании их контейнеров, и вы сразу все поймете, что код этот проще выкинуть и переписать на >STL. При этом он станет компактным, читаемым и понимаемым !миллионами! людей.
Движок так-же свалится со стандартным STL, где ты видел примитивы синхронизации или атомарные операции в стандартном STL ?
>Можно конечно до бесконечности проверять поинтеры на 0, перед тем как делать delete, или возвращаемые значения после new,
в Time Critical код это ни кто не делает, ставится assert и все отлавливается на этапе Debug сборке. В release версии все это считается ошибкой, в этом создается Crash Dump с Call Stack и отправляется отчет разработчикам.
>а можно открыть последние стандарты С++ и STL, прочитать книжку о которой я писал в посте 166, справочники к компиляторам и наконец понять, что мир уже не >такой как 10 лет назад.
мир такой-же как и раньше, а именно: лишние ветвления убивают предсказатель переходов, кэш промахи были всегда, проблемы нехватки памяти не должны проверять контейнеры, это должно быть сделано сверху. Требования за 10 лет увеличились, поэтому контейнеры лучше иметь специализированные.
Майерса читал, книга хоршая, на asm код подтверждает что конструкторы копий в STL это проблема...
Почему я никогда не буду использовать STL. | 4 июня 2010 | 15:22 | #209 |
---|
innuendo
>Z
> не стали делать "типовыми" решениями
> Еще не известно, что типовее тупого цикла.
>никогда не писал функцию где штук 5-6 таких циклов с поиском ?
Тут имеется ввиду, что может попробовать как-то входные данные упростить, поменять архитектуру, выбрать другие структуры данных, что-бы не было таких циклов подряд в коде.
> ну раз так - тогда и твой вопрос странный - они для того чтобы делать то что
> они делают
если я спросил то явно, не из-за того что не знаю что эти алгоритмы делают они внутри и как они устроены.
>Z
> не стали делать "типовыми" решениями
> Еще не известно, что типовее тупого цикла.
>никогда не писал функцию где штук 5-6 таких циклов с поиском ?
Тут имеется ввиду, что может попробовать как-то входные данные упростить, поменять архитектуру, выбрать другие структуры данных, что-бы не было таких циклов подряд в коде.
> ну раз так - тогда и твой вопрос странный - они для того чтобы делать то что
> они делают
если я спросил то явно, не из-за того что не знаю что эти алгоритмы делают они внутри и как они устроены.
Почему я никогда не буду использовать STL. | 4 июня 2010 | 15:18 | #207 |
---|
innuendo
> ты не разбирался что они делают ? :)
странный вопрос.
> ты не разбирался что они делают ? :)
странный вопрос.
Почему я никогда не буду использовать STL. | 4 июня 2010 | 15:06 | #203 |
---|
oistalker
> std::fill, std::replace_if, std::remove_if
зачем эти алгоритмы не пойму.
Z
> Из алгоритмов супер редко видел что-то различное от std::sort. Можно их и из
> STL заюзать кстати.
я бы добавил еще std::lower_bound/std::upper_down
std::for_each удобен иногда.
> std::fill, std::replace_if, std::remove_if
зачем эти алгоритмы не пойму.
Z
> Из алгоритмов супер редко видел что-то различное от std::sort. Можно их и из
> STL заюзать кстати.
я бы добавил еще std::lower_bound/std::upper_down
std::for_each удобен иногда.
Lua 5.2 work 3 | 3 июня 2010 | 17:22 | #1 |
---|
xDimka
я только Lua 5.2 work 2 внедрил, уже успели обновить. Смотрю популярность набирает.
я только Lua 5.2 work 2 внедрил, уже успели обновить. Смотрю популярность набирает.
Есть ль принципиальная разница между языками шейдеров? | 3 июня 2010 | 14:43 | #92 |
---|
arabesc
>таких потенциально неоптималных мест по программе массу найти можно, так что, их все на свой велосипед переписывать сразу надо?..
я просто послушал опытных - на установку констант говорят тратится время, зачем мне эти-же грабли?
>таких потенциально неоптималных мест по программе массу найти можно, так что, их все на свой велосипед переписывать сразу надо?..
я просто послушал опытных - на установку констант говорят тратится время, зачем мне эти-же грабли?
Почему я никогда не буду использовать STL. | 3 июня 2010 | 14:34 | #132 |
---|
Nikopol
> Потому что он написал код для абстрактного типа T.
> Мой тип Т кидает исключения в полный рост.
Вот тут что-то не понял... Где тут нужны исключения? и зачем они вообще нужны в time critical code, тем более расчет частиц на CPU.
можно подробнее. Тут речь наверняка специализированно контейнере идет.
тут вообще еще можно эти 2 мета пустой спецификацией исключений throw() расширить.
Pushkoff
> че-то давно не было видно [b]kas[/b]... помню он был ярым противником стл...
удалили его, поучительные посты были.
> Потому что он написал код для абстрактного типа T.
> Мой тип Т кидает исключения в полный рост.
Вот тут что-то не понял... Где тут нужны исключения? и зачем они вообще нужны в time critical code, тем более расчет частиц на CPU.
можно подробнее. Тут речь наверняка специализированно контейнере идет.
тут вообще еще можно эти 2 мета пустой спецификацией исключений throw() расширить.
Pushkoff
> че-то давно не было видно [b]kas[/b]... помню он был ярым противником стл...
удалили его, поучительные посты были.
Есть ль принципиальная разница между языками шейдеров? | 3 июня 2010 | 14:27 | #89 |
---|
arabesc
>там конечно есть проверка адреса на предмет строка это или хэндл, но если это ботлнек, то даже не знаю...
зачем это все лишнее?
handle эффекта это явно еще не регистр, так что вызовы IDirect3DDevice9::SetVertexShaderConstant*/ID3D10Device::VSSetConstantBuffers
явно быстрее эффекта.
>там конечно есть проверка адреса на предмет строка это или хэндл, но если это ботлнек, то даже не знаю...
зачем это все лишнее?
handle эффекта это явно еще не регистр, так что вызовы IDirect3DDevice9::SetVertexShaderConstant*/ID3D10Device::VSSetConstantBuffers
явно быстрее эффекта.
Есть ль принципиальная разница между языками шейдеров? | 3 июня 2010 | 13:07 | #82 |
---|
паравоз
> приведи плиз аргументы, чем они тебе не угодили.
внутри memcpy, проверка handle на предмет строки или указателя.
> приведи плиз аргументы, чем они тебе не угодили.
внутри memcpy, проверка handle на предмет строки или указателя.
Почему я никогда не буду использовать STL. | 3 июня 2010 | 13:03 | #115 |
---|
Nikopol
> Оно не exception-safe ни разу.
а зачем оно надо? Расскажи пожалуйста.
Alexander K
лишние ветвления не нужны, я бы так сделал:
> Оно не exception-safe ни разу.
а зачем оно надо? Расскажи пожалуйста.
Alexander K
лишние ветвления не нужны, я бы так сделал:
void add(const T &value) { assert(count < MAX && "Out Of Range"); values[count++] = value; } void remove(const int index) { assert(index > 0 && "Invalid Value"); assert(index < MAX && "Out Of Range"); assert(count > 0 && "Empty Array"); values[index] = values[--count]; }
Почему я никогда не буду использовать STL. | 3 июня 2010 | 11:58 | #92 |
---|
Alexander K
> Может и можно, но это либо будет жутко долго, либо потеряется порядок
> элементов, либо данные будут разбросаны по памяти.
Удаление будет быстрее чем в list, порядок элементов для твоей задачи наверняка не важен.
> Может и можно, но это либо будет жутко долго, либо потеряется порядок
> элементов, либо данные будут разбросаны по памяти.
Удаление будет быстрее чем в list, порядок элементов для твоей задачи наверняка не важен.
Почему я никогда не буду использовать STL. | 3 июня 2010 | 11:41 | #82 |
---|
Alexander K
>Уже не помню, из вектора же нельзя так просто удалить элемент по середине.
это кто такое сказал? еще как можно.
>std::vector<Particle*>
внутри каждая частица создавалась как Particle* p = new Particle ?
если так, у тебя зависимость по данным, отсюда кэш промахи, медленный доступ в память...
>Уже не помню, из вектора же нельзя так просто удалить элемент по середине.
это кто такое сказал? еще как можно.
>std::vector<Particle*>
внутри каждая частица создавалась как Particle* p = new Particle ?
если так, у тебя зависимость по данным, отсюда кэш промахи, медленный доступ в память...
Почему я никогда не буду использовать STL. | 2 июня 2010 | 15:22 | #26 |
---|
innuendo
>std::vector<ref<MyObject>>
наверное вылезут кэш промахи
>std::vector<ref<MyObject>>
наверное вылезут кэш промахи
Эффективный куллинг растительности. | 2 июня 2010 | 13:00 | #396 |
---|
innuendo
> worldSpace
да
> worldSpace
да