Полгода сижу на линукс - десктопе. Помаялся с настройкой, зато теперь всё работает идеально.
Винда есть, раз в неделю/две запускаю ради двух игр. Больше ни для чего не годится т.к. работает 3-й год без реинсталла - всё заглючено досмерти. После загрузки clipboard/кодеки отваливаются, потом падает Explorer.
К счастью если успеть запустить игруху - эти вещи уже не нужны.
Переставлять не собираюсь - скорее всего снесу совсем.
А думаешь в 3 ГГц процессоре транзисторы медленнее?
За 1 такт переключаются 20+ тразисторов последовательно в цепочке.
30ГГц рекордные для нанотрубок.
СВЧ 100ГГц тразисторы используются в коммуникационном оборудовании
А экспериментальные транзисторы IBM до 500ГГц разогнали (300 при комнатной температуре)
Поддержка Java - это jazelle. AFAIK Это чудо ускоряет "обычный интерпретатор" всего раза в 2.
"Горячие" циклы всё равно JIT-компилятся. Т.е. особой разницы по сравнению с обычным ARM-ом нет.
А 3D наверняка MBX - они уже часто встречаются.
Для начала неплохо было бы разобраться КТО будет платить.
Бизнес-модели redhat и т.п. расчитаны на корпоративных заказчиков.
C простых пользователей они мало что могут получить.
GPL - рабская лицензия.
Если jpeglib включён, скажем, в photoshop, теперь что, все исходники photoshop открывать?
К счастью для человечества, авторы jpeglib не были linux-zealot'ами.
> Есть разница будет ли развитие данного продукта доступно как free opensource.
Оригинальный код останется полюбому, так что желающие могут его развивать в opensource.
Не вижу тут проблемы
> Пользуй FBSD
Я использую только Fedora по ряду причин.
В принципе мне пофиг, на какой лицензии ОС.
Я вот не понимаю смысла GPL.
Хочешь отдавать свой софт задаром - отдавай его под BSD лицензией.
Какая разница, заработает ли кто-нибудь на нём "мульёны"?
Хочешь сам зарабатывать на софте - какой тогда смысл в opensource?
Особенно раздражает весь этот бред с линковкой gpl/nongpl.
>> Если запустить две задачи, то на одном процессоре каждая
>> из них будет работать в два раза медленней
А не надо запускать 2 штуки на 1 ядре.
Под "задачей" подразумевается некая последовательность операций,
достаточно короткая для того, чтобы не делать её принудительное вытеснение,
либо делать его редко.
Параллелить имеет смысл только то, что можно запараллелить =)
Через несколько лет 16+ ядерные процессоры будут на каждом столе. Niagara вон уже 32 аппаратных треда запускает, а Rock - 64.
>> существует техника создания пуллов нитей или процессов
Это довольно стандартная практика. Кардинальной разницы нет.
>> Как раз это и гарантирует то, что можно сохранить состояние
>> вычисления и перейти к другому вычислению.
>> То есть, организовать многозадачность.
Это фейк, иллюзия одновременного исполнения.
Если у нас есть несколько реальных ядер/аппаратных трэдов, надобность в прерывании работы может и не понадобится.
>>И в чём же его правильность?
При условии правильной реализации, таски можно запускать десятки-сотни тысяч раз в секунду.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
>> Если файловая система одна
А если я параллелю внутренний вычислительный цикл? Мне не нужен ни TLS, ни, возможно, даже стек.
>>Менять надо сам способ описания параллельных программ,
>>а не механизмы поддерживающие работу многозадачных систем.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
Дело не в конкретном направлении, а в "стремлении быть как все".
Если X не мейнстрим, то X, очевидно, игрушка для гиков.
А тем временем "мыши кололись, плакали но продолжали жрать кактус"(c)
Большинство программистов смотрят на параллельное программирование
через призму ущербных языков c++/java и т.п.
Трэды - ИМХО, тупик. Очень высокий оверхид на запуск/синхронизацию, поддержание стейта, несовершенная система планирования.
Более правильный путь - асинхронные task-based системы. На уровне железа.
Правда, с существующей инфраструктурой, это пока что извращённый мазохизм.
Да я собственно никого и не обвиняю. "Партия сказала - инженер ответил Да!"
Хотя сейчас в России вообще микроэлектроника полумертва.
На западе купить и проще и дешевле.
Во имя Великого Мао никакого кеша не жалко =)
С таким же успехом можно сказать "бедные русские" и т.д.
В СССР, например, даже модемы были законодательно запрещены. А вы говорите "лишаются свобод" =)
Да, некоторые hd-wmv, говорят, не показываются, но у меня их нет.
Винда есть, раз в неделю/две запускаю ради двух игр. Больше ни для чего не годится т.к. работает 3-й год без реинсталла - всё заглючено досмерти. После загрузки clipboard/кодеки отваливаются, потом падает Explorer.
К счастью если успеть запустить игруху - эти вещи уже не нужны.
Переставлять не собираюсь - скорее всего снесу совсем.
Это угроза? =)
За 1 такт переключаются 20+ тразисторов последовательно в цепочке.
30ГГц рекордные для нанотрубок.
СВЧ 100ГГц тразисторы используются в коммуникационном оборудовании
А экспериментальные транзисторы IBM до 500ГГц разогнали (300 при комнатной температуре)
Ну ничё, в пьяном угаре могём и "Герцена разбудить" =)
"Горячие" циклы всё равно JIT-компилятся. Т.е. особой разницы по сравнению с обычным ARM-ом нет.
А 3D наверняка MBX - они уже часто встречаются.
Бизнес-модели redhat и т.п. расчитаны на корпоративных заказчиков.
C простых пользователей они мало что могут получить.
Если jpeglib включён, скажем, в photoshop, теперь что, все исходники photoshop открывать?
К счастью для человечества, авторы jpeglib не были linux-zealot'ами.
Оригинальный код останется полюбому, так что желающие могут его развивать в opensource.
Не вижу тут проблемы
> Пользуй FBSD
Я использую только Fedora по ряду причин.
В принципе мне пофиг, на какой лицензии ОС.
Хочешь отдавать свой софт задаром - отдавай его под BSD лицензией.
Какая разница, заработает ли кто-нибудь на нём "мульёны"?
Хочешь сам зарабатывать на софте - какой тогда смысл в opensource?
Особенно раздражает весь этот бред с линковкой gpl/nongpl.
what we will buy today?
>> из них будет работать в два раза медленней
А не надо запускать 2 штуки на 1 ядре.
Под "задачей" подразумевается некая последовательность операций,
достаточно короткая для того, чтобы не делать её принудительное вытеснение,
либо делать его редко.
Параллелить имеет смысл только то, что можно запараллелить =)
Через несколько лет 16+ ядерные процессоры будут на каждом столе. Niagara вон уже 32 аппаратных треда запускает, а Rock - 64.
>> существует техника создания пуллов нитей или процессов
Это довольно стандартная практика. Кардинальной разницы нет.
>> Как раз это и гарантирует то, что можно сохранить состояние
>> вычисления и перейти к другому вычислению.
>> То есть, организовать многозадачность.
Это фейк, иллюзия одновременного исполнения.
Если у нас есть несколько реальных ядер/аппаратных трэдов, надобность в прерывании работы может и не понадобится.
При условии правильной реализации, таски можно запускать десятки-сотни тысяч раз в секунду.
Т.о. можно параллелить каждый чих.
Сейчас затраты на создание трэда в сотни раз больше чем нужно.
Хотя подобный планировщик можно построить и на существующих системах,
но он утонет в синхронизации.
>> Если файловая система одна
А если я параллелю внутренний вычислительный цикл? Мне не нужен ни TLS, ни, возможно, даже стек.
>>Менять надо сам способ описания параллельных программ,
>>а не механизмы поддерживающие работу многозадачных систем.
Про первое я и говорю, со вторым не согласен. Сколько вы на запорожце не пишите F1 pro street racing он от этого быстрее не побежит.
Про регистры не понял. Какое отношение они имеют к многозадачности?
Наоборот, с ними проблем больше - надо сохранять/восстанавливать.
Склероз =)
Если X не мейнстрим, то X, очевидно, игрушка для гиков.
А тем временем "мыши кололись, плакали но продолжали жрать кактус"(c)
через призму ущербных языков c++/java и т.п.
Трэды - ИМХО, тупик. Очень высокий оверхид на запуск/синхронизацию, поддержание стейта, несовершенная система планирования.
Более правильный путь - асинхронные task-based системы. На уровне железа.
Правда, с существующей инфраструктурой, это пока что извращённый мазохизм.
Хотя сейчас в России вообще микроэлектроника полумертва.
На западе купить и проще и дешевле.
С таким же успехом можно сказать "бедные русские" и т.д.
В СССР, например, даже модемы были законодательно запрещены. А вы говорите "лишаются свобод" =)