Хотители сравнить чистую вычислительную мощность -получите.
Я предложил конкретную прикладную задачу, чистая математика в один поток, компактный код как правило умещающийся в кеше проца.
Что не так?

redguard85 это никакой чистой что там не имеет ничего общего... мы недавно в одной ветки уже сравнивали тесты "суперпи" в одном тесте мой проц считает за 12 секунд в другом 40+ секунд и как мне теперь жить? как вообще вы решили считать пи какие алгоритмы были выбраны? оптимизированы ли алгоритмы для многоядерности или нет? производительность 1 ядра все меньше интересует людей не просто потому что "оно не надо" но если тот же самый результат можно получить н ядер то все же их нужно использовать. в тесте с оптимизацией под многоядреность 2 ядреный атом будет жестоко сливать 4 ядрам кортекса а15 (что кстати мы и видем - постоянно "о боже у нас самый крутой проц" да только до независимых тестов). есть многие критерии как например "плотность кода" и тд на вопрос что не так? я могу сказать все.

Мне предлагается ответить?

Гаусс-Лагранж, потрудились бы хоть скачать-посмотреть что ли.

Нет, не опримизированы. Я же написал. Меряется производительность одного ядра в математике.

Но оно есть.
С большой вероятностью люба математическая задача, которую вы возьмётесь считать, будет исполняться в один поток. Если это не какой-нибудь Маткад, Матлаб etc.

Нельзя быть уверенным. Есть задачи, которые принципиально не параллеляться, вы в курсе?
c=a+b
e=c+a

Реальную задачу приведите, пожалуйста.

Как конечного пользователя меня не интересует плотность кода, особенности работы и латентность Java-машины и т.п. Мне бы задачу посчитать.

и вы считаете что все процессоры теперь должны точить на волнение одно ед. специфического алгоритма? а есть другой алгоритм выполнение той же самой задачи. вопрос (точней не вопрос а риторика) если если алгоритмы более не специфичные и тем более более быстрые я должен использоваться топорный алгоритм / тест?

все что считается на цпу - математика. одно ядро не обязательно должно быть сверх быстрым я еще говорю в век многоядерности и гпу расчетов мерить производительности цпу по одному ядру ололо. были уже в свое время нетбусты - ложные ветвления для них были бичом и где они? в... ну вы сами знаете. опять таки тест пи это просто тупо выполнение цикла - ничего интересного из этого теста нельзя получить.
я уже привел вам пример с векторами - аки видео кодирование, но блин удивительно что в цпу на х86 уже сейчас есть специальные блоки для кодирования что у арма правда у арма раньше появились...

бред щас ос сама уже очень хорошо масштабирует и управляет потоками более того задача в одной программе это не тупо линейный поиск числа с н точности. в реальности вы фиг где встретите такой алгоритм.

и приводите такой тупой безграмотный пример догадайтесь почему...

в какой области? тесты есть они доступны в открытом доступе. тот же к900 сливает подчистую аналогам на армах чем не доказательство того что если код писаный под одну архитектуру нельзя запустить без потерь на другой. вообщем сечас нужно спросить вы хоть разницу архитектур улавливаете? потому что причем тут плотность кода и латентность (такого термина я не встречал ололо) JVM %)

Алгоритм компактный по размеру кода и требующий много математических операций? Легко.
Например шейдер. Ага, те самые шейдеры кторым сейчас разукрашены все игры.


Вы уж определитесь что вам не нравиться в Netbrust: ложные ветвления или очистка длинного конвеера после JMP и синхронизация модулей АЛУ не на частоте шины.


Предложите более быстрый алгоритм вычисления пи. У вас получится, я верю.


Поржал, спасибо. Я например беру проц для игр и должен обращать внимание на тесты дополнительных модулей CPU для кодирования видео? Вы так далеко зайдёте с вашими тестами.
Или в этом случае всё же стоит обратить внимание на производительность одного ядра?


Я уже написал: что мне за дело до архитектуры.
У меня конкретная прикладная задача. Или игра. Или кодирование видео.
Или если это ARM, то пусть считает медленно? Сделаем скидку?


Учиться никогда не позно. Sun Spider benchmark меряет эту самую латентность джава-машины.
xbt в каждом тесте телефона его использует, так как эта самая латентность характеризует отзывчивость интерфейса андроида, к примеру.
"ололо" в этом случае вас очень хорошо характеризует.

когда шейдер считали на цпу последний раз? ради чего такая "математика" на цпу? не понял логики.

какая разница? лол перегружать все равно приходиться в данном конкретном примере - ложные ветвления.

да я вам даже ссылку на сообщение на форме найду где мы это обсуждали - Гибридные процессоры Kaveri: о характеристиках и быстродействии #11573300
вот вам логично алгоритм в 3 раза быстрей если не больше.

после этих слов я с вами даже говорить не хочу. вы разберитесь где нужна векторная аки очень важная часть на х86 а уже потом вот эту ржачную фигню несите.
там вообще стоит обратить внимание !чудо! на векторную производительность - но вы далеки от этого.

можно пойти яги попить в подворотни. ололо же....

вы не сможете понять что я напишу если вы даже не понимаете что я вам объясняю)))

олололо мы тут андроид обсуждаем или арм? вы уж определитесь (: я думал... хотя фиг с ним - это тож ржачно.

Конечно тяжело вам тяжело когда главный аргумент выпить яду... или яги, не разобрал.

Не надо тут передёргивать.
Вы писали что нет практических задач с компактным куском кода и множеством математических операций над ним. Я привёл конкретный пример.
Передёрните нечто другое если вом так хочется.

Мне всё больше кажеться что вы обсуждаете что-то сами с собой.

А теперь смотрите. В sun spider, который вы уже скачали, латентность (задержка отклика) джава-машины линейно зависит от частоты проца. Чем выше частота тем меньше задержка. И не зависит от количества ядер. Отсуда делаем вывод что интерфейс андроида рисуется в один поток.
Поэтому он умудряется лагать на 4х и более ядрах.
Так актуальны тесты(производительности) для одного ядра или нет?

когда ваш главный аргумент игры в которых вещественная производительность не менее важна как и целочисленная да? согласитесь ловить вашу логику уже сложновато.

это когда шейдеры стали компактными? ммм... купите мне той же травы.
вы считайте момент "расчета" вызовы деректх и других апи? с чего вы решили что "шейдерный код" простой? для расчетов шейдеров так же дергается цпу скажем и как мне теперь считать? большее того шейдерные операции всегда были многопоточные бла бла бла... и производительность "одного ядра" тут вообще в жопе как ни крути. как это доказывается "не специфичность алгоритма" я не знаю... более того я вообще не пойму зачем здесь этот пример.

это и барану известно. вы продолжаете жечь напалмом.
давайте другой пример. вася (программа) должен передать пети (железо) задачу но посередине есть маша (транслятор) которая должна проверить информацию.
то есть чем выше скорость интерпретирования чем быстрей выполнение программы и да это и есть время отклика. и да она зависит только от тактовой частоты.
интерфейс андроида не джава то есть как бэ вот так.

Трава хороша, да....
"вещественная производительность" - это с плавающей точкой, да? Все конечно догадались.


Как там на Марсе, не дует?

транслятор оказывается информацию проверяет.
Хоть в вики загляните что ли, а то совсем стыдно.

Нэтив Си + ассемблер, точно говорю.
А пользовательские программы на джаве написали, дурни.

там где и вектора считают аминь.

пример к транслятору кода имел отношение никакое азаза. он был призван показать почему возникает "задержки" при передачи информации И почему тактовая частота их решает.

Добавлено спустя 1 минуту 14 секунд:

мне везде хорошо азазаза!
бредовый пример - бредовые выводы - бредовый коммент - распишитесь в получении.