Здравствуйте, Andrew S, Вы писали:
R>>>>з.ы. а мерить среднее время всё-таки некорректно, если ты запустишь тест несколько раз, то увидишь, что время "плавает", т.е. сказываются третьи факторы, с минимальным временем такого нет.
AS>>>Поэтому и надо ставить приоритет реалтайм и привязывать к одном процессору, как тут уже говорили. Еще и рабочую область неплохо бы закоммитить.
R>>Если мерить длинный интервал и запускать функцию _один_ раз, то да. В моём случае всё это учтено, поэтому ничего этого не надо — это никак не повлияет на результат.
AS>Ладно, ладно, мы все тупые, а ты один умный. Делай как знаешь
Сейчас сколько бы раз я не запускал тест у меня получается, допустим 172.
Т.е. ты хочешь сказать, если я запущу свой тест на своей машине с привязкой к ядру, с установкой максимального приоритета, коммитом памяти и т.д., у меня выдастся другое число?
Здравствуйте, remark, Вы писали:
R>Что я понял уже когда я это всё доделал, что надо было код не кустарным способом делать, а сделать генератор кода, которому задаёшь параметр — кол-во "ресурсов, кол-во уровней вызовов и т.д. и что бы он генерировал много красивого кода. И снабдить это ещё скриптами для автоматической сборки и что бы результаты выводились сразу в виде красивых табличек. Тогда бы я это выложил и все желающие запускали бы это на своих платформах и потом выкладывали бы сюда свои результаты... тогда и для ARM'ов бы можно было протестировать и более точно проследить зависимости скорости/размера кода от различных параметров типа кол-ва "ресурсов".
R>К сожалению это не ко мне. Может руки дойдут это оформить в виде набора файлов, который можно запустить на своей платформе и выложить результаты...
Ну ты, например, можешь выложить то, что есть, а руки могут дойти у кого-то ещё
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
R>>>>>з.ы. а мерить среднее время всё-таки некорректно, если ты запустишь тест несколько раз, то увидишь, что время "плавает", т.е. сказываются третьи факторы, с минимальным временем такого нет.
AS>>>>Поэтому и надо ставить приоритет реалтайм и привязывать к одном процессору, как тут уже говорили. Еще и рабочую область неплохо бы закоммитить.
R>>>Если мерить длинный интервал и запускать функцию _один_ раз, то да. В моём случае всё это учтено, поэтому ничего этого не надо — это никак не повлияет на результат.
AS>>Ладно, ладно, мы все тупые, а ты один умный. Делай как знаешь
R>Сейчас сколько бы раз я не запускал тест у меня получается, допустим 172. R>Т.е. ты хочешь сказать, если я запущу свой тест на своей машине с привязкой к ядру, с установкой максимального приоритета, коммитом памяти и т.д., у меня выдастся другое число?
Вполне вероятно. Особенно если ты увеличишь количество итераций. Привязка к ядру — но ты же не только на своей машине планируешь запускать тест, ведь так?
Здравствуйте, Andrew S, Вы писали:
AS>>>А можете привести листинги для функций? Вдруг ic там что проинлайнил? Он может.... CC>>если указывать __declspec(noinline) — то не будет гарантировано. CC>>Впрочем вот:
AS>Cудя по коду для rv, icc убрал вызовы ctor и dtor. Мы договорились этого не делать
Увы, заставить его не убирать совершенно пустые функции не получается... Щас проведу эксперимент — добавлю _asm nop в них
AS>>>>А можете привести листинги для функций? Вдруг ic там что проинлайнил? Он может.... CC>>>если указывать __declspec(noinline) — то не будет гарантировано. CC>>>Впрочем вот:
AS>>Cудя по коду для rv, icc убрал вызовы ctor и dtor. Мы договорились этого не делать CC>Увы, заставить его не убирать совершенно пустые функции не получается... Щас проведу эксперимент — добавлю _asm nop в них
Используй тот код, что приводил я (c init\release). В этом случае не должно убрать — если только линкер не оптимизирует.
Здравствуйте, Andrew S, Вы писали:
AS>>>>>А можете привести листинги для функций? Вдруг ic там что проинлайнил? Он может.... CC>>>>если указывать __declspec(noinline) — то не будет гарантировано. CC>>>>Впрочем вот:
AS>>>Cудя по коду для rv, icc убрал вызовы ctor и dtor. Мы договорились этого не делать CC>>Увы, заставить его не убирать совершенно пустые функции не получается... Щас проведу эксперимент — добавлю _asm nop в них
AS>Используй тот код, что приводил я (c init\release). В этом случае не должно убрать — если только линкер не оптимизирует.
Кинь ссылкой плз, бо в этом топике уже черт ногу сломит.
Скомпилил с nop-ами — получилось одинаково у обоих — 182
AS>>Используй тот код, что приводил я (c init\release). В этом случае не должно убрать — если только линкер не оптимизирует. CC>Кинь ссылкой плз, бо в этом топике уже черт ногу сломит.
AS>>Ладно, ладно, мы все тупые, а ты один умный. Делай как знаешь
M>Должен заметить, что полезную информацию дал пока что только Ремарк. От вас , кроме НЕконструктивной критики пока не было ничего.
А от вас пока ничего, кроме флуда (хотя нет, была ссылка на статью про книгу криса касперски, и то не по адресу). Есть что по делу то сказать?
Здравствуйте, Andrew S, Вы писали:
AS>>>Используй тот код, что приводил я (c init\release). В этом случае не должно убрать — если только линкер не оптимизирует. CC>>Кинь ссылкой плз, бо в этом топике уже черт ногу сломит.
AS>http://www.rsdn.ru/Forum/Message.aspx?mid=2430252&only=1
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, <Аноним>, Вы писали:
А>>1 — передача адреса без чтония памяти. la заместо mov
GN>Имеется ввиду команда lea? Не пойму, как она может быть лучше.
А>>2 — Может E(ABCD)X кончильсь, а указатели остались.
GN>Указатели, как и данные, могут храниться в любом регистре.
Хранение данных в индексных регистрах несколько ограничивает возможные операции, хоть бывает это оправдано. Насчет lea я имел ввиду случай когда можно получить адрес а переменная прямо сейчас не понадобится или например может вообще не понадобится в зависимости от условий. Lea использует например this, который в регистре и константный офсет а реального чтения не происходит изза значений флагов.
В приведенных кодах некоторое сомнение вызывает сочетание __declspec и __fastcall
Кстати тут недавно кто-то volatile использовал для борьбы с компилятором
Re[5]: [Investigation] Exceptions vs. Return Values
Здравствуйте, Programador, Вы писали:
P>В приведенных кодах некоторое сомнение вызывает сочетание __declspec и __fastcall
Чем?
__declspec(noinline) запрещает компилеру инлайнинг данной функции
__fastcall грит компилеру чтоб старался передавать параметры через регистры
все для чего это тут надо — чтоб компилер не выкидывал пустые функции а тратил на их вызов тики
Здравствуйте, Andrew S, Вы писали:
R>>Сейчас сколько бы раз я не запускал тест у меня получается, допустим 172. R>>Т.е. ты хочешь сказать, если я запущу свой тест на своей машине с привязкой к ядру, с установкой максимального приоритета, коммитом памяти и т.д., у меня выдастся другое число?
AS>Вполне вероятно. Особенно если ты увеличишь количество итераций.
Интересно за счёт чего? И ты ещё говорил о компетентности
AS>Привязка к ядру — но ты же не только на своей машине планируешь запускать тест, ведь так?
При чём тут, что я планирую. Я запускал на однопроцессорной машине. Если я запланирую запускать ещё где-то, то тогда я возможно запланирую и изменить методику измерения, если это будет нужно.
R>>>Сейчас сколько бы раз я не запускал тест у меня получается, допустим 172. R>>>Т.е. ты хочешь сказать, если я запущу свой тест на своей машине с привязкой к ядру, с установкой максимального приоритета, коммитом памяти и т.д., у меня выдастся другое число?
AS>>Вполне вероятно. Особенно если ты увеличишь количество итераций.
R>Интересно за счёт чего? И ты ещё говорил о компетентности
За счет того, что шедуллер будет выделять больше времени твоему потоку. Или ты думаешь, в системе один поток и он твой?
Это во-первых. А во-вторых, о компетентности прямо я не говорил (хотя и советовал тебе ознакомиться хотя бы со статьей, приведенной в топике), но теперь могу наверное и начать
AS>>Привязка к ядру — но ты же не только на своей машине планируешь запускать тест, ведь так?
R>При чём тут, что я планирую. Я запускал на однопроцессорной машине. Если я запланирую запускать ещё где-то, то тогда я возможно запланирую и изменить методику измерения, если это будет нужно.
Ууу.. все ясно. Ок, уговорил — больше в таком "интересном" варианте мне общаться не хочется. Конструктива с твоей стороны я не вижу, хотя привел уже несколько ошибок в твоем тесте, ты, похоже, считаешь, что все в порядке. На критику ты реагируешь тоже весьма "интересно". В общем, желаю удачи и доработать тесты хотя бы до вменяемого состояния
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Programador, Вы писали:
P>>В приведенных кодах некоторое сомнение вызывает сочетание __declspec и __fastcall CC>Чем? CC>__declspec(noinline) запрещает компилеру инлайнинг данной функции CC>__fastcall грит компилеру чтоб старался передавать параметры через регистры
CC>все для чего это тут надо — чтоб компилер не выкидывал пустые функции а тратил на их вызов тики
там был импортный __declspec и у него баг случился — при оптимизации параметры в стек засунулись, а не в регистры.
У меня такое отношение что __fastcall это типа инлайне. Хотя в принципе экспорт можно подружить с инлайне путем дублирования кода
Re[7]: [Investigation] Exceptions vs. Return Values
P>У меня такое отношение что __fastcall это типа инлайне. Хотя в принципе экспорт можно подружить с инлайне путем дублирования кода
Отчего ж? Из кернела экспортируются функции с конвенцией fastcall — и ничего, все работает Фасткалл — это конвенция вызова и ничего более — к экспорту\импорту она не должна иметь отношения, кроме как для манглинга...
Здравствуйте, Programador, Вы писали:
P>Хранение данных в индексных регистрах несколько ограничивает возможные операции, хоть бывает это оправдано.
В x86-32 нет индексных регистров, все равноправны.
P>Насчет lea я имел ввиду случай когда можно получить адрес а переменная прямо сейчас не понадобится или например может вообще не понадобится в зависимости от условий. Lea использует например this, который в регистре и константный офсет а реального чтения не происходит изза значений флагов.
Если чтения нет — компилятор не справился с оптимизацией, сгенерировав лишние команды. Если чтение есть — нет разницы в скорости.
Компилятор для ссылки довольно часто может обойтись вообще compile-time вычислениями, не генерируя код, но делает так не всегда.
P>В приведенных кодах некоторое сомнение вызывает сочетание __declspec и __fastcall
Это правильно, поскольку функция экспортируется именно так.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[5]: [Investigation] Exceptions vs. Return Values
Здравствуйте, remark, Вы писали:
R>Ну под дебагом-то что код смотреть?
Баги кодогенератора проявились в дебаге, в релизе просто повезло в конкретном случае.
R>Ты приведи пример, где под релизом так.
На коде небольшого размера не получается воспроизвести, а оставить как есть в продакшене и потом ждать багрепорты об ошибке 2го порядка довольно накладно.
R>В msvc помогает "добить" такие места, где не идельная оптимизация, включение link-time code generation — он как раз вот такие "форварды" должен элиминировать.
Я проводил довольно простой тест — сначала заинклудил все cpp в основной и скомпелировал, потом компелировал по-раздельности и линковал с /LTCG — в последнем случае код хуже.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[5]: [Investigation] Exceptions vs. Return Values
Здравствуйте, remark, Вы писали:
R>Ну так исключение всё равно может полететь, и деструкторы есть, значит фрейм всё равно надо устанавливать.
Тем более, эти результаты неверны, это уже с++/rv+ex какой-то.
R>>>А код С++ компилятор даже лучше генерирует — поскольку деструкторы не вызываются явно у него есть некая свобода в оптимизации.
GN>>Не верю Компилятор там один и тот же.
R>В С — там код более явный, поэтому у компилятора меньше свободы, а в С++ менее явный — и у компилятора больше свободы.
Интересная теория, я всегда считал что С и С++ перед оптимизацией трансформируется в одно и тоже ADT.
R>Я глядел сгенерированный код "с++/rv" — я там даже сразу не понял, что он там к чему нагенерил — там он как-то хитро пишет прям в стек, т.е. не push/pop, а mov [sp],x и всякого такого рода вещи.
При оптимизации по скорости так происходит довольно часто.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[6]: [Investigation] Exceptions vs. Return Values
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Programador, Вы писали:
P>>Хранение данных в индексных регистрах несколько ограничивает возможные операции, хоть бывает это оправдано.
GN>В x86-32 нет индексных регистров, все равноправны.
Равноправны 2 регистра FS и GS это совсем не все
P>>Насчет lea я имел ввиду случай когда можно получить адрес а переменная прямо сейчас не понадобится или например может вообще не понадобится в зависимости от условий. Lea использует например this, который в регистре и константный офсет а реального чтения не происходит изза значений флагов.
GN>Если чтения нет — компилятор не справился с оптимизацией, сгенерировав лишние команды. Если чтение есть — нет разницы в скорости.
GN>Компилятор для ссылки довольно часто может обойтись вообще compile-time вычислениями, не генерируя код, но делает так не всегда.
Я про рунтайм условия. Мы загружаем адрес, а память возможно не читаем, засчет этого ссылка на инт может быть быстрее
