Выпущена пилотная партия моноблочных ПК на базе микропроцессора «Эльбрус-2С+»

с использованием cache line lock механизмов, но обычно такие инструкции не доступны в user mode (OS может использовать эти вещи для размещения своих таблиц)

казалось бы, почему бы и нет? важно не разрешать юзерспейсу разлочить то, что залочила ос, и обеспечить насильное разлочивание при переключении задач

на х86 это есть?

Я не встречал компиляторы, которые пытаются моделировать поведение cache и предсказывать его состояние. Это чрезвычайно сложная задача сама по себе.

ха, кто бы спорил! понятно, что нужно наоборот — давать компилятору какие-то возможности как-то контролировать кэш

как предлагает www_linux_org_ru, генерировал команды, которые запрашивают текущую нагрузку, и, в зависимости от нее, как-то меняют поток управления

опрашивают не только нагрузку, но и факторы, влияющие на зависимость инструкций; да и вообще, есть кое-какие простые вещи, которые я мог бы засшедулить на то время, пока процессор завис на io ждет операнда из некэшированной оперативки

для VLIW, который ты фактически предлагаешь, никто не написал достаточно хороших компиляторов.

я скорее за epic, чем за vliw — т.е. за размещение в сегменте кода той инфы о зависимостях инструкций, которую долго, или вообще невозможно вычислить планировщику инструкций

Злокачественная маниловщина.

ага-ага, так и будем продолжать пользоваться старьем?

Алгоритмъ американскаго iнженера Томасуло произвел настоящiй фуроръ; самъ императоръ Николай II соизволiл выразить интересъ. [Citation needed]

Почитай тред. Немного выше KT писал, что у них свой компилятор.

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

лучше выставите в интернет почасовой платный kvm на (несколько?) эльбрус(ов?), чтобы можно было работать от root-а и бенчить (загрузка должна осуществляться с какого-то read-only диска или по сети, если он у вас это умеет)

и еще просто (почти бесплатный) многопользовательский ssh на эльбрус (можно без исходящего доступа в интернет с аккаунтов) для того, чтобы освоиться с компилятором и тулчейном

Кстати, я вот что подумал. Ведь на базе Монокуба можно забабахать отличный программно-аппаратный комплекс по цифровой обработке звука например.

Достаточно иметь звуковушку с примитивным, но качественным ЦАП/АЦП. Все остальное будет делаться в реалтайме в недрах Эльбруса-2С+ на его DSP-шных ядрах.

Гитарную примочку с over 9000 эффектами сделать будет не проблема. Этакий реалтаймовый гитарный мегапроцессор. Он же сожрет скока угодно цифири, преобразует гармоники и не подавится. Цена фирменной цифровой примочки с золочеными контактами походу будет даже повыше монокуба. Так что вот вам ниша для гражданского применения.

Слишком дорогая примочка выходит. Вот молотить поток данных через цифровые фильтры и прочие БПФ вполне реально, но вот область применения непонятна. В системах наведения, например, вполне понятно на что можно использовать эти 4 DSP ядра, что они даже давиться будут, но это не гражданское применение.

О, да, видеомонтажная станция. Там тоже можно найти чем нагрузить 4 DSP ядра. Но набор периферии для такого как-то грустноват, да и софта нет.

Кстати, я вот что подумал. Ведь на базе Монокуба можно забабахать отличный программно-аппаратный комплекс по цифровой обработке звука например. ... Гитарную примочку с over 9000 эффектами сделать будет не проблема. Этакий реалтаймовый гитарный мегапроцессор.

а еще монокубом можно гвозди забивать !!!!111

дешевая openCL видеокарта легко переплюнет монокуб по dsp-производительности, возможно даже на порядок

так что выдумывать истории типа:

 — а давайте кота заведем!
 — но он нам не нужен
 — а он мышей будет ловить!
 — но у нас нет мышей
 — а мы заведем!

это явно не ко мне

2. компилятор знает, что [bx] сейчас в кэшах с *определенной* вероятностью

Я не встречал компиляторы, которые пытаются моделировать поведение cache и предсказывать его состояние. Это чрезвычайно сложная задача сама по себе.

на всякий случай уточню, что п.2 встречается достаточно часто: скажем, проц имеет кэш в 4МБ, у нас есть массив в 8МБ, состоящий из структур размером меньше кэш-линии (или даже просто из 4-байтовых целых)

этот массив был ранее заполнен (возможно последовательно), и сейчас мы читаем его в *произвольном* порядке, и при этом в память почти не пишем (или пишем без сохранение в кэш); так как весь массив в кэш не влезет, то после чтения части массива (скажем, 1/8) вероятность найти новое значение в кэше близка к 50%, и нет тут никакой Охрененно Сложной Исследовательской Задачи

я думал, что это очевидно, поэтому и не остановился на этом в первом своем ответе

(да, можно запросить чтение массива без сохранения в кэше, но это только во вред)

другое дело, что ты может быть расскажешь, почему компилятору инфа о 50% бесполезна? в двух разрезах: 1) современная архитектура 2) гипотетическая архитектура с управляемым ooe

tailgunner точно охарактеризовал мои идеи как программно-управляемый ооe

Скажите, когда Вы предлагаете выполнять компиляцию, до исполнения или во время исполнения программы? Иными словами, Вы сторонник статической компиляции или JIT?

просто потому что компилятору доступен полный контекст исполнения и зависимости между данными (системные вызовы и прерывания пока упустим)

мне бы тоже этого хотелось, но это иногда не так из-за aliasing-а

Если это не так, или компилятор не может доказать зависимость, он, очевидно, предполагает независимость и генерирует соответствующий код. Программист может улучшить кодогенерацию с помощью соответствующих pragma statements.

инфа, доступная в рантайме (скажем, что i!=j) должна быть доступной для изменения планирования инструкций

Это и происходит в out-of-order процессорах. Однако, количество и тип инструкций при этом не меняется, меняется лишь их порядок и, потенциально, время исполнения.

где прочитать кратко о платировании инструкций в итаниуме?

Думаю в Itanium Software Developer's Manual.

http://www.intel.com/design/itanium/manuals/iiasdmanual.htm

с использованием cache line lock механизмов, но обычно такие инструкции не доступны в user mode (OS может использовать эти вещи для размещения своих таблиц)

казалось бы, почему бы и нет? важно не разрешать юзерспейсу разлочить то, что залочила ос, и обеспечить насильное разлочивание при переключении задач

Процессор не знает, кто issue инструкцию. Это прерoгатива OS, определять kernel space и user space, и соответственно переводить процессор в исполнение того или иного подмножества инструкций.

на х86 это есть?

Конечно, как же иначе выполять cache coherency и atomic operations.

вероятность найти новое значение в кэше близка к 50%, и нет тут никакой Охрененно Сложной Исследовательской Задачи

хорошо. А как ты собрался извлекать профит из этой информации? Ну будет вероятность 50% того, что [bx] в кеше, дальше что? Сейчас компилятор считает что [bx] _есть_ в кеше, IRL получаем профит, либо штрафные такты, если нету. Штрафные такты исправляются двумя путями: заменой процессора, или уменьшением массива. Третьего пути я не вижу.

понятно, что нужно наоборот — давать компилятору какие-то возможности как-то контролировать кэш

Это хорошо, что Вам понятно, а между разработчиками процессоров и системными программистами нет однозначного ответа на вопрос, нужно ли выдавать полный API для explicit cache data movement в user space или нет. Существуют процессоры и с тем и с иным подходом.

на всякий случай уточню, что п.2 встречается достаточно часто:

Несмотря на приведенный пример, я все равно придерживаюсь первоначального мнения - этот пункт вообще не рассматривается на практике. Компиляторы, с которыми я работал на реальном железе, генерируют код используя только информацию, которую могут доказать. Факт повторного использования load будет использован только если будет доказано, что 1) первоначальное значение не было изменено (а это также означает, что значение не имеет хитрых атрибутов, типа volatile, что оно не является разделяемым между потоками, не явлется частью специальной памяти, mapped в спецадреса, и еще миллион неправдоподобных условий) и 2) значение выгоднее хранить, а не просто перезагрузить второй раз. В случае хранения, нужен или дополнительный регистр, или немедленное использование одного значения в двух инструкциях. В случае дополнительного load, никакие вероятности не считаются и размещение в cache не предполагается.

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

другое дело, что ты может быть расскажешь, почему компилятору инфа о 50% бесполезна?

Да нет, просто уж больно лихо Вы про 50% посчитали.

Во-первых, вероятности будете считать для каждой операции с памятью? Или будете хитро выделять важные и неважные? В первом случае для компилятора нужно заказывать суперкомпьютер. Во втором, можете приобщаться к увлекательным исследованиям о том, как оптимизировать доступ к данным в предметно ориентированных областях. Кстати, очень популярное в pure CS направление.

Во-вторых, как будете учитывать многопоточность? Обычно потоки, работающие на одном ядре разделяют cache и могут вызвать trashing. А могозадчность и многопользовательность? Хорошо, последним пренебрежем.

Вот Вам и «Охрененно простая задача». Было бы все просто, давно бы было реализовано...

Чисто проиллюстрировать предыдущий ответ.

Вот картинка с фактическим доступом к памяти компилятора Фортран.

По Y — адреса (в номерах страниц по 4кб), по Х — номер инструкции, ну или время. (картинка из статьи «Program Restructuring for Virtual Memory», by D.J. Hatfield and J. Gerald)

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

Если у вас какой-нибудь мутный алгоритм на большом графе, который следует по указателям — вы практически обречены, эффективнее построить машину, которая минимизирует latency доступа к памяти, проиграв в чём-то другом.

Но если вам повезло и вы занимаетесь, например, DSP, где паттерн доступа не только не зависит от входных данных вообще, но и в принципе очень легко предсказуем, вот тогда да — тогда явное управление кэшем (а с ним и VLIW, производительность которого во многом зависит от предсказания компилятором того, что лежит в кэше) имеет право на жизнь. По факту, оно именно там и живёт; современные DSP часто (и, видимо, вполне успешно) используют VLIW архитектуру.

Однако, для задач общего плана оно пока уступает out-of-order исполнению.

дешевая openCL видеокарта легко переплюнет монокуб по dsp-производительности

софта то нет.

0. Патчи в ядро будут, или 12309 и отсутствие новых плюшек гарантировано?
2. Что там с совместимостью компилятора (генту без очевидных костылей реально собрать?)?
5. Тысяч 15, но все еще зависит от возможности использования DSP и сборки программ.

0. Если патч важный - мы вносим сами. 2. Gentoo уже сейчас используется. Про костыли не знаю.

0. То есть реально будет например 3.7 запустить на Эльбрусе?
2. Весь софт собирается, разницы с gcc нет?

И что там сейчас можно делать прикладного на DSP?

Вот Вам и «Охрененно простая задача»

я, вообще-то, так не говорил, а был несогласен с тем, что это Охренненно Сложная Исследовательская Задача (причем именно в таком написании — т.е. без кавычек, намекающих на цитирование)

Во-вторых, как будете учитывать многопоточность? Обычно потоки, работающие на одном ядре разделяют cache и могут вызвать trashing.

thrashing?

в той ситуации, которую я обрисовал, можно сказать, что уже один поток вызывает thrashing

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

Штрафные такты исправляются двумя путями: заменой процессора, или уменьшением массива. Третьего пути я не вижу.

хотя бы hyperthreading

если у нас есть гипернить, которая целиком исполняется на регистрах (john-the-ripper например), то она будет исполняться в то время, когда основная гипернить ждет операнда из памяти

хорошо. А как ты собрался извлекать профит из этой информации? Ну будет вероятность 50% того, что [bx] в кеше, дальше что?

контекстом моей фразы был гипотетический epic-like процессор; можно ли извлечь профит из этого на нынешних процах — это вопрос

Скажите, когда Вы

я, вообще-то, привык общаться в обе стороны на «ты» и переучиваться мне лень (хотя ниче не имею против обращения ко мне на «вы»)

Скажите, когда Вы предлагаете выполнять компиляцию, до исполнения или во время исполнения программы? Иными словами, Вы сторонник статической компиляции или JIT?

И мед, и сгущенку, и можно без хлеба. (с) винни-пух

а если серьезно, то все, что можно сделать статически — нужно делать статически

т.е.

1. самое лучшее — статическая компиляция

2. если это не проходит — тогда нужен псевдо-jit, опирающися на железо

3. если это не проходит — тогда псевдо-jit, не опирающися на железо

4. иначе настоящий jit

что я понимаю под п.2 можно понять из кода ниже (неоптимизированная версия — это OPT0; п.2 это OPT2 и OPT3) что такое п.3 объяснять лень

#include <iostream>
#include <vector>

typedef unsigned int uint;
const int it=50000000;
const int len=200;

struct Figure {
  virtual uint area() = 0;
};

struct Rect: public Figure {
  uint x;
  uint y;
  Rect(uint x=1, uint y=1): x(x), y(y) {}
  virtual uint area() { return x+y; } /// cделано для скорости
  static inline uint area_static(Rect* r) { return r->area(); }
};

struct Circle: public Figure { 
  uint radius;
  Circle(uint radius=1): radius(radius) {}
  virtual uint area() { return radius; } /// cделано для скорости
};

#ifdef OPT0
uint func1(std::vector<Figure*> v) {
  uint res = 0;
  for(int i=0; i<it; ++i ) {
    for( auto iterator=v.begin(); iterator!=v.end(); ++iterator ) {
      auto element = *iterator;
      res += element->area();
    }
  }
  return res;
}
#endif

#ifdef OPT1
uint func1(std::vector<Figure*> v) {
  static Rect _rect;
  uint res = 0;
  for(int i=0; i<it; ++i ) {
    for( auto iterator=v.begin(); iterator!=v.end(); ++iterator ) {
      auto element = *iterator;
      if( auto rect_ptr = dynamic_cast<Rect*>(element) ) {
        res += rect_ptr->area();
      }else{
        res += element->area();
      }
    }
  }
  return res;
}
#endif

#ifdef OPT2
uint func1(std::vector<Figure*> v) {
  static Rect _rect;
  uint res = 0;
  for(int i=0; i<it; ++i ) {
    for( auto iterator=v.begin(); iterator!=v.end(); ++iterator ) {
      auto element = *iterator;
      if( *(reinterpret_cast<uint*>(element)) == *(reinterpret_cast<uint*>(&_rect))  ) {
        Rect* rect_ptr = reinterpret_cast<Rect*>(element);
        res += rect_ptr->area();
      }else{
        res += element->area();
      }
    }
  }
  return res;
}
#endif

#ifdef OPT3
uint func1(std::vector<Figure*> v) {
  static Rect _rect;
  uint res = 0;
  for(int i=0; i<it; ++i ) {
    for( auto iterator=v.begin(); iterator!=v.end(); ++iterator ) {
      auto element = *iterator;
      if( *(reinterpret_cast<uint*>(element)) == *(reinterpret_cast<uint*>(&_rect))  ) {
        Rect* rect_ptr = reinterpret_cast<Rect*>(element);
        res += Rect::area_static(rect_ptr);
      }else{
        res += element->area();
      }
    }
  }
  return res;
}
#endif

int main()
{
  std::vector<Figure*> v(len);
  for( uint i=0; i<len; ++i ) {
    v[i] = ( i%32==0 ? (Figure*) new Circle() : (Figure*) new Rect() );
  }
  std::cout << func1(v) << std::endl;
  return 0;
}

в том коде, который я привел, нету очень много чего (в частности, кода, отвечающего за пробу в рантайме, кода для подмены кусочка сегмента кода и т.п.) — там только выражена мысль, что и jit должен исполняться статически там, где можно

а ты как относишься к jit?

btw, еще очень интересно было бы побенчить инструкции с data hazard-ами... наверно напишу потом

Было бы все просто, давно бы было реализовано...

вообще-то в самом начале я вел речь о гипотетической архитектуре, которая позволяет извлечь пользу из того, из чего сейчас пользу извлечь проблематично

но разговор постепенно переходит в плоскость «че можно сделать полезного в нынешних архитектурах»; это хотя и интересно, но не так

я, вообще-то, так не говорил, а был несогласен с тем, что это Охренненно Сложная Исследовательская Задача (причем именно в таком написании — т.е. без кавычек, намекающих на цитирование)

но это действительно ОСИЗ. Если ты её реализуешь _аппаратно_, причём БЫСТРО. Настолько быстро, что это существенно быстрее штрафных тактов. Проблема в том, что на этапе компиляции тебе практически никогда неизвестен размер массива, а обычно ещё и неизвестен размер кеша.

если у нас есть гипернить, которая целиком исполняется на регистрах (john-the-ripper например), то она будет исполняться в то время, когда основная гипернить ждет операнда из памяти

компилятор ещё с первопня размешивает инструкции так, что-бы они спаривались. Т.е. гипернить тут ничего не даст, там уже давно в два потока выполняется, задолго до HT.

контекстом моей фразы был гипотетический epic-like процессор; можно ли извлечь профит из этого на нынешних процах — это вопрос

ИМХО смысла нет создавать такой процессор. Какие-нить 256и ядерные более перспективны для расчётов ядрёной бомбы, а потом их можно будет успешно втюхать хомячкам, ведь покупаю-же они ненужные им 6и ядерные процессоры? Покупают. И хвастаются друг перед другом. Ну и 256и ядерные будут покупать.

А вопрос в том, ЧТО ты будешь обсчитывать на своём гипотетическом CPU, и КТО будет вкладываться в его разработку?

ненужные им 6и ядерные процессоры?

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

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

мало-ли что ты говорил? Гламурные кисо тоже много говорят про разные вещи, которые ИМХО ну никак не нужны.

Скажем так, при запущенных virtualbox, eclipse, chrome на многоядернике всё крутится шустрее чем на одноядернике. Вопрос в том, что если ты не можешь нагрузить имеющуюся у тебя выч. мощность, это твои проблемы.

0. Ядро 3.7? Только после переноса в него архитектурно-зависимой части наших правок. Сейчас ядро 2.6.33, оценить разницу с 3.7 мне сложно.

2. Практически с точки зрения формата исходников наш компилятор аналогичен gcc 3.4.6 (наши компиляторщики поддержали и какие-то более свежие расширения). То есть - да, софт собирается.

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

аналогичен gcc 3.4.6
То есть - да, софт собирается.

Мдя.. Старье, в общем.

Вы не поняли. По _возможностям_ компилятор lcc превышает gcc 3.4.6. Речь идёт о том, какие специфические gnu-расширения он понимает.

Уточнил у разработчиков. Фронт-энд у lcc поддерживает gnu-расширения до версии gcc 4.4, с некоторыми фичами из gcc 4.7

Фронт-энд у lcc поддерживает gnu-расширения до версии gcc 4.4, с некоторыми фичами из gcc 4.7

Вот это уже труЪ.

Проблема в том, что на этапе компиляции тебе практически никогда неизвестен размер массива, а обычно ещё и неизвестен размер кеша.

Размер cache известен и фиксирован. Размер массива не так важен - важно только чтобы он был достаточно большой, чтобы покрыть накладные расходы на организацию самого цикла и иметь возможность unroll.

На самом деле проблем несколько. 1) Время выполнения операций разное и зависит от начальных данных и, что наиболее противно, состояния системы, 2) Зависимости между данными не всегда можно выявить в compile time. 3) Задачи распределения ресурсов np-полная, в общем случае неразрешима. Это касается и распределения регистров, и instruction scheduling...

Уточнил у разработчиков. Фронт-энд у lcc поддерживает gnu-расширения до версии gcc 4.4, с некоторыми фичами из gcc 4.7

То есть, например Qt версии 4.x собрать вполне реально?

И еще вопрос. Есть ли в монокубе набортный звуковой чип?

Вроде бы на фото видно два звуковых разъема, но точно не видно, относится ли это к звуку или нет.

То есть интересует, какой звуковой чип. Будет ли с ним работать библиотека SDL?

это OPT0; п.2 это OPT2 и OPT3 что такое п.3 объяснять лень

А OPT1 что значит?

Смешно. Обсудили микруху партией в 100 штук. Народный проецссор прям.

Все, прошу прощения. Набортный звук в монокубе есть:

В этот же чип интегрирован гигабитный Ethernet-котроллер, а соответствующий разъем выведен на заднюю панель. Там же размещены интерфейсы для ввода и вывода аудио

http://zonatex.ru/blog/komputeri/23.html

Но хотелось бы подробностей, что за чип используется, и насколько хорошо его держит ALSA. Будет ли с ним работать звуковой сервер JACK?

Смешно. Обсудили микруху партией в 100 штук. Народный проецссор прям.

Пройди по ссылкам которые в этой теме и оцени эпичность масштабов. Семейство вливовских эльбрусов далеко не партией в 100 штук выпускается. 100 штук - это крафтвеевские сборки моноблоков.

на всякий случай уточню, что п.2 встречается достаточно часто: скажем, проц имеет кэш в 4МБ, у нас есть массив в 8МБ, состоящий из структур размером меньше кэш-линии (или даже просто из 4-байтовых целых)

этот массив был ранее заполнен (возможно последовательно), и сейчас мы читаем его в *произвольном* порядке, и при этом в память почти не пишем (или пишем без сохранение в кэш); так как весь массив в кэш не влезет, то после чтения части массива (скажем, 1/8) вероятность найти новое значение в кэше близка к 50%, и нет тут никакой Охрененно Сложной Исследовательской Задачи

я думал, что это очевидно, поэтому и не остановился на этом в первом своем ответе

(да, можно запросить чтение массива без сохранения в кэше, но это только во вред)

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

И даже не начнут писать, пока не станут доступны платы и документация.

А если станут доступны и платы, и документация, но половина системы будет закрыта? (как выше написали - на DSP будут только бинарные либы без исходников).