Здравствуйте, MTD, Вы писали:
_>>Угу, с зарезервированным перед этим размером. Причём если вылезаем за этот размер, то по задумке автора программа аварийно завершается. Это и есть в точности поведение вот такого решения: MTD>Да, именно этот кейс и тестировался. Я хотел показать, что даже на тривиальной операции можно немного отжать производительности. Интерфейс при этом хотел сохранить.
Интерфейс вектора в этой задаче просто не нужен. Так что это всё твои странные фантазии.
_>>Вот как раз этот твой код у меня стал работать практически одинаково MTD>Конечно нет. На маке ничего не изменилось, на вин10 произошли чудеса и разрыв между велосипедом и вектором усилился , на линуксе отставание вектора составило ~15%.
Ну а теперь смотри на реальность:
500028 us //std::vector с clear()
415023 us //std::vector с resize(0)
265015 us //твой Vector с exit(EXIT_FAILURE);
417023 us //твой Vector с slow_push_back
236013 us //для сравнения мой вариант с data=make_unique<T[]>(n);
Это данные с моей системы. И если ты используешь у себя слабые опции оптимизации или дохлые процессоры (судя по абсолютным цифрам), то это не значит что у всех так.
_>>(с одной небольшой поправкой, которую смотри в том сообщение). MTD>Я специально не давал компилятору никаких рекомендаций относительно инлайна.
Это был речь не про инлайн, а про clear->resize.
_>>Так что никаких чудес нет. MTD>Именно.
Угу, есть только применение ненужного кода в ненужном месте и странные выводы из этого потом.
Здравствуйте, Nikе, Вы писали:
N>Вот я сейчас теста ради запустил начисто в консоли и получил:
Я тебе конечно верю — но не вижу ни платформы, ни компилятора, ни настроек компилятора.
MTD>>10 лет в IT — это вечность. Это же каким ленивым надо быть, чтобы на 10 лет не следить за тем, что происходит в языке которым ты зарабатываешь N>Так получилось, что я довольно давно подрос и перестал интересоваться он..змом, начав заниматься более сложными и полезными вещами. Пока мне инструмента хватает — я не буду улучшать свои знания по нему, т.к. есть много другого для изучения. Тем более, что изучение вот этих вот конкретных нюансов вообще практически бесмысленно.
Это все говорит только о твоем уровне как разработчика. Успешно тебе дотянуть до пенсии, удачи!
MTD>>Пока, что болтуном показал себя ты. Насчет на порядок я написал для красоты, но 8х — вполне. С тобой могу заключить пари, тысяч на 50 рублей, например. После этого покажу код с SSE делающий код без SSE на озвученную мной величину. N>Я на этот бред не подписываюсь.
Здравствуйте, MTD, Вы писали:
NB>>это результат выполнения твоего кода без изменения. NB>>как можно заметить, тормозит не STL.
MTD>Ты же вызовы местами поменял.
Судя по ассемблеру это не так. Кроме того, я протестировал на мак, линукс и вин10 результат не совпадает с твоим. Чисто логически ты можешь сказать за счет чего бы стал тормозить код? И как код в цикле делающий call может оказаться быстрей без такового?
Здравствуйте, MTD, Вы писали:
N>>Вот я сейчас теста ради запустил начисто в консоли и получил:
MTD>Я тебе конечно верю — но не вижу ни платформы, ни компилятора, ни настроек компилятора.
/OUT:"TestVec.exe" /MANIFEST /NXCOMPAT /PDB:"TestVec.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG /MACHINE:X64 /OPT:REF /INCREMENTAL:NO /PGD:"TestVec.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\TestVec.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
N>>Так получилось, что я довольно давно подрос и перестал интересоваться он..змом, начав заниматься более сложными и полезными вещами. Пока мне инструмента хватает — я не буду улучшать свои знания по нему, т.к. есть много другого для изучения. Тем более, что изучение вот этих вот конкретных нюансов вообще практически бесмысленно.
MTD>Это все говорит только о твоем уровне как разработчика.
Судя по прайсам и популярности — отличный уровень. Как раз потому, что я дело делаю. Высокоуровневая оптимизация она не только в программах работает, но и в бизнесе.
MTD>Успешно тебе дотянуть до пенсии, удачи!
Пик развития нормального инженера — 55 лет, до
MTD>>>Пока, что болтуном показал себя ты. Насчет на порядок я написал для красоты, но 8х — вполне. С тобой могу заключить пари, тысяч на 50 рублей, например. После этого покажу код с SSE делающий код без SSE на озвученную мной величину. N>>Я на этот бред не подписываюсь.
MTD>И снова слился. Ну ок.
Так ты ж слился. Я тут недавно, кстати, в одном облачном сервисе десятикратные приросты производительности обеспечил переведя "оптимизированный" С код на С++ и затем улучшив алгоритмическую часть.
кода у меня на машине. NB>>что не понятно?
MTD>Судя по ассемблеру это не так. Кроме того, я протестировал на мак, линукс и вин10 результат не совпадает с твоим. Чисто логически ты можешь сказать за счет чего бы стал тормозить код? И как код в цикле делающий call может оказаться быстрей без такового?
ну понятно. "у меня все работает" (с)
чисто логически, размер заинлайненой функции увеличился. как это отразилось на работе проца -- вопрос не по адресу, т.к. я не позиционировал себя как мастера каких-то там оптимизаций.
Здравствуйте, MTD, Вы писали:
MTD>Да, именно этот кейс и тестировался. Я хотел показать, что даже на тривиальной операции можно немного отжать производительности. Интерфейс при этом хотел сохранить.
Не показал.
Кроме того — нормальный подход это разрабатывать всё с использованием стандартных средств, с минимумом велосипедов, и (достигается некоторой практикой) без преждевременной пессимизации. После возникновения критических тормозов (что относительно редкое явление) — улучшается алгоритмическая часть. И так несколько раз. И только затем, в случае объективных проблем критичных для бизнеса — начинается подобное задротство.
Здравствуйте, Nikе, Вы писали:
MTD>>Да, именно этот кейс и тестировался. Я хотел показать, что даже на тривиальной операции можно немного отжать производительности. Интерфейс при этом хотел сохранить. N>Не показал.
Показал.
N>Кроме того — нормальный подход это разрабатывать всё с использованием стандартных средств, с минимумом велосипедов, и (достигается некоторой практикой) без преждевременной пессимизации. После возникновения критических тормозов (что относительно редкое явление) — улучшается алгоритмическая часть. И так несколько раз. И только затем, в случае объективных проблем критичных для бизнеса — начинается подобное задротство.
Кто бы мог подумать? Еще капитанство будет, типа 2+2=4? Я уже в этой ветке писал, что есть оптимизации стратегические, где выигрыш может достигать порядка и более и тактические, типа того, что я показал, там выжать можно в лучшем случае 2-3х. Очевидно опускаться на низкий уровень нужно в крайнем случае, иначе овчинка будет не стоить выделки.
Здравствуйте, alex_public, Вы писали:
_>Интерфейс вектора в этой задаче просто не нужен. Так что это всё твои странные фантазии.
Почему не нужен? А может как раз нужен. Гипотетически — есть код написанный с вектором, алгоритмически все оптимизировали, надо выжать еще процентов 20. Меняем вектор на свой — профит.
MTD>>Конечно нет. На маке ничего не изменилось, на вин10 произошли чудеса и разрыв между велосипедом и вектором усилился , на линуксе отставание вектора составило ~15%.
_>Ну а теперь смотри на реальность:
Я уже посмотрел.
_>500028 us //std::vector с clear() _>415023 us //std::vector с resize(0)
Можешь объяснить разницу? Давай без подколок, реально интересно.
Здравствуйте, night beast, Вы писали:
NB>ну понятно. "у меня все работает" (с)
Твоя позиция понятна, а мне разобраться интересно.
NB>чисто логически, размер заинлайненой функции увеличился. как это отразилось на работе проца -- вопрос не по адресу, т.к. я не позиционировал себя как мастера каких-то там оптимизаций.
У тебя выключена Whole program optimization (/GL). Что любопытно, если ее выключить std::vector работает быстрее чуть ли не вдвое (к вопросу об stl в time critical ), поведение велосипеда не меняется. Впрочем отрыв велосипеда все равно есть, процентов 15.
MTD>>Это все говорит только о твоем уровне как разработчика. N>Судя по прайсам и популярности — отличный уровень.
Пока что это только с твоих слов, а мы уже выяснили, что особо доверять твоим словам оснований нет.
MTD>>Успешно тебе дотянуть до пенсии, удачи!
N>Пик развития нормального инженера — 55 лет, до
Немного осталось, поднажми.
MTD>>И снова слился. Ну ок. N>Так ты ж слился.
Здравствуйте, MTD, Вы писали:
MTD>>>Да, именно этот кейс и тестировался. Я хотел показать, что даже на тривиальной операции можно немного отжать производительности. Интерфейс при этом хотел сохранить. N>>Не показал.
MTD>Показал.
Есть такие штуки — цифры называются. Вот их мнение о результатах — важнее твоего.
MTD>Кто бы мог подумать? Еще капитанство будет, типа 2+2=4? Я уже в этой ветке писал, что есть оптимизации стратегические, где выигрыш может достигать порядка и более и тактические, типа того, что я показал, там выжать можно в лучшем случае 2-3х. Очевидно опускаться на низкий уровень нужно в крайнем случае, иначе овчинка будет не стоить выделки.
Тебе говорили, что в большинстве случаев желание перейти со стандартных средств на нестандартные, и я уже молчу про убогий С — мотивируются низкой компетенцией. Что тебе хорошо показал alex_public.
Здравствуйте, MTD, Вы писали:
N>>Win10, Intel i7-6700HQ, 16 гигов. N>>VS 2015: N>>/GS /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /Fd"x64\Release\vc140.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\TestVec.pch"
MTD>У тебя выключена Whole program optimization (/GL). Что любопытно, если ее выключить std::vector работает быстрее чуть ли не вдвое (к вопросу об stl в time critical ), поведение велосипеда не меняется. Впрочем отрыв велосипеда все равно есть, процентов 15.
Цифры против, я их привёл. Я уже говорил, что в подобных оптимизациях, по мимо их адской прямой и отложенной дороговизны — очень сильно влияние оползней на Луне.
MTD>Ага, а черное — это белое.
Ты ляпнул провокационное заявление, противоречащее архитектуре проца и всем основным бенчмаркам, тестам и практике. Никак его не обосновал -> гонишь.
Здравствуйте, Nikе, Вы писали:
N>Но таки это ты просился ко мне на работу, а не я к тебе.
Я к тебе не просился, просто сказал, что за озвученную сумму готов общаться. Но предмета для разговора очевидно нет, так как ни озвученных сум у тебя нет, да и сам ты подобных вопросов обсуждать не можешь.
Здравствуйте, Nikе, Вы писали:
MTD>>У тебя выключена Whole program optimization (/GL). Что любопытно, если ее выключить std::vector работает быстрее чуть ли не вдвое (к вопросу об stl в time critical ), поведение велосипеда не меняется. Впрочем отрыв велосипеда все равно есть, процентов 15. N>Цифры против, я их привёл.
Это неправда. Я проверил на той же оси, компиляторе и настройках, только процессор i5, а не i7.
N>Я уже говорил, что в подобных оптимизациях, по мимо их адской прямой и отложенной дороговизны — очень сильно влияние оползней на Луне.
Это потому, что ты процессов не понимаешь, поэтому для тебя это магия.
N>Ты ляпнул провокационное заявление, противоречащее архитектуре проца и всем основным бенчмаркам, тестам и практике. Никак его не обосновал -> гонишь.
Я тебе предложил подтвердить свои слова, а заодно подучить тебя, но разумеется не бесплатно — ты моментально слился.
, на линуксе отставание вектора составило ~15%.
