• По ту сторону закона Мура
    0
    Интел не отстанет. :) HT — это попытка прятать лаетнтности почти по той же схеме, по какой ее прячут GPGPU. В каком то смысле это шаг в правильном направлении. Только вот почти все HPC, которое я вижу ее отключает…
  • По ту сторону закона Мура
    0
    именно поэтому программирование должно совершить революцию, а не просто не программировать лучше.

    Да я уже даже готов согласиться. Только вот подумаю, сколько софта придется портировать и такая тоска меня берет… :)
  • По ту сторону закона Мура
    0
    память сейчас сильно ускорится с выходом ДДР5 так что я думаю память догонит процессор

    Это хорошее замечание -догнать конечно не догонит, но жить станет определенно легче :)
  • По ту сторону закона Мура
    0

    Давайте помогу с написанием. У меня более или менее сносно получается формулировать мысли :)

  • По ту сторону закона Мура
    0
    Опять не понял. Зачем все затачивать под одну частоту?
    Я тока говорил, что жизнь становится сложнее по мере того, как растет разрыв по скорости между процессором и памятью.
    и насчет того что для балансировки надо выбирать софт тоже согласен. Но и это тоже становится все сложнее и сложнее.
  • По ту сторону закона Мура
    0
    ага. вот это интересно было бы почитать :)
    Только лучше не лонг рид :)
  • По ту сторону закона Мура
    0
    Ну еще бы TSMC согласилась с этим. Эпоха перманентынх апгрейдов закончится и ее бизнес похудеет изрядно. Только ыот физические барьеры все сложнее преодолевать.
    А насчет near data — каков размер такой памяти?
  • По ту сторону закона Мура
    0
    Да не только AMD думает про HT 4. Для каких то прилаг (где латентности нужно прятать) это помогает даже. Для HPC как правило HT отключают. Кста, подумал тут что это одна из тех фишек которые приближают СPU к GPU. Я как раз сейчас дкмаю про этот Fusion. Дойдут руки — напишу
  • По ту сторону закона Мура
    0
    Ммм. Я боюсь в этой схеме какой нибудь OpenMP barrier будет просто чудовищно дорогим. Вопрос в том, можно ли как нибудь без них обойтись.
  • ISA ошибок не прощает
    0
    Похоже на то :( Кажется я там писал, что не очень -это еще очень мягко сказано. Работал этот блок медленно а энергии потреблял больше чем все осталное
  • ISA ошибок не прощает
    0
    Такой ад это будет… Даже думать не хочется. Уж лучше бинарная трансляция. Хотя я ее терпеть не могу.
  • По ту сторону закона Мура
    0
    Смотрю щас на нашу поделку с короктими СИМДами (NEON) и бодрым взаимодействием с памятью. Байтов на флоп много. Программисту приятно и разработчику железа тоже. А вот пользователям и маркетологам — увы, по фигу :(
  • ISA ошибок не прощает
    0
    И все препеисать заново?
  • ISA ошибок не прощает
    0
    Да я думаю и запоминать не стоит. Таких стартапов за историю было не счесть :)
  • ISA ошибок не прощает
    0
    У Intel мало разработчиков? Вроде достаточно:) но всё равно работы безумно сложны
    — Много. И Умных. Но каждый копошится в своем углу. Полную картину вряд ли кто то понимает…
  • ISA ошибок не прощает
    0
    Ну как сказать. У BTюна есть драйвера. И фиксить в них баги куда сложнее чем в пользовательском коде. На линуксе — это ужас. На BSD — ужас-ужас…
  • ISA ошибок не прощает
    0
    Ну и по своему опыту могут сказать, что расстановка префетчей в реальных алгоритмах — как мёртвому припарка, эффекта практически нет.

    Cогласен на 99%. Хардварные префетчеры очень четко отрабатывают простые паттерны доступа. Добавить что то поверх них, как правило не выходит.
  • По ту сторону закона Мура
    0
    А когерентность кэшей? Или я не понимаю чего то?
  • ISA ошибок не прощает
    0
    А майкрософт как же? Будет молча плакать в уголке?
  • ISA ошибок не прощает
    0
    «строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке», а не «идём на произвольный другой адрес, на переоткрытии строки теряя 200-300 тактов». Потери такого порядка (самые длительные) компилятору недоступны для понимания и могут быть отработаны только человеком.

    И то не всегда. Мои «любимые» кейсы — вычисления с двойной идексацией. По первому индексу берешь второй из массива (огромного) и ловишь кэш мисс. А потом по этому индексу читаешь данные из другого массива (еще больше). И разумеется ловишь второй. И сделать с этим ничего нельзя. Даже программистов поубивать, потому что код 40 лет назад написан :)
  • ISA ошибок не прощает
    0
    В интелевских процах какой-то уж совсем забубенный и неконтролируемый программистом, хардверный, хаускипинг.

    А уж скока места он занимает — просто кошмар. Но надо сказать, что он адресует много корнер кейсов. Там где простенький анкор AMD зачастую ломается и проседает по производительности, интеловый держится.
  • ISA ошибок не прощает
    0
    Почему бы и нет? Каждому ядру свой канал, например. Не понимаю, почему это должно пугать: при программировании для GPU NUMA уже есть, но есть и инструменты, уменьшающие геморрой.

    А далеко не всегда получается с этим геморроем справиться. Оч сильно от ворклоада зависит.
  • ISA ошибок не прощает
    0
    Но если учесть затраты на программистов, которым нужно больше мозгов и следовательно зарплаты, уже можно подумать
    .
    Часто ловлю себя на мысли, что мне уже мозгов не хватает. То ли я стал настолько старым, то ли программирование стало настолько сложнее. Похоже и то, и другое… :(

  • По ту сторону закона Мура
    0
    И чтобы был быстрый результат, оно должно работать как хорошо настроенный ковеер на заводе. Каждый станок производит ровно столько (не больше не меньше) сколько может переработать следующий станок. То что ядра простаивают ожидая информации из памяти — лишь один из многочисленных примеров бутылочных горлышек в вычислениях.

    Ага. Вот поэтому я и говорил о понижении частоты. Без этого сбалансировать не очень то получается…
  • По ту сторону закона Мура
    0
    Обычный grid. Тут со времён RAW ничего особо лучше не придумать.
    Префетчер должен посылать данные заранее к конкретному ядру.
    Вот над чем нужно думать.
    У меня пока нет ответов на все вопросы, но я и не занимался детальной проработкой.
    Так, скорее пара мыслей крутится.


    Я боюсь, что этот грид будет или затычкой в системе или места занимать в 10 раз больше чем все эти ядра вместе взятые…
  • По ту сторону закона Мура
    0
    PS: Ставьте blockquote (кавычка сверху в редакторе) или хотя бы пробел между цитатой и своими словами — ничего же не понятно.

    Просто попробовать blockquote
  • По ту сторону закона Мура
    0
    Все data flow, которые я пока видел превращались в compiler driven architecture. И у меня сложилось ощущение, что они долго не живут…
  • По ту сторону закона Мура
    0
    Ответил в личку. Давайте там продолжим на эту тему.
    Насчет наших последовательных мозгов — да Бабаян все время мне эту мысль задвигал :)
  • По ту сторону закона Мура
    0
    Думаю сейчас не нужно делать очень длинный конвейер чтобы добиться высокой частоты.
    Для in-order точно не нужно
  • По ту сторону закона Мура
    +1
    Тысячи небольших in-order RISC-ядер имеющих локальную scratchpad SRAM, работающие на 5+GHz + умный префетчер и кэш когерентный DMA.
    Сделать первое не такая большая проблема. Гораздо большая проблема «накормить» эту машину данными. умный префетчер и кэш когерентный DMA. — хорошая затея осталось только сделать :) А как насчет внутрипроцессорной сети? Как эти ядра будут друг с другом коммуницировать?
  • По ту сторону закона Мура
    0
    Это потребует от программистов размышлений над каждой мелочью.При низкой частоте ядер можно рассчитывать только на широкий SIMD и надежду,
    что всё будут делать именно на нём.
    Такое ощущение, что думать над оптимизацией в любом случае придется сильно больше чем раньше. Я кстати даже не про симды — а про серверные приложения где поток ждет данные быстро обрабатывает их и засыпает.
  • По ту сторону закона Мура
    0

    Я тут с точки зрения дизайна железки смотрю. Причём да — железки северной. И дилемма которая иногда возникает, это сделать больше ядер на меньшей частоте или меньше на большей

  • По ту сторону закона Мура
    0
    А почему, если не секрет?
  • По ту сторону закона Мура
    0
    Да я понимаю что понижение частоты — это не очень реалистично. Только если удастся компенсировать за счет чисто железных оптимизаций.
    Мне эта идея нравится с чисто логической точки зрения. Попытка сбалансировать IO и вычислительную мощность. Bytes/flops. Stream/Linpack.
  • По ту сторону закона Мура
    0
    Как Java? Или при установке перекомпиляция все же требуется? А что если я меняю видеокарту? Г Надо пересобирать весь софт?
  • По ту сторону закона Мура
    0
    Все понемножку. Как правило поделки, которые финансируются одним игроком не выживают. Ну а кто то как Red Hat вполне сам зарабатывает деньги.
  • По ту сторону закона Мура
    0
    Wintel?:)
  • ISA ошибок не прощает
    0
    Не зря наняли со стороны специалиста и тот первым делом начал бюрократию разгонять внутри своего куска ответственности)
    Про Келлера?:)
  • ISA ошибок не прощает
    0
    Кто? Маркетологи? :)
  • ISA ошибок не прощает
    0
    Я смотрю на процы довольно просто. По сути все сводится к байтам на флоп. Stream/Linpack :) Мне думается, что самым сбалансированным чипом был Nehalem. Хотя по сравению с нынешними Сандик тоже очень неплохо смотрится…