|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
nedoPC-580 (SMP на 5 процессорах КР580ВМ80А)
Author |
Message |
BarsMonster
Senior
Joined: 21 Jul 2012 15:56 Posts: 126 Location: Zürich, Switzerland
|
Как раз эти проблемы - решаются элементарно: http://www.aliexpress.com/store/product/Factory-direct-and-Free-shipping-400W-5V-60A-switching-power-supply-built-in-cooling-fan-wholesale/410948_576117227.html37.33$ с доставкой. Я такие покупал на 48V. Ну или как вариант - любимый всеми ATX, с 12V->5V DCDC если нагрузочной способности родной 5В шины не хватит. Отведение 100W тепла не является проблемой, но конечно нужен вентилятор.
|
25 Aug 2012 21:23 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
ну что сказать... паяльник-то в руках держал хоть раз или все на верилоге(или что у вас там за софт делает всем хорошо)?
|
25 Aug 2012 21:46 |
|
|
BarsMonster
Senior
Joined: 21 Jul 2012 15:56 Posts: 126 Location: Zürich, Switzerland
|
Да, и паяльник, и фен держал Но о проблемах, о которых я пока не подозреваю - всегда готов послушать.
|
26 Aug 2012 01:48 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
А я тут почитал материалы по "Эльбрусу" и очень вот в этом тезисе усомнился.
Вполне "на лету" задача может быть распараллелена, да - этим самым оптимизирующим,
но только " перекомпилятором", и разложена по " памятям" разным процессорам.
А кому это делать, как не одному из процессоров под управлением ОС?
И это никак не противоречит написанию специального оптимизированного софта.
Да, возможно чисто программно-аппаратно это будет сделано не самым
оптимальным образом, но параллельная работа процессоров должна дать
выигрыш, на мой взгляд.
_________________ iLavr
|
26 Aug 2012 02:27 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
60 ампер это не шутка - рэйлы питания надо серьезные делать и землю не абы как прокладывать иначе не взлетит. пусть не 60, пусть половина - 30ампер. все равно немало. я так понимаю, что осциллограф есть. ткнись им на землю в орионе - крокодильчиком около разъема питания, а щупом потыкай по земляной шине. удивительно, правда? а там всего 1,5 ампера гуляет.
|
26 Aug 2012 04:24 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
выигрыш будет заметен, когда процессоров очень много. если процессоров 2-4, то прирост скорости будет 30-50%.
|
26 Aug 2012 04:33 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Какие ваши аргументы? Свои я привёл многократно: даже при двух процессорах,
если один делает рассчет, а второй - отрисовывает графику, - заметный
прирост точно будет.
Я разбирал это для своих задач даже весьма подробно.
Отрисовка графики весьма медленная и даже 2 проца уже дадут ускорение.
Третий может обслуживать ввод-вывод. Это также ускорит процесс, т.к. не
отвлекает другие два.
очень много процессоров, конечно, дадут ещё где-то прирост, если им будет
чем заняться, но 30%, на мой взгляд, обеспечат вполне уже эти трое.
_________________ iLavr
|
26 Aug 2012 04:45 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
не так. надо вот так - какие есть ваши доказатьельства
время на обслуживание потоков съест большую часть выигрыша. сложность программирования возрастет неимоверно(распараллелить на 2 процессора или тысячу - затраты одни а выигрыш разный). если надо чтоб Специалист работал вдвое быстрее, берем Z80H, перекраиваем синхрогенератор(только так чтобы без вэйтов) и аля-улю.
|
26 Aug 2012 04:59 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Нууууу... оффисер ето не есть доказатьельства...
Я про Ерёму, а ты про Фому...
То, что распараллеливание на 3 процесса даст явный выигрыш - это просто
очевидно и доказанно корректно и логично!
А то что " время на обслуживание потоков съест большую часть выигрыша" -
неочевидно и бездоказательно...
А уж Z80H - и совсем неспортивно... Почему тогда уж не V20/V40?
Или ты решил, что я для музея над ним выплясываю?
Речь мы тут ведем сугубо о многозадачности и распараллеливании, а всякий
" оверклокинг" - это оффтоп!
_________________ iLavr
|
26 Aug 2012 06:10 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
ну давай тогда посчитай выигрыш от распараллеливания например вывода символа на экран(а чо, тоже графика). по тактам(глядишь и софт нарисуется, ага). только не надо вещать про абстрактные глобальные проблемы распараллеливания.
для меня объемные вычислительные задачи это обсчет хэшей. все остальное это как карманный бильярд лол
|
26 Aug 2012 06:54 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Да я привел неоднократно пример про " выигрыш от распараллеливания например вывода символа на экран" - да, это такая же графика, как и нарисовать
примитив, выполняется отдельным процессором, в то время как другой выполняет
программу...
"Выстрелил и - забыл".
Повторяться я больше не собираюсь - читай топик... Я нигде не вещал, " про абстрактные глобальные проблемы распараллеливания"...
Наоборот постоянно призываю к конкретике, пусть и простой...
Так что если тебя бычит чего-то, - займись " обсчетом хэшей"... " Карманный билиард" и
троллинг здесь не нужны.
_________________ iLavr
|
26 Aug 2012 07:08 |
|
|
MC68k
Retired
Joined: 25 Jul 2011 00:14 Posts: 1331 Location: WWW
|
ухожу, ухожу, ухожу...
|
26 Aug 2012 07:32 |
|
|
BarsMonster
Senior
Joined: 21 Jul 2012 15:56 Posts: 126 Location: Zürich, Switzerland
|
Нужно четко понимать разницу между распарралеливанием задачи на уровне компилятора и уровне программирования.
1) Компилятор на типичных линейных задачах может разорвать задачу на 2-3 ALU. Если это реализовывать на отдельных процессорах с общей памятью - то работать конечно будет, но из-за необходимости вести обмен результатами через общую память - скорость работы снижается. Ну и писать такой компилятор - задача сравнимая по сложности с разработкой железа (даже если мы берем готовый LLVM и только дописываем нужный кодогенератор). Этот вариант малореальный.
2) Распарралеливание на уровне программирования - когда мы аппаратно реализовывает кусочек общедоступной памяти с предсказуемым доступом (т.е. если процессоры имеют доступ к нему по-очереди например), и аппаратно реализовываем возможность дергать прерывания "все на всех" или "только главный процессор дергает у всех". Тогда можно реализовать понятные программистам функции mutex_lock и mutex_release, и уже программист сам будет разрывать свою задачу на нужное количество процессоров. Реализация этого метода в железе - существенно проще, и новых компиляторов писать не нужно. С учетом предсказуемости доступа к памяти, mutex_lock/unlock могут выполнятся за сотню тактов, если mutex не захвачен, т.е. не так уж и медленно.
|
26 Aug 2012 13:20 |
|
|
Lavr
Supreme God
Joined: 21 Oct 2009 08:08 Posts: 7777 Location: Россия
|
Ну вобще-то если внимательно почитать топик - у нас была концепция:
каждый процессор со своей памятью и область общей памяти для обмена данными.
Это и есть слабосвязанная многопроцессорная модель и по этому принципу
предполагалось построение многопроцессорных систем на 8086.
Ну никто и не говорил, что всё это легко. Как раз все понимают, что сложно, почему
и не сделали нифига с 18 Авг 2004 г.
А вобще у меня тяжелое впечатлние, что повторения пошли уже по третьему кругу...
_________________ iLavr
|
26 Aug 2012 14:05 |
|
|
BarsMonster
Senior
Joined: 21 Jul 2012 15:56 Posts: 126 Location: Zürich, Switzerland
|
Так мы на самом деле и говорим об одном и том же
Я говорю, что с такой архитектурой проблем программирования нет - понятные программистам инструменты (мютексы) реализовываются легко, и потому вопросы MC68k "а как задачи будут распарралеливаться" и "оно будет медленно распарралеливаться" - неактуальны, т.к. проблем для программиста тут нет.
Но вот мечта Lavr'a "Чтобы и программная совместимость со старым софтом была, и оно само автомагически распарралеливалось" - совершенно неподъемная.
Поэтому мечты о совместимости софта нужно отбросить, и готовится писать весь нужный софт. Раз у нас памяти сейчас много - то можно и на C, без ассемблера, чтобы быстрее.
С тезисом о необходимости защиты памяти в корне несогласен, даже на 32-х битных процессорах нормальные операционки могут без неё работать. В конце концев, какая для нас разница - софт будет виснуть или падать с ошибкой
А насчет практики - думаю, наиболее простой вариант практического теста (для меня и моего варианта со сдвиговыми регистрами) - это распаять на платке 2 проца, 8 сдвиговых регистров и 4 конвертора уровней для синхросигналов - и подключать к FPGA-демоплате, чтобы остальную обвязку там отлаживать.
|
27 Aug 2012 00:05 |
|
|
Who is online |
Users browsing this forum: No registered users and 104 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|