Войти
ПрограммированиеФорумОбщее

Отладчик Visual Studio (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
5:10, 3 мар. 2014

gammaker
>У меня похожая. Подробнее смотри в моём профиле.
Т.е. в итоге есть String + File + Tree, которые естественно не будут в широком доступе? =)


#16
13:14, 3 мар. 2014

FireFenix
> Т.е. в итоге есть String + File + Tree, которые естественно не будут в широком
> доступе? =)
Ну я могу выложить код, который не будет компилироваться из-за неудовлетворённых зависимостей. А то у меня всё завязано на движок, который целиком я не хочу выкладывать, а отвязывать тоже не хочу. Либо могу выложить старую версию того времени без зависимостей, но с незакрытыми багами и меньшим функционалом, чем у меня есть сейчас.

#17
19:35, 3 мар. 2014

gammaker
>не будет компилироваться из-за неудовлетворённых зависимостей.
А разве библиотека/фреймворк не должен быть автономный?

Ну и конечно интереснее версия потолще и поновее :)

#18
19:57, 3 мар. 2014

FireFenix
> А разве библиотека/фреймворк не должен быть автономный?
Я никогда не выделял строки и массивы как отдельную библиотеку. Они являются частью моего движка.
У меня во все cpp файлы неявно (в настройках компилятора) включается файл Core.h, который включает ещё кучу файлов, от которых зависят файлы String.h и Array.h. Зависимости такие: самописный assert, typedef unsigned int uint и подобные. Также математическая библиотека, в которой помимо используемых мной min, max и log2 (для менеджера памяти) ещё векторы и матрицы. Ещё есть компиляторо-специфичные дефайны и всё такое. И все эти файлы хитро раскиданы по папкам.

FireFenix
> Ну и конечно интереснее версия потолще и поновее :)
Если я её выложу, то я не буду выкладывать все зависимости и чистить. Я выложу только то, что относится к моим строкам и массивам, но компилироваться это код не будет. Более того, у меня вовсю используются фичи C++11, которые появились только в студии 2013. Но в открытых компиляторах (g++\clang) эти фичи уже есть достаточно давно.
Не уверен, что тебя заинтересует код, который не компилируется и который нельзя опробовать. Я бы сделал хотя бы exe'шник с тестом производительности, но у меня нет свободного времени, чтобы этим заняться, по крайней мере до ближайших выходных. Я уже давно не сравнивал производительность и самому интересно было бы посмотреть что изменилось с тех пор. В последний раз у меня была студия то ли 2008, то ли 2010, а сейчас 2013 и G++4.8.

#19
23:54, 3 мар. 2014

gammaker
>сейчас 2013 и G++4.8.
а я только под MSVC2013 сижу (ещё с беты, когда тангенс заворачивал в __vectorcall :D)

>typedef unsigned int uint и подобные
я тоже этим не брезгую, но сую такое дело в Forced include, чтоб само во весь прожект прокинуло.

>Я выложу только то, что относится к моим строкам и массивам, но компилироваться это код не будет
ну я как бы понял :)

>Не уверен, что тебя заинтересует код, который не компилируется и который нельзя опробовать
Как я уже говорил, я тож пишу "типа свой фреймворк", только сама большая проблема в организации, а не в кодинге ибо пишется с надеждой на кроссплатформенность (хотя бы линь - вин) :(


И вот ещё интересно:

  • Действительно ли перекрывает пожирание памяти профит кастомного аллокатора для форматирования строк?
  • И я так понимаю строки в utf-16? а как на счёт utf-8? =)
  • #20
    8:38, 4 мар. 2014

    FireFenix
    > __vectorcall
    А что это? Для векторизации кода что ли?

    FireFenix
    > я тоже этим не брезгую, но сую такое дело в Forced include, чтоб само во весь
    > прожект прокинуло.
    Ну и у меня force include, но помимо этого там всё, что я перечислил в предыдущем посте.


    FireFenix
    > кроссплатформенность (хотя бы линь - вин) :(
    Ну контейнерам ничего не мешает быть кроссплатформенными, если юзать только стандартные фичи CRT. Или ты про фреймворк в целом? Он у тебя вообще на какую тему? Графика?

    FireFenix
    > Действительно ли перекрывает пожирание памяти профит кастомного аллокатора для
    > форматирования строк?
    Строки выделяются практически моментально в большинстве случаев. В самом худшем случае, когда строки используются очень интенсивно, аллокатор не будет жрать больше 150 лишних КБ на всё приложение. Для больших строк (больше 4 кб) будет использоваться malloc, всё равно упираться всё будет в их обработку. Так что какое тут пожирание?

    FireFenix
    > И я так понимаю строки в utf-16? а как на счёт utf-8? =)
    Нет, utf-8 и есть. Правда не весь функционал будет работать корректно, если в строке есть не ASCII символы.
    Так что для обработки строк лучше использовать utf-32 строки, но у меня они пока не реализованы. Есть только возможность перевести string в array<char32>, но с ним работать неудобно. Я планирую сделать отдельный класс PodArray с счётчиком ссылок и переделать string, чтобы строки были на нём основаны. Ну типа как в языке D. Тогда будет проще добавить поддержку utf32 и utf16. Последний правда наверное не нужен, но пусть будет.
    Кстати, я обнаружил одну неэффективность в классе строк: даже пустые строки выделяют буфер на 16 байт. Но чтобы её исправить, придётся пройтись по всему коду строк и добавить везде проверку на null.

    #21
    3:23, 5 мар. 2014

    gammaker
    > А что это? Для векторизации кода что ли?
    Это долгая история, всё началось со своего тангенса, который знатно проигрывал тангенсу crt.
    И один из профитов crt было то, что вся логика вызова тангенса была кошерно впилена код, а у меня компилер генерил кучу перемещений по регистрам.
    И так вот __vectorcall это такая фишка, грубо говоря аналог __fastcall, когда все аргументы пробрасываются через регистры и всё это старается быть оптимизированным

    >Он у тебя вообще на какую тему? Графика?
    Это тоже отдельная история... Всё началось со своей математики и хейтерством макросов windows.h (особенно очень радуют коллизии имён и невозможность запихнуть всё это в отдельное пространство). В итоге прожект из набора контейнеров стал немного платформ-депендед и панеслась Изображение

    >Так что какое тут пожирание?
    Ну я до конца не осведомлён как у тебя всё реализоавнно... Но вот как я понял:

  • Появляется буфер строк и, при освобождении строки, в него заносится освобождённый буфер. Т.е. по сути имеем некоторый синглтон, который юзает конструктор и деструктор строк. Но т.к. код может быть поточный, то нужны крит секции или механизмы синхронизации -> если ты тестировал в одном потоке производительность, то в многопоточности она будет ниже.
  • Новые строки выделяются из "кеша буферов" только если есть буфер больше либо равного размера, что опять таки нужно иногда звать системные/сrt механизмы выделения памяти.
  • Если есть очень большой кусок (пару метров) и запрашивается буфер в 3 символа? Могу предположить, что более простой аллокатор и для 3х символов будет предоставлен толстый буфер.
  • И собсно в итоге - действительно ли кастомный аллокатор настолько профитный, что бы отказаться от дефолтных выделений памяти? При том, что в играх - строки обычно не место ботлнека
    По мне так кастомный аллокатор - лишний.

    Про память я не много не верно подумал, поэтому претензия не считается :)

    >Нет, utf-8 и есть.
    Я вот как раз на этом залип, ибо студия до конца не держит utf8 по стандарту C++11, где есть литерал u8.

    >Правда не весь функционал будет работать корректно, если в строке есть не ASCII символы.
    char* конструктор, где первые 128байт ASCII просто пробрасываются через 1 байт в utf8? :)

    >Так что для обработки строк лучше использовать utf-32
    Почему лучше? utf-8 заведомо linux-based + короче. У студии по дефолту utf-16. utf-32 то как?
    Размышляя про локали и прочую нашинал-депендед дребедень я таки пришёл, что лучше в utf-8 всё хранить - меньше мороки + меньше места - сложнее работать.

    #22
    11:09, 5 мар. 2014

    FireFenix
    > Это долгая история, всё началось со своего тангенса, который знатно проигрывал
    > тангенсу crt.
    А быстрого синуса у тебя нет случайно?

    FireFenix
    > При том, что в играх - строки обычно не место ботлнека
    > По мне так кастомный аллокатор - лишний.
    Выделение памяти - это вообще самое медленное из того, что может быть в строках. От аллокатора очень большой профит. Да и вообще он не мешает. Разве что тем, что не поддерживает многопоточность. Но когда я соберусь писать многопоточный код, я исправлю это.
    А игры тут особо ни при чём. Я хотел сделать быстрее, чем std::string и использовал все методы оптимизации для этого.

    В аллокаторе у меня есть пирамида буферов: размером от 16 до 64, от 64 до 256 и так до 4096. Чем больше размер буферов, тем меньше хранит их аллокатор: 50, 40, 30, 20 и 10 соответственно.

    FireFenix
    > Я вот как раз на этом залип, ибо студия до конца не держит utf8 по стандарту
    > C++11, где есть литерал u8
    Надо, чтобы исходники были в utf-8, тогда и все литералы будут в этой кодировке.

    FireFenix
    > char* конструктор, где первые 128байт ASCII просто пробрасываются через 1 байт
    > в utf8? :)
    Нет, литерал копируется как есть, ведь он уже в кодировке utf-8. По крайней мере предполагается, что оно так.

    FireFenix
    > Почему лучше? utf-8 заведомо linux-based + короче. У студии по дефолту utf-16.
    > utf-32 то как?
    Чтобы не было всяких последовательностей и суррогатных пар. Иначе такие строки даже перевернуть сложно. И нет произвольного доступа. А в utf32 символ имеет фиксированную длину и такие строки легко обрабатывать.

    #23
    8:11, 6 мар. 2014

    gammaker
    > А быстрого синуса у тебя нет случайно?
    вообще вопрос поставлен не корректно. В данном случае ещё нужно учитывать точность вычислений, платформу/железо и другие ресурсы.

    я забил на свою математику после того как узнал, что МС юзает (раньше юзало, сейчас не знаю) Intel asm либы, а так же код вшитый в crt с SSE2 оптимизацией на порядок быстрее, чем любые мои прошлые извращения. (Не ну решение в лоб через таблицу значений - кончено будет быстрее, только тут уже вопрос в памяти)
    Т.е. скорость работы прямо пропорциональна оптимизации более новых расширений.

    Знаю ещё Intel продвигает свои мат. либы, говорит, что они ещё быстрее и стоят денег :)

    gammaker
    >Надо, чтобы исходники были в utf-8, тогда и все литералы будут в этой кодировке.
    >Нет, литерал копируется как есть, ведь он уже в кодировке utf-8. По крайней мере предполагается, что оно так.
    Читер! :D
    Кстати, а в чём могут быть проблемы?

    >В аллокаторе у меня есть пирамида буферов: размером от 16 до 64, от 64 до 256 и так до 4096. Чем больше размер буферов, тем меньше хранит их аллокатор: 50, 40, 30, 20 и 10 соответственно.
    Т.е. ты делал буфера для строк которые живут только для того, чтобы вывести на печать?
    Т.е. если брать в общем случае, то профита не много? =)

    #24
    12:46, 6 мар. 2014

    FireFenix
    > Не ну решение в лоб через таблицу значений - кончено будет быстрее, только тут уже вопрос в памяти
    Решение в лоб через таблицу значений (особенно большую) будет самым медленным, если только не тестировать его в цикле на мильен итераций. А все потому, что операция доступа к некешированной памяти — одна из самых медленных на современных компьютерах (медленнее, чем честное вычисление синуса на fpu с точностью long double). Т. е., как только таблица вытесняется из кеша, начинаются проблемы. На практике неплохим вариантом является таблица на пару десятков значений с аппроксимацией сплайном 3-4 порядка, но это уже совсем не решение "в лоб".

    > Кстати, а в чём могут быть проблемы?
    В том, что студия при какой-то комбинации настроек может начать заниматься ненужными преобразованиями текстовых литералов (типа utf8->cp1251).

    #25
    13:35, 6 мар. 2014

    gammaker
    > А быстрого синуса у тебя нет случайно?
    http://www.gamedev.ru/code/forum/?id=93064

    > вообще вопрос поставлен не корректно. В данном случае ещё нужно учитывать точность вычислений, платформу/железо и другие ресурсы.
    Согласен.

    > Решение в лоб через таблицу значений (особенно большую) будет самым медленным
    Поэтому данный метод и не применяют. А если и применяют, то для научных расчетов. Где точность важна и не с double работают, а с большими числами.

    #26
    15:23, 6 мар. 2014

    FireFenix
    > вообще вопрос поставлен не корректно. В данном случае ещё нужно учитывать
    > точность вычислений, платформу/железо и другие ресурсы.
    Мне нужна точность около 0.001. Желательно, чтобы было быстрее стандартного на всех платформах и плюс ещё отдельно оптимизированные варианты для конкретных платформ.

    FireFenix
    > Кстати, а в чём могут быть проблемы?
    Проблемы чего? Что исходники не в той кодировке? Ну тогда все алгоритмы, которые трактуют эту строку как utf8 начнут сыпать после первого не ascii символа ошибочными символами. Причём они могут захватить и ascii символы, которые идут после не ascii.

    FireFenix
    > Т.е. ты делал буфера для строк которые живут только для того, чтобы вывести на
    > печать?
    > Т.е. если брать в общем случае, то профита не много? =)
    В смысле? Любое выделение памяти для строк происходит через этот аллокатор, а происходить оно может при их создании, конкатенации, форматировании и других алгоритмах.

    #27
    16:01, 6 мар. 2014

    gammaker
    > Мне нужна точность около 0.001.
    Откопал одну из реализаций с такой точностью:

    + Код

    > Причём они могут захватить и ascii символы, которые идут после не ascii.
    Не могут, если они нормально написаны.

    #28
    16:22, 6 мар. 2014

    }:+()___ [Smile]
    > Решение в лоб через таблицу значений (особенно большую) будет самым медленны
    Ну я же специально добавил
    >только тут уже вопрос в памяти
    :)

    > В том, что студия при какой-то комбинации настроек может начать заниматься ненужными преобразованиями текстовых литералов (типа utf8->cp1251).
    Чего?

    asvp
    > http://www.gamedev.ru/code/forum/?id=93064
    Я когда пилил свой тангенс, тоже заглядывал туда. И даже тест остался. :)

    gammaker
    >на всех платформах
    Это довольно сложно...

    >Желательно, чтобы было быстрее стандартного на всех платформах
    х86+SSE2: Не знаю как с точностью, но полином 26-24го порядка (COS0 и COS1), предложенный asvp, довольно отстаёт от crt'шного дабла, который в свою очередь догоняет 17го порядка.

    >В смысле? Любое выделение памяти для строк происходит через этот аллокатор, а происходить оно может при их создании, конкатенации, форматировании и других алгоритмах.
    Это понятно... Я к тому, что у тебя заточено под маложивущие строки в ограниченном количестве. И если рассматривать все ситуации, то профит сомнителен.

    #29
    16:24, 6 мар. 2014

    asvp
    > http://www.gamedev.ru/code/forum/?id=93064
    Мне уже давали эту ссылку. Я просто хочу накопить побольше вариантов, чтобы в выходных сразу всё протестировать, когда время свободное будет. Вообще это самый быстрый вариант, если не опускаться до ассемблера и векторизации? И кстати, мне нужно на всей числовой оси, а это значит, что понадобится ещё fmod. Он не будет тормозить?
    Вообще какой скорости можно добиться на 1.6 ГГц процессоре в одном потоке? У меня с math.h получается 5000000 в секунду, но хотелось бы раз в 5 побыстрее. Точности 0.0001 наверное хватит. И кстати, как вообще используют таблицы, если углы имеют тип float? Их же ведь придётся приводить к целым, умножая на некоторый коэффициент, и это наверное убьёт весь профит, если он вообще есть?

    Ну вообще я скатился в оффтоп с этими синусами. Я свою тему недавно создавал по этому поводу.

    Страницы: 1 2 3 4 5 Следующая »
    ПрограммированиеФорумОбщее

    Тема в архиве.