nedoPC.org

Как раз эти проблемы - решаются элементарно:

http://www.aliexpress.com/store/product/Factory-direct-and-Free-shipping-400W-5V-60A-switching-power-supply-built-in-cooling-fan-wholesale/410948_576117227.html

37.33$ с доставкой. Я такие покупал на 48V.
Ну или как вариант - любимый всеми ATX, с 12V->5V DCDC если нагрузочной способности родной 5В шины не хватит.

Отведение 100W тепла не является проблемой, но конечно нужен вентилятор.

ну что сказать... паяльник-то в руках держал хоть раз или все на верилоге(или что у вас там за софт делает всем хорошо)?

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

А я тут почитал материалы по "Эльбрусу" и очень вот в этом тезисе усомнился.
Вполне "на лету" задача может быть распараллелена, да - этим самым оптимизирующим,
но только "перекомпилятором", и разложена по "памятям" разным процессорам.
А кому это делать, как не одному из процессоров под управлением ОС?

И это никак не противоречит написанию специального оптимизированного софта.

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

60 ампер это не шутка - рэйлы питания надо серьезные делать и землю не абы как прокладывать иначе не взлетит. пусть не 60, пусть половина - 30ампер. все равно немало. я так понимаю, что осциллограф есть. ткнись им на землю в орионе - крокодильчиком около разъема питания, а щупом потыкай по земляной шине. удивительно, правда? а там всего 1,5 ампера гуляет.

выигрыш будет заметен, когда процессоров очень много. если процессоров 2-4, то прирост скорости будет 30-50%.

Какие ваши аргументы? Свои я привёл многократно: даже при двух процессорах,
если один делает рассчет, а второй - отрисовывает графику, - заметный
прирост точно будет.
Я разбирал это для своих задач даже весьма подробно.
Отрисовка графики весьма медленная и даже 2 проца уже дадут ускорение.
Третий может обслуживать ввод-вывод. Это также ускорит процесс, т.к. не
отвлекает другие два.

очень много процессоров, конечно, дадут ещё где-то прирост, если им будет
чем заняться, но 30%, на мой взгляд, обеспечат вполне уже эти трое.

не так. надо вот так - какие есть ваши доказатьельства
время на обслуживание потоков съест большую часть выигрыша. сложность программирования возрастет неимоверно(распараллелить на 2 процессора или тысячу - затраты одни а выигрыш разный). если надо чтоб Специалист работал вдвое быстрее, берем Z80H, перекраиваем синхрогенератор(только так чтобы без вэйтов) и аля-улю.

Нууууу... оффисер ето не есть доказатьельства...
Я про Ерёму, а ты про Фому...

То, что распараллеливание на 3 процесса даст явный выигрыш - это просто
очевидно и доказанно корректно и логично!

А то что "время на обслуживание потоков съест большую часть выигрыша" -
неочевидно и бездоказательно...

А уж Z80H - и совсем неспортивно... Почему тогда уж не V20/V40?
Или ты решил, что я для музея над ним выплясываю?

Речь мы тут ведем сугубо о многозадачности и распараллеливании, а всякий
"оверклокинг" - это оффтоп!

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

для меня объемные вычислительные задачи это обсчет хэшей. все остальное это как карманный бильярд лол

Да я привел неоднократно пример про "выигрыш от распараллеливания
например вывода символа на экран" - да, это такая же графика, как и нарисовать
примитив, выполняется отдельным процессором, в то время как другой выполняет
программу...
"Выстрелил и - забыл".

Повторяться я больше не собираюсь - читай топик... Я нигде не вещал, "про
абстрактные глобальные проблемы распараллеливания"...
Наоборот постоянно призываю к конкретике, пусть и простой...

Так что если тебя бычит чего-то, - займись "обсчетом хэшей"... "Карманный билиард" и
троллинг здесь не нужны.

ухожу, ухожу, ухожу...

Нужно четко понимать разницу между распарралеливанием задачи на уровне компилятора и уровне программирования.

1) Компилятор на типичных линейных задачах может разорвать задачу на 2-3 ALU. Если это реализовывать на отдельных процессорах с общей памятью - то работать конечно будет, но из-за необходимости вести обмен результатами через общую память - скорость работы снижается. Ну и писать такой компилятор - задача сравнимая по сложности с разработкой железа (даже если мы берем готовый LLVM и только дописываем нужный кодогенератор). Этот вариант малореальный.

2) Распарралеливание на уровне программирования - когда мы аппаратно реализовывает кусочек общедоступной памяти с предсказуемым доступом (т.е. если процессоры имеют доступ к нему по-очереди например), и аппаратно реализовываем возможность дергать прерывания "все на всех" или "только главный процессор дергает у всех". Тогда можно реализовать понятные программистам функции mutex_lock и mutex_release, и уже программист сам будет разрывать свою задачу на нужное количество процессоров. Реализация этого метода в железе - существенно проще, и новых компиляторов писать не нужно. С учетом предсказуемости доступа к памяти, mutex_lock/unlock могут выполнятся за сотню тактов, если mutex не захвачен, т.е. не так уж и медленно.

Ну вобще-то если внимательно почитать топик - у нас была концепция:
каждый процессор со своей памятью и область общей памяти для обмена данными.

Это и есть слабосвязанная многопроцессорная модель и по этому принципу
предполагалось построение многопроцессорных систем на 8086.

Ну никто и не говорил, что всё это легко. Как раз все понимают, что сложно, почему
и не сделали нифига с 18 Авг 2004 г.

А вобще у меня тяжелое впечатлние, что повторения пошли уже по третьему кругу...

Так мы на самом деле и говорим об одном и том же
Я говорю, что с такой архитектурой проблем программирования нет - понятные программистам инструменты (мютексы) реализовываются легко, и потому вопросы MC68k "а как задачи будут распарралеливаться" и "оно будет медленно распарралеливаться" - неактуальны, т.к. проблем для программиста тут нет.

Но вот мечта Lavr'a "Чтобы и программная совместимость со старым софтом была, и оно само автомагически распарралеливалось" - совершенно неподъемная.

Поэтому мечты о совместимости софта нужно отбросить, и готовится писать весь нужный софт. Раз у нас памяти сейчас много - то можно и на C, без ассемблера, чтобы быстрее.

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

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