LINUX.ORG.RU

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

 , , ,


6

5

Компания МЦСТ совместно с компанией Kraftway выпустила первую пилотную партию моноблочных компьютеров с архитектурой «Эльбрус». Компьютеры предназначены для использования в качестве офисных автоматизированных рабочих мест.

Моноблочный компьютер оснащён материнской платой «Монокуб». Плата «Монокуб» разработана в ЗАО МЦСТ под гибридный микропроцессор «Эльбрус-2С+» (два ядра Elbrus E2K + 4 DSP фирмы Элвис) предназначена для широкого применения, в том числе в гражданском секторе. Компания Kraftway, в свою очередь, адаптировала под плату «Монокуб» моноблочную платформу KM4.

Внешний вид моноблочного компьютера: http://www.mcst.ru/image/news_121229_1.jpg

Плата «Монокуб»: http://www.mcst.ru/image/news_121229_2.jpg

Плата «Монокуб» имеет форм-фактор miniITX и содержит один процессор «Эльбрус-2С+». На плате имеются два разъёма DIMM DDR2-800 и один разъём PCI-Express x16 (используется 8 линий). Возможна установка до 16 ГБ памяти (используются модули с ECC). Имеются внешние выходы: Gigabit Ethernet, 4 порта USB 2.0, аудио, RS-232, DVI. Система охлаждения основана на тепловых трубках.

Состав оборудования компьютера следующий:

  • сенсорный экран с диагональю 20” и разрешением 1600х900;
  • жёсткий диск SATA диаметром 2.5”. В корпусе меется посадочное место для второго жёсткого диска;
  • дисковод DVD-RW;
  • адаптер Wifi b/g;
  • USB хаб с карт-ридером и панелью аудиоразъёмов;
  • два встроенных динамика мощностью 2 Вт.

Общая потребляемая мощность ПК ~100 Вт, вес ~11 Кг (с подставкой, но без источника питания).

Моноблок работает под операционной системой «Эльбрус». Она основана на ядре Linux 2.6.33 и включает в себя доработки, реализующие мандатную защиту. Комплект пользовательских программ привычен многим любителям Linux:

  • графическая оболочка Xorg;
  • оконный менеджер Xfce4;
  • средства работы с офисными документами (текстовый редактор ABIWord, электронная таблица GNumeric);
  • браузер Firefox;
  • СУБД Postgresql и Linter;
  • веб-сервер Apache;
  • прочие программные компоненты.

Все комплексы программно-аппаратных средств имеют второй класс защищённости от несанкционированного доступа и сертифицированы по второму уровню контроля недекларированных возможностей.

Информации о стоимости компьютера и возможности его приобретения в сети не обнаружено.

>>> Подробности

★★★★★

Проверено: tazhate ()

Ответ на: комментарий от VIT

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

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от VIT

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

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

Dark_SavanT ★★★★★ ()
Ответ на: Ответ на популярные вопросы от KT

Re: Ответ на популярные вопросы

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

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: Re: Ответ на популярные вопросы от www_linux_org_ru

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

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Xintrea

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

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от Xintrea

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

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от VIT

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

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

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

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

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

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

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

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

VIT ()
Последнее исправление: VIT (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

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

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

drBatty ★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

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

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

VIT ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

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

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

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

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

GolemXIV ()
Ответ на: комментарий от www_linux_org_ru

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

софта то нет.

devl547 ★★★★★ ()
Ответ на: Ответ на популярные вопросы от KT

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

devl547 ★★★★★ ()
Ответ на: комментарий от devl547

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

KT ()
Ответ на: комментарий от KT

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

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

devl547 ★★★★★ ()
Ответ на: комментарий от VIT

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

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

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

thrashing?

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от drBatty

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

хотя бы hyperthreading

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

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

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

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от VIT

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

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

Скажите, когда Вы предлагаете выполнять компиляцию, до исполнения или во время исполнения программы? Иными словами, Вы сторонник статической компиляции или 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;
}

www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от VIT

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

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от VIT

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

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

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

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

drBatty ★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

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

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

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

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

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

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от devl547

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

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

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

KT ()
Ответ на: комментарий от KT

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

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

devl547 ★★★★★ ()
Ответ на: комментарий от devl547

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

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

KT ()
Ответ на: комментарий от KT

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

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

devl547 ★★★★★ ()
Ответ на: комментарий от drBatty

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

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

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

VIT ()
Ответ на: комментарий от KT

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от KT

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от KT

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

Xintrea ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

Xintrea ★★★★★ ()

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

pat_minus ()
Ответ на: комментарий от KT

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

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

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

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

Xintrea ★★★★★ ()
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от pat_minus

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

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

Xintrea ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

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

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

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

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



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

Xintrea ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

Xintrea ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.