?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Суббота вечер [31 Aug 2008|12:08am]
Не могу удержаться, чтобы не показать разницу между CPU и GPU в исполнении знаменитых Mythbusters. Вон она, разница между последовательными и параллельными вычислениями (последние 4 секунды записи, конечно, весьма впечатляют):

Тем не менее, я считаю, что последовательные вычисления отнюдь нельзя сбрасывать со счетов. Не все задачи в мире сводятся к рисованию картинок.

С другой стороны, все эти "рисования картинок" неожиданно могут свестись к решению ровно обратной задачи: этих картинок распознаванию. К этому все и идет. Gigabyte уже продемонстрировал системную плату для Core i7, в которую можно воткнуть 6 графических плат на общую сумму $1200. Результирующая вычислительная мощность -- 6Терафлоп. Нужно заметить, что суперкомпьютер 1997 года, в котором было 10тыс. Пентиумов Про, стоил сумасшедшие деньги и рейтинговался на 1Терафлоп. Прошло всего 11 лет, и суперкомпьютер становится доступным для домашнего использования -- http://www.tgdaily.com/content/view/39056/135/.

И не думайте, что эти суперкомпьютеры нацелены только на очень ограниченные задачи отрисовки экранов. Так, Nvidia поставляет уже второе поколение CUDA -- системы программирования своих графических процессоров для самых разных задач. Для примера поставляется код плагина для Photoshop, который существенно ускоряет его работу -- http://www.tgdaily.com/content/view/39017/140/. Но это только для примера, запрограммированы могут быть и другие задачи. Были бы дешевые процессоры, а к задачам их всегда приспособят -- наверняка где-то уже сидят заточенные под CUDA 2.0 стартапы.

Кстати, электронная бумага тоже потихоньку развивается: вот уже фото газет и цветной бумаги на новой технологии QR-LPD, сейчас это выставляется на IFA 2008 в Берлине: http://www.digitimes.com/news/a20080828PR201.html. А следующее поколение OLED-технологий будет только в 2011 году -- http://www.digitimes.com/displays/a20080829PD206.html
* * *
Бионика на марше: отмоделировав фотосинтез, сделали шажок к добыче водорода из воды при посредстве солнечного света -- http://www.tgdaily.com/content/view/39062/113/. Но не думаю, что КПД будет больше, чем от улавливания света солнечными батареями и затем простого дедовского электролиза. Тем более, что солнечные батареи уже готовятся производить в домашних условиях.
* * *
А пока я опять пожадничал и перебрал месячную норму трафика на 300 рублей. С другой стороны, если бы мне еще пяток лет назад сказали, что мое нынешнее месячное потребление будет вылезать за 72G, я бы сильно удивлялся. А теперь понимаю, что лет через пять-семь и 1Тбайта в месяц может оказаться мало.
* * *
Мне кажется, что я начинаю понимать, куда все это вычислительное богатство девать. Для PraxOS это все очень и очень пригодится.
5 comments|post comment

Управление информацией в системной инженерии: уровни описания [31 Aug 2008|03:33pm]
Уровни описания управления информацией в системной инженерии:

1. Стандарт архитектурного описания и архитектурного фреймворка -- ISO 42010 (проект на сентябрь 2007г. -- http://www.canieti.com.mx/assets/files/807/N3849%20NWIP%20Architecture%20Description.pdf, согласованный с ISO 15288 и, увы, с насквозь документоцентрическим ISO 15289. Как я понимаю, следующий драфт будет в июле -- они согласуются с GERAM http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html и RM-ODP http://en.wikipedia.org/wiki/RM-ODP).

Архитектура -- фундаментальная организация системы, заключенная в ее компонентах, их отношениях друг ко другу и окружению (environment), а также принципы ее дизайна и эволюции. Также: высокоуровневая концепция системы в ее окружении. В xAF дается другое определение: принципы самоограничения в дизайн-выборах.

2. Фреймворк корпоративной архитектуры системной инженерии (PraxOS Симултрек).
architecture framework -- a set of architectural concerns, generic stakeholders, predefined viewpoints, and viewpoint correspondence
rules, that have been established to capture a common practice for architectural descriptions in a specific domain or stakeholder community.

framework -- фреймворк (набор инструментальных средств и правил их применения)
stakeholder -- стейхолдер (лицо, как-то заинтересованное в системе).
concern -- интерес (интерес к разработческим, эксплуатационным, политическим, регуляторным, социальным и иным факторам, который проявляет один или более стейкхолдеров системы).
generic <класс> - абстрактный <класс> (выражение, указывающее на необходимость подстановки во время использования какого-то экземпляра класса (множества всех объектов)).
viewpoint -- вьюпойнт, соглашение по конструированию, интерпретации и использованию вью, адресующего предписанный набор интересов для набора стейкходлеров.
viewpoint correspondence rule -- правило согласования вьюпойнтов.
description -- описание (учтенное описание. Особо замечу, что я перевожу documented как "учтенное" -- совершенно необязательно, чтобы описание было именно в форме документа, я сознательно избавляюсь от документоориентированного языка).
domain -- предметная область.

Архитектурный фреймворк -- набор архитектурных интересов, типовых стейкхолдеров, предписанных вьюпойнтов и правил согласования вьюпойнтов, которые были определены для учёта общепринятой практики архитектурных описаний в конкретных предметных областях или сообществах стейкхолдеров.

3. Корпоративная архитектура конкретного Заведения (architecture, "эскизный проект").

4. Проект системы (design, to be).

5. Configuration management (as built и далее).
* * *
План работы:
1. Понять по-русски, о чем говорит ISO 42010 и сопутствующие ему стандарты, причем адаптировать понятое для датацентрики (см. http://ailev.livejournal.com/611877.html)
2. Разработать PraxOS Симултрек -- в письменном виде.
3. Предложить клиенту его корпоративную архитектуру (которая соответствует PraxOS Симултрек, и которая тем самым соответствует творчески понимаемым ISO).
4. На основе опыта разработки конкретной архитектуры сделать апдейт Симултрека.
9 comments|post comment

Ссылочки [31 Aug 2008|05:55pm]
Мой любимый CYC продолжает свою экспансию: в вебе опубликовано 150 тыс. концептов этой онтологии: http://sw.opencyc.org.
* * *
Похоже, вот место, где занимаются нотационной инженерией: http://www.aaai.org/Library/Symposia/Fall/fs07-03.php. Жаль, доступ к статьям закрыт. Но это уже вопрос техники. Я заинтересовался этим местом потому, что люди из CYC опубликовали там бумажку про изменение репрезентации -- http://www.aaai.org/Press/Reports/Symposia/Fall/fs-07-03.php. Понятен их интерес к этой проблеме, достаточно вспомнить Accretion Model of Theory Formation Дугласа Лената (в конце постинга http://ailev.livejournal.com/469995.html).
* * *
Случайно заглянул в пост годичной давности и прочел там Алана Кея (http://ailev.livejournal.com/469995.html):
8. Стильные языки (APL, Lisp, Smalltalk) и агглютинативные ("клейкие")языки типа PL/1. Стильные языки -- для людей, у кторых есть математическая ленивость, они окупаются через год после начала проекта -- когда у вас появляется сильная идея, и вам быстро-быстро нужно все переделать. Агглютинативные языки сопротивляются этой переделке. Кроме того, стильные языки обычно позднего связывания, а агглютинативные языки -- раннего, что приводит к совершенно разным процессам отладки, дает абсолютно разные типы ошибок. И для стильных языков не нужно беспокоиться об архитектуре фон Неймана. Это раздел двух культур, через эти различия в стилях невозможно общаться.
Я вот думаю, что colorForth -- это стильный язык сверхраннего связывания.

И все чаще и чаще задумываюсь над этой разницей в использовании стильных языков и агглюнативных -- IMHO, дело даже не в самом языке, а в стиле программирования на языке, который поощряется "тусовкой". Вот почитайте мемуар Михаила Донского, который описывает "стильное программирование" независимо от языка: http://www.polit.ru/science/2008/08/20/programmist.html. Он как раз описывает, что сильный программистский коллектив сам себе разрабатывает фреймворк -- чуть ли не от уровня железа. Создает себе стиль, не обращая внимания на язык. И затем на этом фреймворке получает удивительные результаты -- прирученный тобой язык становится могучим и великим, программирование выдерживает стиль от самого верхнего уровня до самого дна (железа). Похоже, что дело не столько в языке, сколько в стиле его использования -- "голенький" язык подразумевает совершенно другой подход.

Все это верно отнюдь не только для языков. Так, какой-нибудь Адизес или Голдратт создает "полномасштабный" стильный бизнес-язык, на котором описывает решение проблем своих клиентов. Число приемов ограничено, все существенно повторноиспользуемо. А какой-нибудь MBA пытается совладать с агглюнативной окрошкой, остающейся после изучения пары десятков готовых "библиотек" и "фреймворков". В жизни встречаются и работают оба подхода, но тут совершенно уместно замечание Алана Кея: "Это раздел двух культур, через эти различия в стилях невозможно общаться".

UPDATE: поговорил с Донским по телефону. Он полностью подтвердил наблюдение Кея, и добавил два важных пункта: 1. Если проект большой (заведомо более года), то в него безопасно идти, только если у тебя свой инструментарий. И только если проект маленький, то тогда безопасно пользоваться всякими фреймворками. 2. "Язык", который обсуждается (хоть Лисп, хоть Кобол) -- это не язык, это только по недоразумению его называют языком. Язык как раз пишется самостоятельно, собственноручно созданный инструментарий -- вот язык, на котором создается большая система!
6 comments|post comment

navigation
[ viewing | August 31st, 2008 ]
[ go | previous day|next day ]