Comments 79
Вывод очевиден. То же самое (в принципе) с переходом на 64-битные платформы — программы должны поддерживать новые возможности, «иначе ничего не получится» (с)Хабр.
Кстати, увеличение тактовой частоты не настолько большое, чтобы ожидать сколько-либо заметного роста производительности.
Кстати, увеличение тактовой частоты не настолько большое, чтобы ожидать сколько-либо заметного роста производительности.
я помню когда была видна разница между поколениями одного и того же проца при на одинаковых частотах… Лично у меня все в память упирается (мой десктоп), 2 ГБ не хватает, но больше не поставить :(
Да, как пишет Иван Сагалаев Надо всё переписать
Вы забыли о том, что если гонка в частоте процессоров закончилась, то гонка в частоте системных шин и памяти продолжается. С новым компьютером так же можно получить DDR3 вместо DDR или DDR2, плюс два или три кнала памяти вместо одного или двух. Чтобы использовать это, не нужно переписывать код программ заново.
я тестировал память ddr2 6400, 8500, 10600 и ddr3 10600
скорость в евересте у всех, кроме 6400 — 7,5 Гб/сек, у 6400 соответственно около 6,3-6,4 Гб/сек
так что память тоже херово работает :(
скорость в евересте у всех, кроме 6400 — 7,5 Гб/сек, у 6400 соответственно около 6,3-6,4 Гб/сек
так что память тоже херово работает :(
Зато к энергоэффективности и экономичности — прямое. Windows 7 и современные CPU поддерживают «парковку» ядер (в случае отсуствия нагрузки бОльшая часть ядер просто отключается). Память DDR3 использует пониженное напряжение питания, что тоже сказывается на экономии электроэнергии. Для GPU верны сразу оба предыдущих утверждения.
А у вас точно все в процессор упирается? Может в диск?
Предлагаю попробовать с ram-диск-а запускать…
Далее, на C2Q квадах каждая из половинок кэша второго уровня доступна только для «своей» пары ядер, поэтому если операционка ваш поток перекинет на «неправильное» ядро, получите задержку из-за отсутствия данных в L2 кеше.
Предлагаю попробовать руками привязывать ваши потоки к ядрам (CPU Affinity).
Ну и лично я сильно сомневаюсь что у вас числовой работы на час счета квадкора, даешь оптимизации в массы, SSE2, Intel C++ и т д и т п :-)
Предлагаю попробовать с ram-диск-а запускать…
Далее, на C2Q квадах каждая из половинок кэша второго уровня доступна только для «своей» пары ядер, поэтому если операционка ваш поток перекинет на «неправильное» ядро, получите задержку из-за отсутствия данных в L2 кеше.
Предлагаю попробовать руками привязывать ваши потоки к ядрам (CPU Affinity).
Ну и лично я сильно сомневаюсь что у вас числовой работы на час счета квадкора, даешь оптимизации в массы, SSE2, Intel C++ и т д и т п :-)
>> Ну и лично я сильно сомневаюсь что у вас числовой работы на час счета квадкора, даешь оптимизации в массы, SSE2, Intel C++ и т д и т п :-)
я думаю к этому и идёт, к избыточности инструкций процессора. Формально на PC 3 распространённые архитектуры, на деле получается гораздо больше, все эти SSE2 SSE3 SSE4. Отсюда добавляется геморроя разработчикам на компилируемых языка, придётся писать код под разные процы или распространять с исходниками. В этом плане интерпретируемые языки в байт-код начинают потихоньку выигрывать, пока только не ясно когда этот выигрыш будет в полной мере ощутим.
я думаю к этому и идёт, к избыточности инструкций процессора. Формально на PC 3 распространённые архитектуры, на деле получается гораздо больше, все эти SSE2 SSE3 SSE4. Отсюда добавляется геморроя разработчикам на компилируемых языка, придётся писать код под разные процы или распространять с исходниками. В этом плане интерпретируемые языки в байт-код начинают потихоньку выигрывать, пока только не ясно когда этот выигрыш будет в полной мере ощутим.
Геморроя нет. При правильном использовании Intel C++ делает все это за вас )
Ну и SSE2 is a must сейчас…
Ну и SSE2 is a must сейчас…
Ага, и пользователи AMD вам скажут большое спасибо
icc -xSSE2 source.c -o test.x,
работает на Intel и AMD одинаково, с SSE2. а для IPO, PGO которые часто более эффективны, вообще почти без разницы Intel или AMD.
работает на Intel и AMD одинаково, с SSE2. а для IPO, PGO которые часто более эффективны, вообще почти без разницы Intel или AMD.
Вы видимо новостей недавних не читали… Или неужели интелы исправились? К сожалению не имею под рукой AMD машины, чтобы проверить
Та новость была про «интеллект» компайлера, когда генерится несколько вариантов кода и исполняется один из них, в зависимости от проца, на котором исполняемся. Можно просто приказать компайлеру — генерируй только SSE2(1,3,4.1,4.2) код, как я написал выше. Конечно, на P3 это не заработает, в отличие от.
Just use gcc, luke! Делаем 3 сборки, одну для generic i686, другую для современных IA32 и третью для современных X86-64. А писать код под разные процы, это что-ли в ассемблер лезть? Ну так вы себе только гемморой наживёте. Я вот привык доверятся компилятору и код даже на arm процессорах работает.
И получаем необходимость тестирования трех версий приложения…
Даже в случае с байт кодом нужно будет тестить на всех аппаратных платформах, а еще желательно на всех распространённых интерпретаторах, JIT компиляторах.
Вот только представьте сколько проблем может быть при разработке кроссплатформенного софта.
Вот только представьте сколько проблем может быть при разработке кроссплатформенного софта.
>> Даже в случае с байт кодом нужно будет тестить на всех.
Да, разумеется.
>> Вот только представьте сколько проблем может быть при разработке кроссплатформенного софта.
Собственно их столько и есть :-). А поскольку далеко не всегда есть силы у разработчиков тестировать под разные платформы, в целом получается что кроссплатформенные приложения бывают менее оттестированы, чем одноплатформенные.
Да, разумеется.
>> Вот только представьте сколько проблем может быть при разработке кроссплатформенного софта.
Собственно их столько и есть :-). А поскольку далеко не всегда есть силы у разработчиков тестировать под разные платформы, в целом получается что кроссплатформенные приложения бывают менее оттестированы, чем одноплатформенные.
Скорее они оттестированы на родной платформе разработчика, а на других просто как-то работают.
Ну и конечно кроссплатформенные проги куда чаще бывают открытыми.
Ну и конечно кроссплатформенные проги куда чаще бывают открытыми.
Это безумно интересная мысль, как то я вот не догадывался об этом. Камент ниже дополняет и расширяет. Теперь придется поразмышлять над стратегией.
>> А у вас точно все в процессор упирается? Может в диск?
Вы правы, упирается в диск, так как много дисковых операций.
О чем есть запись здесь.
Но это не отменяет описанного поведения процессора.
Вы правы, упирается в диск, так как много дисковых операций.
О чем есть запись здесь.
Но это не отменяет описанного поведения процессора.
>> Ну и лично я сильно сомневаюсь что у вас числовой работы на час счета квадкора.
Опять же Вы правы, как указано в заметке:
«То, что ускорение происходит не в два раза связано с тем, что процесс тестов не полностью параллелен и содержит последовательные процедуры.»
Действительно счета там не на час, но от этого задача не перестает быть реальной :-).
Опять же Вы правы, как указано в заметке:
«То, что ускорение происходит не в два раза связано с тем, что процесс тестов не полностью параллелен и содержит последовательные процедуры.»
Действительно счета там не на час, но от этого задача не перестает быть реальной :-).
При запуске юнит-тестов жесткий диск точно роли не играет. Чистый счет, с потреблением порядка 2 Гб памяти.
При длительных тестах жесткий диск играет роль. Приходится препроцессировать много файлов. Но я думаю, это не влияет. Вот дополнительные сведения по памяти и дискам.
Память в обоих случаях: DDR2 Dual Symmetric 400 MGz
Диски:
1) WDC5000AAKS ATA 16 MB Cache 7200 RPM
2) WD3200AAKS ATA 16 MB Cache 7200 RPM
При длительных тестах жесткий диск играет роль. Приходится препроцессировать много файлов. Но я думаю, это не влияет. Вот дополнительные сведения по памяти и дискам.
Память в обоих случаях: DDR2 Dual Symmetric 400 MGz
Диски:
1) WDC5000AAKS ATA 16 MB Cache 7200 RPM
2) WD3200AAKS ATA 16 MB Cache 7200 RPM
В случае Сполски замена hdd на ssd не привела к уменьшению времени компиляции.
В Вашем же случае анализ(юнит тесты) данных, поэтому прирост может быть.
Я бы на Вашем месте проанализировал поведения OS & PC в момент проведения тестов и посмотрел, что является узким местом.
В Вашем же случае анализ(юнит тесты) данных, поэтому прирост может быть.
Я бы на Вашем месте проанализировал поведения OS & PC в момент проведения тестов и посмотрел, что является узким местом.
По поводу CPU Affinity. Я знаю, что привязка к ядрам немного ускорит работу. Я экспериментировал. Вот результат по юнит-тестам:
1 поток на 4 ядрах — 62 секунды
1 поток привязанный к одному ядру — 60 секунд
Я сознательно не стал затрагивать этот вопрос. Ведь хотелось показать, что просто приобретя чуть более мощный процессор с большим количеством ядер, я ничего не получу от неподготовленной к этому программе.
1 поток на 4 ядрах — 62 секунды
1 поток привязанный к одному ядру — 60 секунд
Я сознательно не стал затрагивать этот вопрос. Ведь хотелось показать, что просто приобретя чуть более мощный процессор с большим количеством ядер, я ничего не получу от неподготовленной к этому программе.
А еще, у вас тип памяти одинаковый? А то хорошая DDR2 может быть быстрее плохой DDR3 :-)
Могу ошибаться, но мне кажется, это довольно очевидный результат. Использование 2х ядер на 4хядерном процессоре создает накладные расходы на реализацию этого искусственного ограничения. А насчет «Преимущество можно получить только от использования программ, которые умеют использовать несколько ядер.» вы абсолютно правы — закон Амдала никто не отменял.
Вообще, в «начале времен» когда компьютерные архитектуры только придумывались, существовали два идеолога подходов к проектированию — один профессор говорил, что в компьютере должен быть один центральный процессор, который будет думать «за всех», и был второй профессор — который говорил, что в компьютере должно быть несколько процессоров, которые смогут решать независимые задачи.
В итоге победил подход первого процессора, и появились разные IBM-PC совместимые компьютеры с центральным микропроцессором.
В то же время сейчас взгляды второго профессора становятся более реальными — за графическую подсистему отвечают всякие мощные чипы, процессоры становятся многоядерными… То есть все подходы оказались хороши, но для своего времени — пока технологи позволяли «мельчить» дорожки, хватало одноядерных процессоров, а когда дошли до технологического предела — стали масштабировать уже «количественные» показатели.
В итоге победил подход первого процессора, и появились разные IBM-PC совместимые компьютеры с центральным микропроцессором.
В то же время сейчас взгляды второго профессора становятся более реальными — за графическую подсистему отвечают всякие мощные чипы, процессоры становятся многоядерными… То есть все подходы оказались хороши, но для своего времени — пока технологи позволяли «мельчить» дорожки, хватало одноядерных процессоров, а когда дошли до технологического предела — стали масштабировать уже «количественные» показатели.
Мне почему-то всегда немного страшно читать такие статьи — видимо ленивому подсознанию не очень хочется разбираться во всех нюансах а разнообразию параллельного программирования )
Я не понимаю, как можно провдить сравнения, когда используются две совершенно разные системы?
У вас разные ОС, разные процы, разные материнки. Настройки BIOS'а тоже разные скорее всего, а там и до таймингов и задержек ОЗУ в настройках BIOS не далеко. К тому же, где гарантия идентичности процессов запущенных при выполнениии этих Unit тестов?
Вообще, я считаю, что эти тесты не говорят ни о чем.
У вас разные ОС, разные процы, разные материнки. Настройки BIOS'а тоже разные скорее всего, а там и до таймингов и задержек ОЗУ в настройках BIOS не далеко. К тому же, где гарантия идентичности процессов запущенных при выполнениии этих Unit тестов?
Вообще, я считаю, что эти тесты не говорят ни о чем.
Может кто-нибуть знает, в JUnit/NUnit можно запустать тесты в два-три-четыре потока?
Спасибо.
Спасибо.
Посмотрите на Japex japex.dev.java.net и на junitbench code.google.com/p/junitbench/
Japex так же позволяет сравнивать выгоду от использования нескольких ядер
Japex так же позволяет сравнивать выгоду от использования нескольких ядер
Это не юнит тесты. Это вообще не тесты и статья — ни о чем.
Это «тонкий» пиар их системы.
Это «тонкий» пиар их системы.
«Я не хочу строить теории, почему получены именно такие данные по замерам скорости и в чем может быть ошибка. Я хочу сказать, что пришло то самое время, когда халява закончилась»
То есть ничего не поняли (т.е. что именно влияет и почему), но выводы сделали? :)
Где методики тестирования? Скажем, разница в 6 секунд (62-56) — это вообще-то больше методической погрешности или меньше?
Где, собственно, сравнение только процессоров (т.е. на одной и той же системе, под одной и той же ОС, но с разными процы)?
То есть ничего не поняли (т.е. что именно влияет и почему), но выводы сделали? :)
Где методики тестирования? Скажем, разница в 6 секунд (62-56) — это вообще-то больше методической погрешности или меньше?
Где, собственно, сравнение только процессоров (т.е. на одной и той же системе, под одной и той же ОС, но с разными процы)?
Методика сравнения очень простая. Где-то года два назад, точно не помню, у меня появилась новая рабочая машина. Я увидел существенный прирост производительности, на задачах не ориентированных на многоядерность. Сейчас у меня новая машина из того же ценового диапазона. Я вижу прирост производительности, там где используется несколько ядер. И не вижу прирост, где не используется! Мне не интересуют теоретические рассуждения и замеры. Мне интересно практическое использование новой техники. :)
Скажите, а можно ваши результаты перенести на другую машину?
Ну, то есть на конкретно вашем компьютере с конкретно вашим состоянием ОС вы получили некие абстрактные циферки. На другой «новой машине из того же ценового диапазона» будет всё то же самое? Или нет?
Ну, то есть на конкретно вашем компьютере с конкретно вашим состоянием ОС вы получили некие абстрактные циферки. На другой «новой машине из того же ценового диапазона» будет всё то же самое? Или нет?
К сожалению, я видимо так и не смог донести мысль. Попробую еще раз. Общепризнано, что существенный рост дальнейшей производительности возможен только за счет распараллеливания. Увеличение разрядности (32->64), рост тактовой частоты процессоров, памяти, шины и так далее, дает прирост в процентах. Но не в разы. Существенный прирост дает только использование нескольких ядер. Программное обеспечение, не использующее несколько ядер, в ближайшее время будет получать все меньший и меньший прирост производительности при установке на новые системы. Для разных программ это наступит в разное время. В моем случае, я считаю, это произошло сейчас. Об этом я и рассказал.
Скажите, а как в таком случае ваш результат — 62 секунды на ядре с большей частотой против 56 секунд на ядре с меньшей частотой — согласуется с «рост тактовой частоты процессоров, памяти, шины и так далее, дает прирост в процентах».
Вы написали «Я не знаю, чем вызван такой провал производительности. Поэтому комментировать этот замер не буду.», но в этом-то и проблема.
Раз вы не можете ни объяснить первый результат, ни подтвердить/опровергнуть его корректность, то почему вы считаете, что корректны результаты второго теста (снова падение производительности при росте частоты процессора)?
А если это будет не Q9400, а Q8300?
P.S. Кстати, если верить интелу, то E7200 не 2.4GHz, а 2.53GHz
Вы написали «Я не знаю, чем вызван такой провал производительности. Поэтому комментировать этот замер не буду.», но в этом-то и проблема.
Раз вы не можете ни объяснить первый результат, ни подтвердить/опровергнуть его корректность, то почему вы считаете, что корректны результаты второго теста (снова падение производительности при росте частоты процессора)?
А если это будет не Q9400, а Q8300?
P.S. Кстати, если верить интелу, то E7200 не 2.4GHz, а 2.53GHz
Я не могу ответить на ряд вопросов в силу недостаточно высокой компетентности в сфере Benchmark, а также из-за отсутствия необходимой технической базы для более детальных сравнений и экспериментов. Я могу строить гипотезы, не более. Но не хочу. По этому, и написал, что оставляю это без комментариев, так как признаю, что я могу быть не прав и не точен.
P.S.
Измерения в юнит-тестах осуществляются с использованием GetThreadTimes с расчетом среднего арифметического. Это вполне достоверно, если мы говорим об одном потоке. В многопоточном режиме использовался простой таймер, но для порядка 100 минут, это совершенно точные результаты.
P.S.
Измерения в юнит-тестах осуществляются с использованием GetThreadTimes с расчетом среднего арифметического. Это вполне достоверно, если мы говорим об одном потоке. В многопоточном режиме использовался простой таймер, но для порядка 100 минут, это совершенно точные результаты.
Был у нас один проект, оптимизация поисковой машины. Когда мы отправили заказчику наши изменения, нам в ответ пришло: -Прекрасно! На глаз вижу прирост производительности в 10%!
Наш отдел валялся, дело в том что скорость работы тестов измерялась секундами. С тех пор пошла молва о «глазомере» заказчиков.
Суть притчи такова — если вы пишите технически грамотную статью, то в вашем эксперименте должна быть цель и описана методика проведения измерений, логически и физически обоснованная. А у вас простите — «глазомер».
Наш отдел валялся, дело в том что скорость работы тестов измерялась секундами. С тех пор пошла молва о «глазомере» заказчиков.
Суть притчи такова — если вы пишите технически грамотную статью, то в вашем эксперименте должна быть цель и описана методика проведения измерений, логически и физически обоснованная. А у вас простите — «глазомер».
С одной стороны верно, с другой стороны иногда такой «методичный» подход вызывает улыбку. Например, я долго-долго читал вот эту статью на THG.RU, чтобы в ее конце обнаружить совершенно очевиднейший вывод. Возникает вопрос: а не из пушки ли это по воробъям? Может иногда имеет смысл сразу перейти к выводам? Нет, правда смешно:
«Первое, что мы узнали: технология Turbo Boost оказывается наиболее эффективной при улучшении производительности приложений, плохо оптимизированных под многопоточность.»
«Первое, что мы узнали: технология Turbo Boost оказывается наиболее эффективной при улучшении производительности приложений, плохо оптимизированных под многопоточность.»
Забыл уточнить: этот вывод сделан после 4 страниц графиков и тестов.
То есть вы дальше раздел «Заключение» читать просто не стали?
Почему же, я все очень внимательно прочитал. А вы?
В таком случае, почему вас «склинило» на первой фразе?
Собственно, можно было бы поспорить о смысле самой статьи целиком (т.е. обосновать саму необходимость проверки данной технологии), но вот спорить о необходимости описания методик/тестов/приведении результатов этих тестов — вот это уж точно не стоит.
Потому что иначе получаем вот такую статью, как тут — какие-то цифры получили. А каким образом, можно ли их повторить, как их интерпретировать, как их перенести на другую систему и можно ли это сделать — это всё открытые вопросы.
Очень грубы пример: «DOS на моём 486ом грузился моментально. Vista на E6600 грузится заметное время. То есть напрашивается очевидный вывод: E6600 супротив 486 DX4 100 — говно» :)
Собственно, можно было бы поспорить о смысле самой статьи целиком (т.е. обосновать саму необходимость проверки данной технологии), но вот спорить о необходимости описания методик/тестов/приведении результатов этих тестов — вот это уж точно не стоит.
Потому что иначе получаем вот такую статью, как тут — какие-то цифры получили. А каким образом, можно ли их повторить, как их интерпретировать, как их перенести на другую систему и можно ли это сделать — это всё открытые вопросы.
Очень грубы пример: «DOS на моём 486ом грузился моментально. Vista на E6600 грузится заметное время. То есть напрашивается очевидный вывод: E6600 супротив 486 DX4 100 — говно» :)
Не понимаю, за что минусуют vladsm. Детский сад.
Меня не «склинило». Просто я за принцип разумной достаточности. Не стОит делать 4 страницы графиков и тратить неделю на тестирование, только для того, чтобы получить 4 совершенно очевиднейших вывода.
Да, вывод этой статьи Андрея тоже вряд ли получит оскар за оригинальность. Но если сюда добавить страницу графиков он более оригинальным не станет, так? Зато это хороший рабочий пример, за что Андрею и спасибо.
Меня не «склинило». Просто я за принцип разумной достаточности. Не стОит делать 4 страницы графиков и тратить неделю на тестирование, только для того, чтобы получить 4 совершенно очевиднейших вывода.
Да, вывод этой статьи Андрея тоже вряд ли получит оскар за оригинальность. Но если сюда добавить страницу графиков он более оригинальным не станет, так? Зато это хороший рабочий пример, за что Андрею и спасибо.
«Не стОит делать 4 страницы графиков и тратить неделю на тестирование, только для того, чтобы получить 4 совершенно очевиднейших вывода»
Ну так это вопрос смысла создания самой статьи. Это не вопрос её структуры (введение, постановка задачи, описание методик и т.д. и т.п., выводы и заключение).
«Но если сюда добавить страницу графиков он более оригинальным не станет, так? Зато это хороший рабочий пример, за что Андрею и спасибо.»
Это никакой не пример, в том-то и дело. Он не в состоянии ответить на возникающие вопросы.
Что явилось причиной разницы в скорости? Только лишь процессор? Или то, что вся система вообще другая? А что больше повлияло — смена окружения целиком или смена процессора? А насколько велик вклад того или иного изменения? И ещё раз — а как перенести результаты вот конкретного этой разницы двух конкретно взятых компьютеров в конкретно вот этой задаче на что-то ещё? И 6 секунд — это 10% производительности или просто некая «константа», в духе «некая разность за счёт скорости загрузки теста на другой системе с другим винтом в данный момент времени»?
Вот об этом речь. О том, что не проведён анализ того, что же именно оказывает влияние и какое это именно влияние.
А без этого нельзя ни выводы сделать, ни хотя бы проверить их.
Ну так это вопрос смысла создания самой статьи. Это не вопрос её структуры (введение, постановка задачи, описание методик и т.д. и т.п., выводы и заключение).
«Но если сюда добавить страницу графиков он более оригинальным не станет, так? Зато это хороший рабочий пример, за что Андрею и спасибо.»
Это никакой не пример, в том-то и дело. Он не в состоянии ответить на возникающие вопросы.
Что явилось причиной разницы в скорости? Только лишь процессор? Или то, что вся система вообще другая? А что больше повлияло — смена окружения целиком или смена процессора? А насколько велик вклад того или иного изменения? И ещё раз — а как перенести результаты вот конкретного этой разницы двух конкретно взятых компьютеров в конкретно вот этой задаче на что-то ещё? И 6 секунд — это 10% производительности или просто некая «константа», в духе «некая разность за счёт скорости загрузки теста на другой системе с другим винтом в данный момент времени»?
Вот об этом речь. О том, что не проведён анализ того, что же именно оказывает влияние и какое это именно влияние.
А без этого нельзя ни выводы сделать, ни хотя бы проверить их.
Я отчасти с вами согласен, выводы может быть для кого-то неочевидны, или вообще — очевидны только для автора. Однако, к вопросу разумной достаточности — даже если выводы не очевидны повод для обсуждения уже есть.
Все-таки Хабр не сборник догматов а, скорее, место для обсуждения чего-либо, ошибаюсь?
Все-таки Хабр не сборник догматов а, скорее, место для обсуждения чего-либо, ошибаюсь?
Вопрос в том, на основании чего делаются те или иные выводы.
И насколько правомерно эти выводы делать вообще в той или иной ситуации.
Разумеется, место для обсуждения. Чем мы, собственно, сейчас и занимаемся.
И насколько правомерно эти выводы делать вообще в той или иной ситуации.
Разумеется, место для обсуждения. Чем мы, собственно, сейчас и занимаемся.
ok.
Собственно если загвоздка в 6 секундах (10%) разницы на юнит-тестах, то я могу из головы прямо сейчас выдумать десяток причин, почему так может получиться. И затем автор потратит месяц на то, чтобы подтвердить или опровергнуть эти мои гипотезы.
Но.
40% > 10%, это обсуждать по меньшей мере странно. Мы знаем, откуда взялись 40%. Следовательно, можем назвать эту причину «выводом в первом приближении», так?
Собственно если загвоздка в 6 секундах (10%) разницы на юнит-тестах, то я могу из головы прямо сейчас выдумать десяток причин, почему так может получиться. И затем автор потратит месяц на то, чтобы подтвердить или опровергнуть эти мои гипотезы.
Но.
40% > 10%, это обсуждать по меньшей мере странно. Мы знаем, откуда взялись 40%. Следовательно, можем назвать эту причину «выводом в первом приближении», так?
Вот именно для того, чтобы ничего никто не выдумывал и разрабатывают методики тестирования и анализа/интерпретации полученных результатов тестирования.
«Выводом в первом приближении» о чём? О том, что в случае оптимизации программы под какую-то технологию, на платформе с этой самой технологией мы будем иметь преимущество?
Так это, кагбэ, известно уже из фразы «оптимизация XXXX под YYYY».
«Выводом в первом приближении» о чём? О том, что в случае оптимизации программы под какую-то технологию, на платформе с этой самой технологией мы будем иметь преимущество?
Так это, кагбэ, известно уже из фразы «оптимизация XXXX под YYYY».
Отнюдь. Вывод о том, что для любой платформы данный тип оптимизации ресурсоемких приложений — единственный способ получить серьезно преимущество в долгсрочной перспективе.
Если вы знаете какой-либо тип оптимизации, вложения в которые дадут бОльший эффект в обозримом грядущем хотябы на одной платформе — дайте мне знать. Лично я — не знаю.
Если вы знаете какой-либо тип оптимизации, вложения в которые дадут бОльший эффект в обозримом грядущем хотябы на одной платформе — дайте мне знать. Лично я — не знаю.
Ещё раз — «Оптимизация XXXX под YYYY даёт выигрыш на YYYY. Именно поэтому данное действие и называется «оптимизация»».
Замените XXXX на «ресурсоёмкое приложение», а YYYY на «мультиядерная система».
Замените XXXX на «расход топлива в условиях жаркого климата», а YYYY замените на «жаркий климат». И так далее…
Замените XXXX на «ресурсоёмкое приложение», а YYYY на «мультиядерная система».
Замените XXXX на «расход топлива в условиях жаркого климата», а YYYY замените на «жаркий климат». И так далее…
Ууууу… Да, при таком подходе действительно нужно сделать сотню графиков ТОЛЬКО для того, чтобы затем сделать сотню оговорок почему вы НИКОГДА не получите заявленных цифр на вашей конкретной платформе и вашем конкретном приложении.
Еще раз: я не против точных данных, наоборот — я всецело за! Но я за принцип разумной достаточности. Иными словами: покажите мне любую цифру, и я тут же скажу, как ее испортить.
Еще раз: я не против точных данных, наоборот — я всецело за! Но я за принцип разумной достаточности. Иными словами: покажите мне любую цифру, и я тут же скажу, как ее испортить.
Не, вы, видимо, не понимаете…
Так вы объясните ;)
Например, приведите пример любой современной платформы, на которой имеет смысл вкладываться во что-либо, кроме распараллеливания, чтобы болучить хороший долгосрочный эффект.
Например, приведите пример любой современной платформы, на которой имеет смысл вкладываться во что-либо, кроме распараллеливания, чтобы болучить хороший долгосрочный эффект.
В огороде бузина, в Киеве дядька…
Что объяснить?
Что термин «XXX оптимизировано для YYY» обозначает, что «XXX в условиях YYY выполняется (бегает, прыгает, плавает, летает, пахнет, дохнет и т.д.) лучше»?
При чём тут примеры современной платформы для вкладывания, когда речь идёт про конкретно данный пост с конкретно данным текстом и цифрами?!
Что объяснить?
Что термин «XXX оптимизировано для YYY» обозначает, что «XXX в условиях YYY выполняется (бегает, прыгает, плавает, летает, пахнет, дохнет и т.д.) лучше»?
При чём тут примеры современной платформы для вкладывания, когда речь идёт про конкретно данный пост с конкретно данным текстом и цифрами?!
Мы обсуждаем целесообразность досконального исследования всего и вся. Я утверждаю, что это делать нецелесообразно, гораздо важнее найти bottleneck, самое узкое место, и сконцентрироваться именно на нем. Собственно, это первое правило любой оптимизации. Вы же не будете исследовать сопротивление качению шин вашего автомобиля, если диагностика показала, что свечи сдохли?
Вы же с завидным постоянством требуете от автора исследования износа покрышек. Хотя все давно уже поняли, что «движок троит». Вот я и спрашиваю: если движок троит, и диагностика показывает неисправность свечи во втором цилиндре, что, по вашему, еще нужно померять для того чтобы с легким сердцем заменить свечи???
Вы же с завидным постоянством требуете от автора исследования износа покрышек. Хотя все давно уже поняли, что «движок троит». Вот я и спрашиваю: если движок троит, и диагностика показывает неисправность свечи во втором цилиндре, что, по вашему, еще нужно померять для того чтобы с легким сердцем заменить свечи???
«гораздо важнее найти bottleneck, самое узкое место, и сконцентрироваться именно на нем»
Ну так именно для этого и разрабатываются методики тестирования.
Для того, чтобы выявить именно то конкретное «место», которое и будет тестироваться.
«Вы же не будете исследовать сопротивление качению шин вашего автомобиля, если диагностика показала, что свечи сдохли?»
Полагаю, что и вы не будете.
Однако в данном случае «диагностика-то» проведена не была. И в этом вся проблема.
В данном случае всё на уровне «У меня был ВАЗ „семёрка“, а теперь BMW „семёрка“. И поехал я на дачу. Забавно, но на BMW я чё-т вчера проехал за два часа, хотя на „семёрке“ проезжал за час. Фиг знает, почему так получилось. Мож на светофорах стоял? А зато на МКАДе удалось ночью разогнаться до 250км/ч. Вывод — БМВ это круто, но не надо думать, что на ней сразу будете быстрее доезжать до дачи».
«Дорогой дневничок…» прям какой-то :)
Ну так именно для этого и разрабатываются методики тестирования.
Для того, чтобы выявить именно то конкретное «место», которое и будет тестироваться.
«Вы же не будете исследовать сопротивление качению шин вашего автомобиля, если диагностика показала, что свечи сдохли?»
Полагаю, что и вы не будете.
Однако в данном случае «диагностика-то» проведена не была. И в этом вся проблема.
В данном случае всё на уровне «У меня был ВАЗ „семёрка“, а теперь BMW „семёрка“. И поехал я на дачу. Забавно, но на BMW я чё-т вчера проехал за два часа, хотя на „семёрке“ проезжал за час. Фиг знает, почему так получилось. Мож на светофорах стоял? А зато на МКАДе удалось ночью разогнаться до 250км/ч. Вывод — БМВ это круто, но не надо думать, что на ней сразу будете быстрее доезжать до дачи».
«Дорогой дневничок…» прям какой-то :)
Все, понял. Просто глядя на этот ваш комментарий, я полагал, что вы ратуете за обоснование шестисекундной разницы в юнит тестах. Ан нет.
Но позвольте — в статье сравнивается разультаты, полученные на ОДНОЙ машине: 1) Q9400 со всеми четырьмя ядрами и 2) она же, но с двумя отключенными ядрами. Более честного сравнения я не представляю.
Где же вы тут увидели аналогию со сравнением ВАЗа и BMW? Это просто «всем чмоки в этом чате» какое-то ;)
Но позвольте — в статье сравнивается разультаты, полученные на ОДНОЙ машине: 1) Q9400 со всеми четырьмя ядрами и 2) она же, но с двумя отключенными ядрами. Более честного сравнения я не представляю.
Где же вы тут увидели аналогию со сравнением ВАЗа и BMW? Это просто «всем чмоки в этом чате» какое-то ;)
То есть первую половину статьи просто выкидываем. Возникает вопрос — нафига она тогда вообще была?
Но позвольте, в статье ещё и сравниваются результаты ДВУХ машин: E7200, два ядра, Vista x64, 4Gb vs Q9400, «включены» два ядра, W7 x64, 8Gb
При этом при большей частоте Q9400 получили и большее время выполнения.
Насколько полученные величины достоверны и от чего зависят на самом деле?
Мне казалось, что статья задумывалась как нечто большее, чем констатация факта «задача, рассчитанная на мультиядерные системы на Q9400 с четырьмя ядрами работает лучше, чем на Q9400 с двумя».
Честно — я боюсь объяснять подробнее, потому что боюсь того, что вы меня ещё в какой-нить холливор про Автоваз втянете… Замените ВАЗ на Мерседес, если вам так легче.
Две разных(!) системы: разные ос, разный объём памяти, разные винты, разные процы — РАЗНЫЕ системы. Я уже устал повторять, вот честно. Всё написано в первом же моём комментарии.
Но позвольте, в статье ещё и сравниваются результаты ДВУХ машин: E7200, два ядра, Vista x64, 4Gb vs Q9400, «включены» два ядра, W7 x64, 8Gb
При этом при большей частоте Q9400 получили и большее время выполнения.
Насколько полученные величины достоверны и от чего зависят на самом деле?
Мне казалось, что статья задумывалась как нечто большее, чем констатация факта «задача, рассчитанная на мультиядерные системы на Q9400 с четырьмя ядрами работает лучше, чем на Q9400 с двумя».
Честно — я боюсь объяснять подробнее, потому что боюсь того, что вы меня ещё в какой-нить холливор про Автоваз втянете… Замените ВАЗ на Мерседес, если вам так легче.
Две разных(!) системы: разные ос, разный объём памяти, разные винты, разные процы — РАЗНЫЕ системы. Я уже устал повторять, вот честно. Всё написано в первом же моём комментарии.
Я прекрасно понимаю, о чем вы. А вот вы меня совершенно понять не хотите. Итак, еще раз: читаем первые два предложения в этой статье, и английскую статью по первой ссылке в ней же. Теперь стало понятнее, зачем нужна первая часть?
Зачем нужна первая часть в виде «чё-то сделали, какая-то фигня получилась, а почему так и отчего — разбираться не буду» понятнее не стало.
Если бы первая часть была про E7200 vs E8600 (одна задача, два ядра — разные частоты — пресловутый «free lunch»), а вторая про E7200 vs E8600 vs Q9400 «x2» vs Q9400 «x4» (то есть показать, что «free lunch» действительно over) — был бы разговор. А так…
Если бы первая часть была про E7200 vs E8600 (одна задача, два ядра — разные частоты — пресловутый «free lunch»), а вторая про E7200 vs E8600 vs Q9400 «x2» vs Q9400 «x4» (то есть показать, что «free lunch» действительно over) — был бы разговор. А так…
Непонятно уже — о чем вы спорите. Тесты должны быть репрезентативны. А автор пишет — я померял что-то на чем-то, потом померял что-то на еще чем-то и получил… вывод! Второе что-то было не быстрее чем первое!
Так о чем, простите, речь? О всестороннем тестировании или о том что наведенные эффекты могут дать погрешность больше замеряемой величины? Кто-нибудь может сказать четко — что мерялось? Эффективность дисковой подсистемы? Пропускная способность памяти? Быстродействие ЦПУ на целых числах? Или на плавучке? Особенность планирования задач в разных ОС? И из всего этого можно сделать феноменальный вывод.
Если кому то не нравятся читать статьи с кучей графиков — можно перейти сразу к заключению. Но если кто-то видит необъяснимые для него результаты — он может вернуться к странице N и почерпнуть оттуда все условия тестирования и понять — что же произошло.
Так о чем, простите, речь? О всестороннем тестировании или о том что наведенные эффекты могут дать погрешность больше замеряемой величины? Кто-нибудь может сказать четко — что мерялось? Эффективность дисковой подсистемы? Пропускная способность памяти? Быстродействие ЦПУ на целых числах? Или на плавучке? Особенность планирования задач в разных ОС? И из всего этого можно сделать феноменальный вывод.
Если кому то не нравятся читать статьи с кучей графиков — можно перейти сразу к заключению. Но если кто-то видит необъяснимые для него результаты — он может вернуться к странице N и почерпнуть оттуда все условия тестирования и понять — что же произошло.
PVS — дерьмо. Хуже тулзы я не видел. skolem!, блять =)
Я думаю, что E и Q серии Intel это вещи одного порядка, в смысле, процессоры одного технологического поколения, и результаты вполне логичны — разумеется, если отказаться от «народного факта», что 4 ядра всегда круче, чем 2. Выбор процессора очень индивидуальная штука — если используемые, именно вами программы используют многоядерность то стоит 4ядра покупать, а если в основном нет, то 2. Все-таки прирост производительности при использовании всех 4х ядер значительный. Все «профессиональные» тесты ваши выводы, вполне подтверждают.
Жаль что вы Q9400 выбрали, я бы подобное сравнение про i5-750 — i7-860 с технологией Turboboost (когда множитель при при не полном использовании ядер увеличивается) с большим интересом прочитал, так как буду менять C2D 2ГГц на один из этих процессоров)
Жаль что вы Q9400 выбрали, я бы подобное сравнение про i5-750 — i7-860 с технологией Turboboost (когда множитель при при не полном использовании ядер увеличивается) с большим интересом прочитал, так как буду менять C2D 2ГГц на один из этих процессоров)
Sign up to leave a comment.
Бесплатные обеды закончились на практике