А для Ъ?

А для Ъ?

Там собственноручно подписанный смертный приговор от рук Grammar Nazi.

в текст особо пока не вникал, но глаз очень режет это «небыло», «впринципе» и т.п. пожалуйста, пиши их раздельно.

также поправь ссылку на лор, сейчас у тебя она такая tp://www.linux.org.ru/forum/talks/9326998

пожже

ну ты понел.

добавь тег multiclet. Ну и скастуем пользователя Multiclet

мы видим инновационный и конкурентноспособный продукт

О. ЛО. ЛО.

я хочу сказать что в той же мегапопулярной Arduino дела под Linux обстоят не лучшим образом

Хм, у меня всё нормально было. Максимум среду приходилось перезапустить, когда оно какую-то жабо-ошибку выдавало. Но таки надо сравнить и цену этих двух девайсов.

Ссылка на ЛОР битая.

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

Эх, не могу. Уходил, а теперь редактирование запрещено.

Так я не понял, в чем инновационность сего продукта? Машинное распараллеливание - так это мы уже в cell-архитектуре видели (кстати, совпадение названий наводит на мысли). Так cell не взлетел же - в PS4 нынче обычный x86 обмылок. Про конкурентоспособность вообще промолчу - перспективы применения совершенно неясны.

В Cell не была решена проблема машинного распараллеливания. Архитектура организации вычислительного процесса всё та же - разбиение потоков на ядра, только очень хитропопое. Разработчики побоялись сделать ставку на неотработанные технологии и даже ядра сделали на семействе Power. Cell - гигантская уродливая махина, которую слепили из того что было с надеждой что разработчики вдруг начнут в естественном виде писать многопоточные приложения. Не вышло.

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

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

4.2.

я хочу сказать что в той же мегапопулярной Arduino дела под Linux обстоят не лучшим образом

С Arduino всё прекрасно. Говорю по личному немалому опыту общения с Arduino Uno и Mega2560.

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

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

Ну не знаю, у меня Arduino Uno под линухом тупит. Тупит и если пользоваться родным IDE, и тупит если пользоваться GPL-ным софтом.

Очень часто avrdude не может залить в Arduino простейший бинарь. Приходится передергивать адуину, если не помогает - менять USB-порт. Ну и постоянно следить какой там ttyUSB использовать. Иногда приходится удерживать ресет при подключении питания, иначе точно не зальется.

Debian Stable есличо.

Да, я это понимаю. просто в таком случае всё равно нужны некоторые оптимизации при разработке (или при компиляции, но лучше при разработке), не так ли?

Если завязана, будет ожидание готовности данных, затем выполнение команды и клетка освободится

Насколько часто получается так, что приходится ждать? (Интересно же глянуть статистику) Ведь от этих ожиданий можно проиграть вплоть до (количество_ядер − 1) ядер (то есть постоянно работать будет только одно, а все остальные будут ждать). С этой проблемой как-то борется этот проц?

Насколько часто получается так, что приходится ждать? (Интересно же глянуть статистику) Ведь от этих ожиданий можно проиграть вплоть до (количество_ядер − 1)

Статистику и меня нет, обратись к разработчикам. В любом случае, микропроцессор будет работать не медленнее, чем скорость выполнения кода на одной клетке. В любом случае, конструкция мультиклета гораздо лучше UV-распараллеливания на Intel.

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