- the trick
- Постоялец
PANDA
Т.е. если бы он сказал "я вообще как бы разбираюсь в ассемблере и могу сказать что его компилятор VB6 неплохо
работает, учитывая специфику и ориентированность языка", то твоих придирок бы не было? Лол.
PANDA
> Тут даже о тестах речи не было.
Хм... Это видимо у тебя проблемы с логикой. Раз я смотрел как работает тот или иной код видимо я делал это для изучения его работы, или по твоему зачем?
PANDA
> И у кого тут проблемы с логикой?
Пока что у тебя. Это проявляется в том, что я ясно написал что исследовал множество программ и писал несколько тестов, но ты уперто продолжаешь писать про какой-то 1 тест.
PANDA
> да-да-да, именно поэтому АРМ процессоры такие же быстрые при тех же частотах,
> как и интелловские, да? Тупые инженеры интела понапихали ненужного хлама в
> проц, чтобы он грелся. Кому нужен этот бранч предикшен, когда есть целерон, да
> Тарас?
Я вообще не понял, что ты хочешь сказать. Причём тут ненужный хлам в проце? Ты о чём, парень?
TarasB
Я тоже не сразу понял. Он хочет сказать что раз в интеле столько ядер и столько всяких инструкций, то всеми ими надо пользоваться, иначе они как бы жрут энергию зря.
Некоторые лохи даже встроенный в интелы видеоускоритель не используют, по старинке на цпу считают.
kipar
Ну я и говорю, это даёт не так много прироста.
TarasB
kipar
Я не о том. Я говорю о том, что эта, как сказал Тарас, "магия" дает прирост в несколько раз, и именно ее развивают последние 10-15 лет, а АРМ как раз остался на уровне третьего пня. Поэтому какой-нибудь ассемблерный гуру из 90-х может легко ошибаться по поводу производительности некоторого кода, т.к. не учитывает бранч-предикшн и out-of-order, а также другие нюансы пайплайна. Компайлеры в этом плане знают больше, и в 90% случаев сегодня в дураках именно программист, а не компайлер. Но откуда Тарасу что-либо знать по этому поводу с его целероном.
kipar
> Т.е. если бы он сказал "я вообще как бы разбираюсь в ассемблере и могу сказать
> что его компилятор VB6 неплохо
> работает, учитывая специфику и ориентированность языка", то твоих придирок бы
> не было? Лол.
Во всяком случае, это бы звучало убедительнее и не так смешно, как оригинал. Но вопросы по "разбираюсь" возникли бы, конечно.
the trick
> Раз я смотрел как работает тот или иной код видимо я делал это для изучения его
> работы, или по твоему зачем?
И? Смотреть "как работает" достаточно, чтобы оценить производительность и оценить компайлер? По фразе "заглядывал в дизасм" я должен был точно понять, что ты проводил сравнительные тесты производительности? Ты вообще программист? Как с такой логикой можно работать?
the trick
> Это проявляется в том, что я ясно написал что исследовал множество программ и
> писал несколько тестов, но ты уперто продолжаешь писать про какой-то 1 тест.
Твои тесты ничего не стоят (судя по твоим описаниям), хоть там 1, хоть 10. Чтобы нормально протестировать и получить какой-то результат, надо во-первых иметь несколько поколений процов от разных производителей, несколько компайлеров с разными настройками оптимизации. Собственно тестовые наборы, где помимо синтетических тестов должны быть реальные программы (пусть и небольшие), а не только число-дробилки. Ты что-то подобное делал? Я очень сомневаюсь.
PANDA
> Компайлеры в этом плане знают больше, и в 90% случаев сегодня в дураках именно
> программист, а не компайлер.
Это надо к Царю с говнокода. Он много примеров писал, того какая даже в последнем gcc питушня и как можно на штеуде ускорить вещи типа сложения чисел или копирования памяти, если не думать "компилятор умный, он разбирается в современных процессорах лучше".
А, вот про сложение: http://www.linux.org.ru/forum/development/10452829
Хотя это оффтоп слегка.
PANDA
> Смотреть "как работает" достаточно, чтобы оценить производительность и оценить
> компайлер?
Да. Имея в наличии несколько компиляторов и сравнивая код и время работы кода можно делать выводы о производительности.
PANDA
> По фразе "заглядывал в дизасм" я должен был точно понять, что ты проводил
> сравнительные тесты производительности? Ты вообще программист? Как с такой
> логикой можно работать?
У меня складывается такое впечатление что ты с какой-то другой планеты. Если я написал что VB6 неплохой компилятор, то естественно я не с балды это взял, а этот вывод сделан на основании многих таких исследований. Кроме C++ я также сравнивал и с другими ЯП, например с PureBasic, ссылка где-то тут раньше была на предыдущих страницах.
PANDA
> Твои тесты ничего не стоят (судя по твоим описаниям), хоть там 1, хоть 10.
> Чтобы нормально протестировать и получить какой-то результат, надо во-первых
> иметь несколько поколений процов от разных производителей, несколько
> компайлеров с разными настройками оптимизации. Собственно тестовые наборы, где
> помимо синтетических тестов должны быть реальные программы (пусть и небольшие),
> а не только число-дробилки. Ты что-то подобное делал? Я очень сомневаюсь.
Не стоят твои пустые высказывания, которые ничего конкретного так и не показывают - не опровергают убогость COM, и убогость VB6 компилятора.
Я тестил на реальных задачах, короче я не буду это уже в сотый раз писать. Тут даже раньше ссылки на тест словаря были.
kipar
> Это надо к Царю с говнокода. Он много примеров писал, того какая даже в
> последнем gcc питушня и как можно на штеуде ускорить вещи типа сложения чисел
> или копирования памяти, если не думать "компилятор умный, он разбирается в
> современных процессорах лучше".
> А, вот про сложение: http://www.linux.org.ru/forum/development/10452829
Ну ты не перекручивай, я же написал про 90%. Я уверен, что наш мастер оценки кода на глаз относится именно к ним.
the trick
> Да. Имея в наличии несколько компиляторов и сравнивая код и время работы кода
> можно делать выводы о производительности.
Стоп, в оригинале было просто:
>Я очень часто работаю в отладчике и много видел кодов (инструкций) программ на VB6 и на других языках
Про свои замеры ты уже позже запел.
the trick
> Если я написал что VB6 неплохой компилятор, то естественно я не с балды это
> взял, а этот вывод сделан на основании многих таких исследований.
почему это? Мало ли кто и что сказал, важна аргументация.
the trick
> Не стоят твои пустые высказывания, которые ничего конкретного так и не
> показывают - не опровергают убогость COM, и убогость VB6 компилятора.
> Я тестил на реальных задачах, короче я не буду это уже в сотый раз писать. Тут
> даже раньше ссылки на тест словаря были.
Ладно, наверное, это я плохо изъясняюсь. Прошу прощения, если так.
Мой поинт:
Не компилятор плох (плох ли он, я не знаю, в глаза его не видел), а твое определение качества компилятора по заглядыванию в дебаггер и твои чудо-тесты.
Почему твое тесты - говно, я вот тебе и написал.
PANDA
> Про свои замеры ты уже позже запел.
Это получается что я так выразился?
> Я очень часто работаю в отладчике и много видел кодов (инструкций) программ на
> VB6 и на других языках, но я просто смотрел инструкции и закрывал отладчик не смотря что код делает и как работает?
Ты не видишь что это глупо?
PANDA
> почему это? Мало ли кто и что сказал, важна аргументация.
Короче это как разговор со стеной, я не вижу смысла дальше что-то обсуждать.
PANDA
> Не компилятор плох (плох ли он, я не знаю, в глаза его не видел), а твое
> определение качества компилятора по заглядыванию в дебаггер и твои чудо-тесты.
Господи, это ересь. Как определить качество компилятора по твоему? Получается что для этого не нужно знать листинг и проводить сравнительные тесты. По-моему ты бредишь.
PANDA
> Почему твое тесты - говно, я вот тебе и написал.
Ничего вразумительного не видел.
kipar
Дочитал до конца пост на лоре: ну окей, а теперь мы это "оптимизированное" чудо запускаем на проце с другими параметрами пайплайна и все начинает тормозить (я про самую последнюю версию кода). Проходит пару лет и появляются еще какие-то улучшения в компайлере и железе. А этот код начинает тормозить еще больше в сравнении с обычным, сгенеренным компайлером. Я не говорю, что не надо оптимизировать, но делать это надо с умом и так, чтобы быстро было везде, а не на конкретной машине программиста.
the trick
> > Я очень часто работаю в отладчике и много видел кодов (инструкций) программ
> > на
> > VB6 и на других языках, но я просто смотрел инструкции и закрывал отладчик не
> > смотря что код делает и как работает?
> Ты не видишь что это глупо?
я могу тебе назвать с десяток причин, не связанных с производительностью, почему ты мог заглядывать в асм. Откуда мне знать, зачем ты изначально туда заглядывал.
the trick
> Господи, это ересь. Как определить качество компилятора по твоему?
Я уже тебе написал...
> Чтобы нормально протестировать и получить какой-то результат, надо во-первых
> иметь несколько поколений процов от разных производителей, несколько
> компайлеров с разными настройками оптимизации. Собственно тестовые наборы, где
> помимо синтетических тестов должны быть реальные программы (пусть и небольшие),
> а не только число-дробилки. Ты что-то подобное делал? Я очень сомневаюсь.
Ты читать не умеешь?
PANDA
> Я говорю о том, что эта, как сказал Тарас, "магия" дает прирост в несколько
> раз, и именно ее развивают последние 10-15 лет, а АРМ как раз остался на уровне
> третьего пня.
Я про магию, выполняемую компилятором. А ты про что, лол?
Про магию процессоров я в курсе. Кстати, она снижает разницу между оптимизированным и неоптимизированным кодом.
PANDA
> т.к. не учитывает бранч-предикшн и out-of-order
Для тупых поясняю - я имел в виду, что магия компилятора, учитывающая эти приколы, даёт прирост на копейки. А вот лишние обращения к памяти более значимы и более заметны глазу.
PANDA
> я могу тебе назвать с десяток причин, не связанных с производительностью,
> почему ты мог заглядывать в асм. Откуда мне знать, зачем ты изначально туда
> заглядывал.
Это ересь. Если ты вскрываешь листинг, то ты смотришь исходный код для того чтобы посмотреть как работает код.
PANDA
> Ты читать не умеешь?
Это бред, поэтому я и переспросил. На разных процессорах результат будет разный, и это не может быть показателем, где то лучше в другом наоборот хуже. Понятное дело что в VB6 компилятор не использует новшеств типа SIMD, просто потому, что во времена его создания их не было (только-только MMX появился). Я часто занимаюсь реверсом и единицы программ, очень очень редко используют эти SIMD и новшества. Компилируя код один в один в VС++ 2010 он получается таким же как и на VB6 (1998), без всяких расширений. Так что ты написал - бред.
the trick
>На разных процессорах результат будет разный, и это не может быть показателем, где то лучше в другом наоборот хуже.
Вот именно, разный результат! Вот в этом и смысл делать тесты, неужели не очевидно. На твоем процессоре ты увидишь 1% прирост и сделаешь неверный вывод, не узнав, что на другом проце 50% тормознее. Неужели не очевидно, что при нормальном тестировании надо рассмотреть как можно больше случаев и примеров. А уже потом обобщать результаты.
the trick
> Я часто занимаюсь реверсом и единицы программ, очень очень редко используют
> эти SIMD и новшества. Компилируя код один в один в VС++ 2010 он получается
> таким же как и на VB6 (1998), без всяких расширений. Так что ты написал - бред.
А тут тебя можно по фактам на жопу посадить. Гугли "auto vectorization", очень много какой код векторизуется автоматически на современных компайлерах. Даже операции пересылки памяти векторизуются.
Тема в архиве.