Re[38]: и все же.
От: Pavel Dvorkin Россия  
Дата: 15.04.10 08:54
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Это значит, что разговор зашел в фазу, когда пора заниматься ликбезом или завязывать.


Придется

PD>>Я не намерен обсуждать, зачем бенчмарки и что ими меряют. Я знаю одно — ими именно меряют.


V>ЧТО меряют? Еще раз большими буквами: что именно ими меряют и как ты предлагаешь использовать бенчмарки для сравнения несовместимых архитектур? Я вот себе даже представить этого не могу.


http://en.allexperts.com/e/d/dh/dhrystone.htm
http://en.allexperts.com/e/w/wh/whetstone_(benchmark).htm

Именно эти величины (MDIPS и MWIPS) мне FreshDiagnose и показывает. Там на рисунке есть комбобокс, сейчас там Speed — нечто интегральное. Другие варианты — MDIPS и MWIPS.

>Это же сравнивать зеленое с горячим. Вот что именно было измеренно на твоем графике? Какой из 3-х десятков популярных бенчмарков был использован и что именно ты увидел на этом графике? Скажи, нафига тебе график, если мы даже не знаем, что на этом графике?


Объяснил чуть выше.

V>Дело в том, что разные тесты бенчмарков ВСЕГДА дают разные сравнительные результаты. Когда был бум частот и я следил за соревнованиями Интел vs АМД, то часто видел, что на одних бенчмарках до 30% выигрывал Интел, на других тестах на столько же был счет в пользу АМД. Поэтому, еще раз, давай ты встряхнешься и задашь вопрос более осознанно — что именно ты хочешь замерять?


Реальное быстродействие этого процессора. И мне нет дела до того, что разные тесты дают разные результаты. Это все верно, но только пока мы в рамках сравнимого. Хоть какие тесты не бери, ни один из них не покажет, что Pentium III — 500 быстрее современного процессора.

PD>>Вот у меня на машине стоит FreshDiagnose. На тебе рисунок от нее.

PD>>Если это не сравнение процессоров по скорости с использованием Benchmark — то будь добр, объясни, что это такое.

V>Угу, смотрю в книгу, вижу фигу.



V>Повторю, я вообще плохо понимаю, как можно пользоваться графиками, когда по осям не указаны размерности.


Уф...
По оси X номер процессора. 1, 2, 3... Что означет 1, 2 и 3 — посмотри справа.
По оси Y — либо MDIPS, либо MWIPS, либо некий интегральный Speed.

Еще вопросы есть ?


V>В общем, в Викки доступным языком растолковано, что есть бенчмарки, какие они бывают, и что меряют. 99% тестов бенчмарков непереносимы, в отличии от SPEC, поэтому требовать сравнительные бенчмарки для несравнимых архитектур... это и есть демонстрировать то, формулировка чего тебя так задела.


А как же в статье, что ты привел, такое сравнение проводится ?

V>В режиме эмуляции именно в бенчмарках Эльбрус показал быстродействие от Пентиум-3 500МГц до Пентиум-4 2000МГц, в зависимости от теста, ключевое опять выделил. Сей разброс легко будет понятен любому студенту-первокурснику, если дать ему 15 мин на изучение вопроса, что есть бенчмарки.


О господи! Ну и аргументы.

V>Ну? А результаты тестов показывают, что в большинстве вычислительных алгоритмов Эльбрус показывает 97-98% от пиковой производительности, в отличие от Core2, который показывает 35-70% на тех же задачах.


V>Сказать честно, мне точные данные не нужны и я не понимаю, зачем они нужны тебе. Разброс +-20% абсолютно ничего не покажет


Верно. Но я не уверен в том, что разброс не будет в 200%. Пока что я никаких данных не от производителя не видел. Данным от производителя я верить не обязан.


V>Так вот, меня интересовало общее положение вещей, а оно комплексное и зависит от типа задач. Ссылку на документ с подробными тестами я привел, там все вполне доступно и показательно. Более того, т.к. Эльбрус — пока единственный TRUE VLIW в природе (трансмета и итаниумы — это компромиссы и архитектурно сосут, сорри за акцент), так вот приведенный документ позволяет вообще взглянуть на сильные и слабые стороны VLIW архитектуры, и всем что с ней связано, как таковой.


Возможно. Я не исключаю, что придуманное ими совсем не плохо, и даже более. Но это никак не влияет на мое отношение к разработке и производству такого рода техники у нас. Я уже писал , повторюсь. Я не возражаю, что у нас есть светлые головы, но эти светлые головы не смогут здесь сделать что-либо реально работающее из-за отсутствия инфраструктуры и технологической культуры. И дело тут не в "развале", потому что так же было до него.
With best regards
Pavel Dvorkin
Re[38]: по ссылке
От: Pavel Dvorkin Россия  
Дата: 15.04.10 09:09
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если тебя действительно интересуют тесты, если тебе действительно интересно (раз уж ты запрашиваешь тесты), что есть Эльбрус, почему именно VLIW, что он дает (в частности, объясняет, зачем Интелл настойчиво вбухивает деньги в непопулярный IA64 и скупает разработчиков Эльбруса), вот тебе ссылка по различным тестам: http://www.mcst.ru/doc/1_grabezhnoy.doc


Посмотрел. Вот это меня сразу насторожило

/////////////////////////////////////////////////////////////////

Таким образом, производительность процессора E3M на данном примере составит 6.0 GIPS или 2.4 GFLOPS.

Таким образом, производительность процессора E3M на данном примере составляет 23.1 GIPS или 9.6 арифметических GOPS.

То есть в одной широкой команде будет: 16 арифметических операций, 8 считываний, 2 записи, 5 вычислений адреса, 1 переход и 1 продвижение счетчика цикла с выработкой условия. Что в сумме составляет 33 инструкции.
Следовательно, производительность процессора E3M на данном примере составит 9.9 GIPS или 4.8 GFLOPS (Табл. 1).

/////////////////////////////////////////////////////////////////

Почему нет просто данных эксперимента ? Программа приведена, запустить да померять. Вместо этого рассуждения о том, что будет. Может, и будет, но лучше бы, если бы могли сказать "есть".

Дальше — больше. Постоянно упирают на то, что у них широкие команды и в них выполняются несколько действий. Но почему-то ни слова о том, что нечто аналогичное в x86/x64 есть под названием SSEi и ничего не сказано, исполнялись ли тесты на x86/64 в SSE варианте или нет. А это, сам понимаешь, в 4 раза изменяет примерно. Не говоря уж о том, что о распараллеливании на ядра процессора для x86/x64 там вообще ни слова.

В общем, пока я не увижу данных по сравнению из независимых источников, я подожду оценивать этот процессор.
With best regards
Pavel Dvorkin
Re[39]: по ссылке
От: vdimas Россия  
Дата: 15.04.10 10:18
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Дальше — больше. Постоянно упирают на то, что у них широкие команды и в них выполняются несколько действий. Но почему-то ни слова о том, что нечто аналогичное в x86/x64 есть под названием SSEi и ничего не сказано, исполнялись ли тесты на x86/64 в SSE варианте или нет. А это, сам понимаешь, в 4 раза изменяет примерно.


В 4 раза никакого прироста быстродействия на практике ты не получаешь, это точно такие же лозунги. Я, например, после перекомпиляции кодеков на SSE/SSE2 получил, максимум 30-50%. Чтобы получить быстродействие в 4 раза, надо такую задачу подобрать, чтобы она использовала все дополнительных 100% регистров, и без них бы работала в 4 хуже.

Например, для фильтра 2-го порядка нужно всего 3 промежуточных регистра, в итоге на обычных "старых" регистрах получаем практически идентичное быстродействие, и тут нам SSE не помогает. Так же он не помогает, если не хватает регистров SSE, т.е. если приходится на каждом цикле алгоритма загружать и сохранять данные. В принципе, там весь выигрыш — это в большом файле регистров, где каждый может оперировать с каждым, т.е. не надо использовать "бутылочное горлышко" в виде едиственного аккумулятора и не надо (если хватает регистров) сохранять в памяти промежуточные результаты на каждой итерации цикла. Т.е. даже для БПФ на 1024 отсчета SSE не дает ощутимую прибавку.

PD>Не говоря уж о том, что о распараллеливании на ядра процессора для x86/x64 там вообще ни слова.


Ну лично я играл с распараллеливанием и на этом сайте тоже полно обсуждений экспериментов. Хорошо параллелить получается только независимые вычисления. Т.е. перемножение матриц до 500x500 параллелить пока бесполезно, ибо практически нет толка — затраты на запуск потоков и их синхронизацию съедает все бенефиты. До тех пор, пока примитивы синхронизации обслуживаются программно через шедуллер ОС, паралельное исполнение на независимых ядрах имеет весьма ограниченное применение.


PD>В общем, пока я не увижу данных по сравнению из независимых источников, я подожду оценивать этот процессор.


К сожалению не увидишь, ибо он существует в партиях из сотен/единиц тысяч штук. Очевидно, что следующее, что мы будем оценивать от наших разработчиков — это сервера и суперЭВМы на итаниумах.
Re[40]: по ссылке
От: Pavel Dvorkin Россия  
Дата: 15.04.10 10:40
Оценка:
Здравствуйте, vdimas, Вы писали:

PD>>Дальше — больше. Постоянно упирают на то, что у них широкие команды и в них выполняются несколько действий. Но почему-то ни слова о том, что нечто аналогичное в x86/x64 есть под названием SSEi и ничего не сказано, исполнялись ли тесты на x86/64 в SSE варианте или нет. А это, сам понимаешь, в 4 раза изменяет примерно.


V>В 4 раза никакого прироста быстродействия на практике ты не получаешь, это точно такие же лозунги. Я, например, после перекомпиляции кодеков на SSE/SSE2 получил, максимум 30-50%. Чтобы получить быстродействие в 4 раза, надо такую задачу подобрать, чтобы она использовала все дополнительных 100% регистров, и без них бы работала в 4 хуже.


Отчасти верно. Но все же им надо было упомянуть. Может, и у них то же самое будет. Поэтому я и говорю — давайте результаты, а не рассуждения.

PD>>Не говоря уж о том, что о распараллеливании на ядра процессора для x86/x64 там вообще ни слова.


V>Ну лично я играл с распараллеливанием и на этом сайте тоже полно обсуждений экспериментов. Хорошо параллелить получается только независимые вычисления. Т.е. перемножение матриц до 500x500 параллелить пока бесполезно, ибо практически нет толка — затраты на запуск потоков и их синхронизацию съедает все бенефиты. До тех пор, пока примитивы синхронизации обслуживаются программно через шедуллер ОС, паралельное исполнение на независимых ядрах имеет весьма ограниченное применение.


У меня другие данные. Я писал распараллеливание некоторого матричного алгоритма порядка N^2*M, где M << N. В итоге скорость на моей рабочей двухядерной машине увеличилась почти в 2 раза, а на машине заказчика (4 ядра) — в 3 раза. Правда, алгоритм позволял провести распараллеливание так, что разные потоки практически не имели общих данных. Да, именно независимые вычисления.

Насчет перемножения матриц — не уверен. Если сделать так, чтобы потоки друг другу кэш не сбрасывали, думаю, можно получить эффект. Не в 4 раза, да, но все же.

PD>>В общем, пока я не увижу данных по сравнению из независимых источников, я подожду оценивать этот процессор.


V>К сожалению не увидишь, ибо он существует в партиях из сотен/единиц тысяч штук.


Ну и что ? Ты же мне дал ссылку, где они его вроде как представляют не как разработку, а как изделие. Причем изделие, которым заинтересовался Интел. Почему же никто не купил ее и не попробовал ? Даже одной тысячи штук вполне достаточно. Или же ты оговорился и слово "тысяч" тут по ошибке ?

>Очевидно, что следующее, что мы будем оценивать от наших разработчиков — это сервера и суперЭВМы на итаниумах.


Аллах его знает. Напомню, что Итаниум проектировался не только для серверных платформ, а как вообще замена x86. Ничего из этого не вышло и , теперь уж ясно, не выйдет. x86 сумела за себя постоять, став x64. Не исключаю, что и Итаниум окажется тупиковым направлением. Во всяком случае реально его очень мало, а уже сколько лет прошло с момента его появления !


Кстати, вспомни Intel APX 432, который должен был заменить 8086.

http://ru.wikipedia.org/wiki/Intel_iAPX_432

Где он и какова его судьба ?
With best regards
Pavel Dvorkin
Re[39]: и все же.
От: vdimas Россия  
Дата: 15.04.10 11:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

V>>ЧТО меряют? Еще раз большими буквами: что именно ими меряют и как ты предлагаешь использовать бенчмарки для сравнения несовместимых архитектур? Я вот себе даже представить этого не могу.


PD>http://en.allexperts.com/e/d/dh/dhrystone.htm


Это устаревший вариант SPEC.int.


PD>http://en.allexperts.com/e/w/wh/whetstone_(benchmark).htm


А это один из тех самых примерно 30-ти бенчмарков, которые от балды.


PD>Именно эти величины (MDIPS и MWIPS) мне FreshDiagnose и показывает. Там на рисунке есть комбобокс, сейчас там Speed — нечто интегральное. Другие варианты — MDIPS и MWIPS.


Нечто интегральное...

Любые тесты на современных архитектурах зависят от характера задачи, принятой в качестве теста. Поэтому лично для меня показатели какого-то одного синтетического теста не говорят ничего. Поэтому и популярны не столько бенчмарки процессоров, сколько систем на их основе, поэтому одни из самых популярных бенчмарков — это трассировка лучей и сжатие данных. Но по ним как раз сложно оценивать быстродействие именно процессора. Поэтому единственные тесты, к которым можно аппелировать — это признаные организацией SPEC. Тестов SPEC много, но по каждому из них хоть есть четкое описание, что именно они измеряют и как, в отличие от 99% бенчмарков, результаты которых неизменно в попугаях и пригодны лишь для сравнительной оценки аналогичных архитектур.


V>>Дело в том, что разные тесты бенчмарков ВСЕГДА дают разные сравнительные результаты. Когда был бум частот и я следил за соревнованиями Интел vs АМД, то часто видел, что на одних бенчмарках до 30% выигрывал Интел, на других тестах на столько же был счет в пользу АМД. Поэтому, еще раз, давай ты встряхнешься и задашь вопрос более осознанно — что именно ты хочешь замерять?


PD>Реальное быстродействие этого процессора. И мне нет дела до того, что разные тесты дают разные результаты. Это все верно, но только пока мы в рамках сравнимого. Хоть какие тесты не бери, ни один из них не покажет, что Pentium III — 500 быстрее современного процессора.


Ты так уверен?
Пентиум III-S 1.0 GHz в свое время на многих бенчмарках легко делал P4 1.5 GHz, а тот, в свою очередь, на остальных со значительным отрывом делал первого. А трехлетний Core2 делает на некоторых тестах свежевышедшую систему на i9. В общем, результаты тестов Эльбруса, показанные при журналистах, колебались от производительности P3-500 (в режиме его эмуляции, блин!) до P4-2000. Этого тебе мало? Ну построй график сам. Или поищи в интернете, там на разных тестах показаны сравнительные графики, если уж так интересны именно графики.

Ты можешь не соглашаться сколь угодно. Тебе же все-равно, что процессор на 300МГц эмулирует другой процессор, и даже в этом режиме сравним с показателями эмулируемого при работе на 500 МГц. Ты вообще, где-нить подобное видел? Я в свое время занимался разработкой эмуляторов для однокристалок, сейчас у меня обычно пара виртуалок тоже крутиться, с другими версиями виндов или линухами... Быстродействие программ в виртуалках значительно ниже, в родной среде. Поэтому показанное не просто круто, а отвал башки.


V>>Повторю, я вообще плохо понимаю, как можно пользоваться графиками, когда по осям не указаны размерности.


PD> По оси Y — либо MDIPS, либо MWIPS, либо некий интегральный Speed.


PD>Еще вопросы есть ?


Да, что за алгоритм Speed, его характеристики, что именно он меряет? Скорость подкачки вещественных чисел? Работу предсказателя ветвлений? Работу кэша какого-нить уровня? Сравнение строк? БПФ? ..?


PD>А как же в статье, что ты привел, такое сравнение проводится ?


Угу, мало того, так еще и сами тесты адаптируются, чтобы выглядеть хорошо на Эльбрусе.
Я не привел д-кт сразу, ибо тесты там и синтетические и доморощенные... зато каждый тест подробно расписан, все адаптации популярных тестов и алгоритмов честно расписаны (если применялись), и ты можешь видеть, на каких задачах он хорош, а на каких — не очень. Т.е. этот отчет интересен для специалистов и просто глубоко интересующимся. Т.к. я увлекаюсь обработкой сигналов и занимаюсь ей по работе — мне более чем интересно.


PD>О господи! Ну и аргументы.


Ну а какими словами тебе еще сказать про разбросы в бенчмарках? Ну как можно ориентироваться на данные измерений при разбросе результатов +-50%?


V>>Сказать честно, мне точные данные не нужны и я не понимаю, зачем они нужны тебе. Разброс +-20% абсолютно ничего не покажет


PD>Верно. Но я не уверен в том, что разброс не будет в 200%.


А он и есть более чем в 200%. До 600-700% процентов производительности дает применение архитектуры VLIW на многих классах задач, но не на всех, и это тоже надо понимать. По-сути, сравнивать надо было с процом на обычной архитектуре на той же частоте и безо-всякой эмуляции, чтобы видеть "архитектурный" прирост производительности. И такие приведенные данные тоже в том док-те даны. Было бы кому интересно...

Повторюсь, для военных применений, где траектории расчитываются, дифуры решаются и т.д. — это очень и очень подходящая рабочая лошадка со смешным энергопотреблением. Ведь реально сейчас купить готовое оборудование для производства по технологиям, позволяющим поднять тактовую до 1.5 ГГц, т.е. в 5 раз (!!!), и, учитывая скромное кол-во транзисторов на ядро, на том же кристалле размещать их по 4 штуки. Собсно, это и декларировалось в планах дальнейшего развития, дело лишь за заказчиком... А в России, как и везде, такой не вовремя кризис.
Re[40]: по ссылке
От: Pavel Dvorkin Россия  
Дата: 15.04.10 11:19
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ну лично я играл с распараллеливанием и на этом сайте тоже полно обсуждений экспериментов. Хорошо параллелить получается только независимые вычисления. Т.е. перемножение матриц до 500x500 параллелить пока бесполезно, ибо практически нет толка — затраты на запуск потоков и их синхронизацию съедает все бенефиты.


Вот сейчас тест набросал и сам удивился.

Качество кода не критиковать. Писалось на скорую руку.



#include "stdafx.h"
#include "windows.h"
#include "process.h"

const int N = 500;
double a[N][N], b[N][N],c[N][N];
int nProc;

unsigned int WINAPI ThreadFunc(LPVOID lpV)
{
    int n = (int) lpV;
    for (int i = n; i < n + N / nProc; i++)
        for (int j = 0; j < N; j++)
            for (int k = 0; k < N; k++)
                c[i][j] += a[i][k] * b[k][j];
        return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dt1 = GetTickCount();

    for(int i = 0; i < N; i++)
        for(int j = 0; j < N; j++)
        {
            a[i][j] = b[i][j] = i + j;
            c[i][j] = 0;
        }


    for (int i = 0; i < N; i++)
        for (int j = 0; j < N; j++)
            for (int k = 0; k < N; k++)
                c[i][j] += a[i][k] * b[k][j];

    DWORD dt2 = GetTickCount();
    printf("%d\n", dt2 - dt1);

    for(int i = 0; i < N; i++)
        for(int j = 0; j < N; j++)
            c[i][j] = 0;

    HANDLE hThread[4];
    SYSTEM_INFO si;
    GetSystemInfo(&si);
    nProc = si.dwNumberOfProcessors;
    for(int i = 0; i < 4; i++)
        hThread[i] = (HANDLE)_beginthreadex(NULL, 0, ThreadFunc,(void*)(i * N / nProc),0,NULL);
    WaitForMultipleObjects(4, hThread, TRUE, INFINITE);
    dt1 = GetTickCount();


    printf("%d\n", dt1 - dt2);
    return 0;
}


Печатает 265 и 78.

Phenom II 955, 4 cores, 4GB
VS 2010 SP1 Release
With best regards
Pavel Dvorkin
Re[40]: и все же.
От: Pavel Dvorkin Россия  
Дата: 15.04.10 11:39
Оценка:
Здравствуйте, vdimas, Вы писали:

PD>>http://en.allexperts.com/e/d/dh/dhrystone.htm


V>Это устаревший вариант SPEC.int.


Я в курсе. Ну что же, давай значения по SPEC. Я попробую найти программу, которая их у меня меряет.
Только опять же, полученные независимыми экспертами. Вот Fresh Diagnose, прямо скажем, до моего оборудования дела нет, они его не разрабатывали, поэтому им ни преувеличивать, ни приуменьшать не надо. Независимые эксперты.


PD>>http://en.allexperts.com/e/w/wh/whetstone_(benchmark).htm


V>А это один из тех самых примерно 30-ти бенчмарков, которые от балды.


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


PD>>Именно эти величины (MDIPS и MWIPS) мне FreshDiagnose и показывает. Там на рисунке есть комбобокс, сейчас там Speed — нечто интегральное. Другие варианты — MDIPS и MWIPS.


V> Нечто интегральное...


Ну не придирайся. Есть 2 вполне определенные величины, ну и еще одна прибросочная. Не вижу тут ничего плохого.



PD>>Реальное быстродействие этого процессора. И мне нет дела до того, что разные тесты дают разные результаты. Это все верно, но только пока мы в рамках сравнимого. Хоть какие тесты не бери, ни один из них не покажет, что Pentium III — 500 быстрее современного процессора.


V>Ты так уверен?

V>Пентиум III-S 1.0 GHz в свое время на многих бенчмарках легко делал P4 1.5 GHz, а тот, в свою очередь, на остальных со значительным отрывом делал первого. А трехлетний Core2 делает на некоторых тестах свежевышедшую систему на i9. В общем, результаты тестов Эльбруса, показанные при журналистах, колебались от производительности P3-500 (в режиме его эмуляции, блин!) до P4-2000. Этого тебе мало?

Да.


>Ну построй график сам. Или поищи в интернете, там на разных тестах показаны сравнительные графики, если уж так интересны именно графики.


Интересны. Для Эльбруса, полученные независимыми исследователями. Остальное не интересно.

V>Ты можешь не соглашаться сколь угодно. Тебе же все-равно, что процессор на 300МГц эмулирует другой процессор, и даже в этом режиме сравним с показателями эмулируемого при работе на 500 МГц.


Про SSE опять решил не упоминать ?


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


Для твоего сведения — в виртуалках большинство команд просто исполняется, а вовсе не эмулируется. А быстродействие там ниже не только по этой причине.



PD>> По оси Y — либо MDIPS, либо MWIPS, либо некий интегральный Speed.


PD>>Еще вопросы есть ?


V>Да, что за алгоритм Speed, его характеристики, что именно он меряет? Скорость подкачки вещественных чисел? Работу предсказателя ветвлений? Работу кэша какого-нить уровня? Сравнение строк? БПФ? ..?


Не юродствуй. Кроме Speed там еще 2 метода, о которых ты такое не скажешь.

V>Угу, мало того, так еще и сами тесты адаптируются, чтобы выглядеть хорошо на Эльбрусе.

V>Я не привел д-кт сразу, ибо тесты там и синтетические и доморощенные... зато каждый тест подробно расписан, все адаптации популярных тестов и алгоритмов честно расписаны (если применялись), и ты можешь видеть, на каких задачах он хорош, а на каких — не очень. Т.е. этот отчет интересен для специалистов и просто глубоко интересующимся. Т.к. я увлекаюсь обработкой сигналов и занимаюсь ей по работе — мне более чем интересно.

Бога ради.


PD>>О господи! Ну и аргументы.


V>Ну а какими словами тебе еще сказать про разбросы в бенчмарках? Ну как можно ориентироваться на данные измерений при разбросе результатов +-50%?


Можно, если ожидается плюс-минус двести. Тебе напомнить сравнение двух средних из теории вероятности ?

V>Повторюсь, для военных применений, где траектории расчитываются, дифуры решаются и т.д. — это очень и очень подходящая рабочая лошадка со смешным энергопотреблением. Ведь реально сейчас купить готовое оборудование для производства по технологиям, позволяющим поднять тактовую до 1.5 ГГц, т.е. в 5 раз (!!!), и, учитывая скромное кол-во транзисторов на ядро, на том же кристалле размещать их по 4 штуки. Собсно, это и декларировалось в планах дальнейшего развития, дело лишь за заказчиком... А в России, как и везде, такой не вовремя кризис.


Ладно, давай заканчивать тут. Еще раз — мое мнение, что дело тут не в кризисе, и не в "развале", и не в 90-х, а в гораздо более глубинных факторах, которые не давали нам делать качественную аппаратуру в 70-е — 80-е и не дали бы сейчас при любых условиях в экономике. О причинах я уже говорил. Ты не согласен. Предлагаю на этом и закончить.
With best regards
Pavel Dvorkin
Re[41]: по ссылке
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.04.10 11:45
Оценка: 9 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, vdimas, Вы писали:


>>Очевидно, что следующее, что мы будем оценивать от наших разработчиков — это сервера и суперЭВМы на итаниумах.


PD>Аллах его знает. Напомню, что Итаниум проектировался не только для серверных платформ, а как вообще замена x86. Ничего из этого не вышло и , теперь уж ясно, не выйдет. x86 сумела за себя постоять, став x64. Не исключаю, что и Итаниум окажется тупиковым направлением. Во всяком случае реально его очень мало, а уже сколько лет прошло с момента его появления !


И МС объявила об окончании поддержки Итаниума для Windows Server
Re[42]: по ссылке
От: Pavel Dvorkin Россия  
Дата: 15.04.10 11:51
Оценка:
Здравствуйте, Курилка, Вы писали:

К>И МС объявила об окончании поддержки Итаниума для Windows Server


Очень интересно. Кстати, вот оригинальное сообщение.

http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server-2008-r2-to-phase-out-itanium.aspx

Вот оттуда

Windows Server 2008 R2 will be the last version of Windows Server to support the Intel Itanium architecture. SQL Server 2008 R2 and Visual Studio 2010 are also the last versions to support Itanium.
...
Why the change? The natural evolution of the x86 64-bit (“x64”) architecture has led to the creation of processors and servers which deliver the scalability and reliability needed for today’s “mission-critical” workloads. Just this week, both Intel and AMD have released new high core-count processors, and servers with 8 or more x64 processors have now been announced by a full dozen server manufacturers. Such servers contain 64 to 96 processor cores, with more on the horizon.

Microsoft will continue to focus on the x64 architecture, and it’s new business-critical role, while we continue to support Itanium customers for the next 8 years as this transition is completed.

Dan Reger
Senior Technical Product Manager
Windows Server

Все. Конец.
With best regards
Pavel Dvorkin
Re[41]: исправляю
От: Pavel Dvorkin Россия  
Дата: 15.04.10 12:06
Оценка:
Говорю же — писалось на скорую руку. Сначала захардкодил там 4 как число ядер, потом решил исправить, но исправил не везде

#include "stdafx.h"
#include "windows.h"
#include "process.h"

const int N = 500;
double a[N][N], b[N][N],c[N][N];
int nProc;

unsigned int WINAPI ThreadFunc(LPVOID lpV)
{
    int n = (int) lpV;
    for (int i = n; i < n + N / nProc; i++)
        for (int j = 0; j < N; j++)
            for (int k = 0; k < N; k++)
                c[i][j] += a[i][k] * b[k][j];
        return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dt1 = GetTickCount();

    for(int i = 0; i < N; i++)
        for(int j = 0; j < N; j++)
        {
            a[i][j] = b[i][j] = i + j;
            c[i][j] = 0;
        }


    for (int i = 0; i < N; i++)
        for (int j = 0; j < N; j++)
            for (int k = 0; k < N; k++)
                c[i][j] += a[i][k] * b[k][j];

    DWORD dt2 = GetTickCount();
    printf("%d\n", dt2 - dt1);

    for(int i = 0; i < N; i++)
        for(int j = 0; j < N; j++)
            c[i][j] = 0;

    HANDLE hThread[4];
    SYSTEM_INFO si;
    GetSystemInfo(&si);
    nProc = si.dwNumberOfProcessors;
    for(int i = 0; i < nProc; i++)
        hThread[i] = (HANDLE)_beginthreadex(NULL, 0, ThreadFunc,(void*)(i * N / nProc),0,NULL);
    WaitForMultipleObjects(nProc, hThread, TRUE, INFINITE);
    dt1 = GetTickCount();


    printf("%d\n", dt1 - dt2);
    return 0;
}




Проверил на Athlon 4200+, 2 cores, 2 GB

640 и 390.
With best regards
Pavel Dvorkin
Re[41]: по ссылке
От: vdimas Россия  
Дата: 15.04.10 12:24
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

А попробуй прогнать при N=200, 300.

Что-то слишком большая разница у тебя, похоже все дело в том, что в этом новом проце кеш 6МВ, это ровно столько сколько 8*500*500*3. (даже еще чуть останется)
В общем, угадали с этими 500.

У меня получалось на двухядерном примерно 20% разницы для 300 и примерно 30% для 500.
Ну и опять же, эта задача как раз из тех, которая легко разбивается на независимые подзадачи.

Когда я пытался параллелить видео-кодек, где кадр 320*200, то параллельный вариант практически ничего не дал, т.е. я зря отнимал ресурсы системы (которые обслуживают еще и аудиокодек), и отбросил эту затею.
Re[42]: по ссылке
От: Pavel Dvorkin Россия  
Дата: 15.04.10 12:32
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:


V>А попробуй прогнать при N=200, 300.


Не получилось. В пределах точности GetTickCount. Исправлять не буду.

При 400 125 и 47

При 1000 11403 и 3401.

в общем, все так же.

V>Что-то слишком большая разница у тебя, похоже все дело в том, что в этом новом проце кеш 6МВ, это ровно столько сколько 8*500*500*3. (даже еще чуть останется)


Не пойдет. См мой тест на Athlon 2 core 3-летней давности

http://rsdn.ru/forum/education/3775892.1.aspx
Автор: Pavel Dvorkin
Дата: 15.04.10



V>В общем, угадали с этими 500.


500 тут ни при чем.

V>У меня получалось на двухядерном примерно 20% разницы для 300 и примерно 30% для 500.


Какой процессор ?

V>Ну и опять же, эта задача как раз из тех, которая легко разбивается на независимые подзадачи.


Конечно.

V>Когда я пытался параллелить видео-кодек, где кадр 320*200, то параллельный вариант практически ничего не дал, т.е. я зря отнимал ресурсы системы (которые обслуживают еще и аудиокодек), и отбросил эту затею.


Все может быть.
With best regards
Pavel Dvorkin
Re[34]: Российская кремниевая долина - насколько реально?
От: kig Россия  
Дата: 15.04.10 12:47
Оценка:
Здравствуйте, vdimas, Вы писали:

V>

V>Информационная и программная совместимость с наиболее распространенными в мире ЭВМ, являвшимися де-факто мировыми стандартами была достигнута в трудных условиях отсутствия документации и работающих образцов машин IBM-360.


V>Вообще, я боюсь даже представить объем работ, чтобы при отсутствии спецификаций и работающих прототипов, только имея на руках двоичные коды операционки, разработать под эти коды железку и около 70-ти перифейрийных устройств!!!


Спецификации и железки через третьи страны все же тащили. Не все могли утащить, но тащили.
А операционки в большей своей части шли в исходниках. VM/370 — VM/SP до середины 80х вообще полностью в исходниках были — CP, CMS, апликухи — XEDIT, REXX, компиляторы.
Re[41]: и все же.
От: vdimas Россия  
Дата: 15.04.10 13:05
Оценка: 6 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я в курсе. Ну что же, давай значения по SPEC. Я попробую найти программу, которая их у меня меряет.

PD>Только опять же, полученные независимыми экспертами. Вот Fresh Diagnose, прямо скажем, до моего оборудования дела нет, они его не разрабатывали, поэтому им ни преувеличивать, ни приуменьшать не надо. Независимые эксперты.

Как это независимые? Ты запускаешь готовый бинарник под x86. Совсем другое дело заготовить такой же тест для другой архитектуре. Вон там с перемножением матриц как у тебя вышло из-за 6МГ кеша, что опять же говорит — не только в самом проце дело. А хотелось померить именно процы.

PD>Ты никак понять не хочешь. От балды так от балды. Черт с ним. Пусть точность этих данных оставляет желать лучшего. Но когда я, как пользователь, буду выбирать себе новый компьютер, я на эти тесты буду ориентироваться в плане соотношения производительности и стоимости. Черт знает, что они отражают, но они хоть что-то отражают и, в общем, тенденцию мне дают. Болльшего мне и не надо.


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

PD>>>Именно эти величины (MDIPS и MWIPS) мне FreshDiagnose и показывает.



V>>Ты можешь не соглашаться сколь угодно. Тебе же все-равно, что процессор на 300МГц эмулирует другой процессор, и даже в этом режиме сравним с показателями эмулируемого при работе на 500 МГц.


PD>Про SSE опять решил не упоминать ?


Ну ты же упоминаешь, а у меня нет данных.


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


PD>Для твоего сведения — в виртуалках большинство команд просто исполняется, а вовсе не эмулируется.


Разумеется, иначе разница была бы не в 2-3 раза в виртуалке, а в 15-30 раз. И это я тебе должен был напомнить, ибо в случае Эльбруса как раз эмулируется чуждая система команд. Просто все эти технологии, аналогичные JIT, немного стирают грань м/у интерпретацией и нативным исполнением перекомпиллированного кода, и не хотел уводить обсуждение в эту сторону.

PD>А быстродействие там ниже не только по этой причине.


По причине эмуляции аппаратуры, виртуальной памяти, всех DMA, а так же "честной" эмуляции всех привилегированных команд, но это не суть. Даже на совместимой архитектуре мы получаем заметное проседание производительности в случае эмуляции.


PD>Ладно, давай заканчивать тут. Еще раз — мое мнение, что дело тут не в кризисе, и не в "развале", и не в 90-х, а в гораздо более глубинных факторах, которые не давали нам делать качественную аппаратуру в 70-е — 80-е и не дали бы сейчас при любых условиях в экономике. О причинах я уже говорил. Ты не согласен.


Да какой там глубинный фактор. С середины 80-х стали урезать расходы на наш IT. До этого, еще в начале 40-х, кибернетика была объявлена лженаукой, и пока бомбу разрабатывать не стали, своего IT просто не было. Мы объективно начали на 10 лет позже развиваться в этом направлении, но постепенно сокращали отставание. Даже в периоды самого лучшего финансирования этого сектора, в конце 70-х начала 80-х, мы по общим инвестициям в эту область отставали на порядок-другой, и тем не менее умудрялись медленно, но верно сокращать разрыв. И тебе, как химику, не удержусь уколоть, что проблемы низкой надежности наших интегральных микросхем исключительно и полностью лежат на совести химиков, которые разрабатывали пластик для корпусов ИС. Сами ИС выходили из строя в результате разгерметизации, и этот порок наших микросхем, так же как и других наших элементов с пластиковым корпусом, был бичом до середины-конца 80-х. Все что шло в керамике или металле — работало отлично, но это дорого и было в основном для военных (до сих пор работает). Тоже самое касается печатных плат.

Я вообще считаю, что при таком финансировании мы умудрялись делать системы мирового уровня только благодаря нашей научной школе. Во всем мире нас опережали в IT только одна страна, которая нехило разбогатела на той войне и ее последствиях. И вот, самая пострадавшая в войне страна довольно быстро выходит на 2-е место в мире по развитию IT в условиях скудного финансирования этой отрасли... Да, некий "глубинный фактор" тут должен был быть, чтобы достигнуть таких впечатляющих результатов, но те тот, о котором ты думаешь. И разработка самой удачной архитектуры VLIW на сегодня — следствие того же самого фактора.
Re[42]: и все же.
От: Pavel Dvorkin Россия  
Дата: 15.04.10 13:09
Оценка:
Здравствуйте, vdimas, Вы писали:

PD>>Только опять же, полученные независимыми экспертами. Вот Fresh Diagnose, прямо скажем, до моего оборудования дела нет, они его не разрабатывали, поэтому им ни преувеличивать, ни приуменьшать не надо. Независимые эксперты.


V>Как это независимые?


Очень просто. Независимые — не от группы Эльбрус.

>Ты запускаешь готовый бинарник под x86. Совсем другое дело заготовить такой же тест для другой архитектуре. Вон там с перемножением матриц как у тебя вышло из-за 6МГ кеша


Кэш там ни при чем, точнее, не из-за него, так как на Athlon вышло то же самое, то есть в 2 раза. Я тебе об этом писал. Либо ты не читал, либо...


>что опять же говорит — не только в самом проце дело. А хотелось померить именно процы.


Дело именно в проце. А матричный тест предложил ты, а не я.

Ладно, все же хватит.
With best regards
Pavel Dvorkin
Re[43]: по ссылке
От: vdimas Россия  
Дата: 15.04.10 13:16
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все. Конец.


Конец чего?
PowerPC майкрософтом тоже не поддерживается, но на нем прекрасно строят суперЭВМ.
Под IA64 вообще нужен специальный компилятор, которого нет у MS и все приложения и по любому на нем не шли. Это ДРУГАЯ архитектура без всякой надежды на нативную поддержку x86-й.

В общем, посмотрим, как оно будет. На моей памяти AMD второй раз по-крупному делает Интеллу подножку, предлагая "переходные" решения.
Re[43]: Российская кремниевая долина - насколько реально?
От: vdimas Россия  
Дата: 15.04.10 13:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

V>>Успел и я на 1020 посидеть, но правда феррита уже там не было, хоть я и видел его в подсобке.


PD>Я эту ссылку специально для тебя нашел. Когда писал о ферритах — я ее не знал. Просто помню, что однажды спрсил у инженеров ВЦ, что там за память.


В твоей ссылке — год выпуска книги, а не год выпуска серии 1020. Когда вышла книга, на замену вышедшим из строя модулям памяти уже шли модули с динамической. Если же память не поломалась, то зачем ее менять?

PD>Довелось. ЕС-1045. СВМ ЕС. 1990-91 год.


Неплохая машинка, только поздновато к вам дошла.

PD>Впечатления. Висла каждые 20-30 минут. А вот про СВМ остались неплохие воспоминания. ОС ЕС я знал неплохо, а СВМ не знал совсем. Прочитал какое-то введение, сел и все сразу получилось. Для 1990 года совсем неплохо.

PD>Впрочем, опыт был очень небольшой.

У нас ничего не висло. Вернее, пару раз я такое видел, но у меня и персоналки периодически виснут.
Re[43]: добавлю
От: vdimas Россия  
Дата: 15.04.10 13:28
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Через пару лет меня попросили написать обоснование на списание этой машины. Немного работы я с таким удовольствием делал, как это обоснование.


Согласен, на PDP-11 архитектуре неплохо получились только персоналки ДВК. Жаль, что опоздали с ними буквально на 5 лет.
Re[35]: Российская кремниевая долина - насколько реально?
От: vdimas Россия  
Дата: 15.04.10 13:42
Оценка:
Здравствуйте, kig, Вы писали:

kig>Спецификации и железки через третьи страны все же тащили. Не все могли утащить, но тащили.


Насколько я понял, ни процессора, ни блока памяти не было. А от накопителей да перфораторов толку немного.


kig>А операционки в большей своей части шли в исходниках. VM/370 — VM/SP до середины 80х вообще полностью в исходниках были — CP, CMS, апликухи — XEDIT, REXX, компиляторы.


Все-равно, восстанавливать спецификации по исходникам — это тот еще геммор. Вот я тебе дам программу в исходниках на С, много ты спецификаций процессора и архитектуры восстановишь? Меня удивляет уверенность некоторых, что слизали вплоть до схемотехники. Как раз схемотехника там относительно проста и слизывать ее незачем, гораздо сложнее было восстановить спецификации, которым разрабатываемая железка должна удовлетворять. В этом плане AMD было легче клонировать Интелл, ибо подробные спецификации открыты.
Re[44]: по ссылке
От: Курилка Россия http://kirya.narod.ru/
Дата: 15.04.10 14:17
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Все. Конец.


V>Конец чего?

V>PowerPC майкрософтом тоже не поддерживается, но на нем прекрасно строят суперЭВМ.
V>Под IA64 вообще нужен специальный компилятор, которого нет у MS и все приложения и по любому на нем не шли. Это ДРУГАЯ архитектура без всякой надежды на нативную поддержку x86-й.

V>В общем, посмотрим, как оно будет. На моей памяти AMD второй раз по-крупному делает Интеллу подножку, предлагая "переходные" решения.


А первый какой?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.