Программирование - это просто

sami

Местный
Не, не.

Само по себе использование GPU (NUMA) и кластеров и распределённых вычислений ничего общего не имеет со взломом и грубой силой.

Тут видно смешение понятий произошло.

Брут-форс это именно грубый взлом (часто прямым перебором), а не метод высокопроизводительных вычислений :)
http://en.wikipedia.org/wiki/Brute_force

Самое первое значение - Brute force, a style or method in which strength is used where other (usually easier) methods could be used to solve a problem or fill a need.
Статьи нет.
Второе - Brute-force search, a trivial computer problem-solving technique
И только третье значение - взлом.

Да, про высокопроизводительность брут-форса я ничего не писал :p

Таже история и с хакерами (http://ru.wikipedia.org/wiki/Хакер) - искажение первоначального значения слова.
 

sami

Местный
Введение в Haskell в картинках
http://learnyouahaskell.com/

Без всяких заумностей. Фактически для детей ;)
Не совсем для детей, но старшекласснику должно быть позубам.
(на английском)
 

Mike22

Местный
Встречаем новый язык программирования от Microsoft - Axum

Не успели мы ещё познакомитя с F# и новыми возможнастями .NET 4.0, как Microsoft представила новый язык программирования Axum (на самом деле Axum был представлен ещё до выпуска первой бета-версии .NET 4.0). Раньше он имел коддовое название Maestro.

Что же представляет собой Axum? Это язык для паралельной разработки (parallel model language), который позволяетлегко создавать легкомасштабируемые, распределённые и многопоточные приложения. Лично мне синтаксис этого языка напомнил Erlang, которые имеет изменённый синтаксис и является полностью .net-совместимым языком программирования.

Даже и не знаю, как это прокомментировать.
Думаю это опять типичная политика MS - создавать новые стандарты пользуясь своим доменирующим положением на рынке.

Кому-нибудь новый язык нужен? :rolleyes:
 

sami

Местный
Встречаем новый язык программирования от Microsoft - Axum
Вообще-то это не совсем язык. В том плане, что это пока инкубационный MSR концепт (например каким был до превращения в LINQ), выльется ли он в самостоятельный язык, или вольется в C# или/и F# - пока неизвестно. Народ, приближенный к MSR полагает, что вольется в C# 5, что немного не совпадает с точкой зрения команды Axum, представленной на сайте. Ну тут уж им придется сплясать под дудку маркетинга M$.

По поводу сравнения с Erlang-ом:
От Erlang-а только позаимствована система сообщений и акторов. В остальном же в Axum-е громоздкий синтаксис и вообще он не функциональный. (как следствие обязан иметь проблемы с синхронизацией и дедлоками). Насколько я понял, Axum из линейного императивного кода генерит конечный автомат с состоянием в куче (это гораздо проще было бы прикрутить к Nemerle с его развитым метапрограммированием).

Кроме того, Erlang работает на легковесных процессах с автоматическим вытеснением, а такие штуки в рамках платформы CLR невозможны. Если в Erlang-е могут крутиться сотни тысяч потоков, то в CLR - лишь пара десятков.

Даже и не знаю, как это прокомментировать.
Думаю это опять типичная политика MS - создавать новые стандарты пользуясь своим доменирующим положением на рынке.
Причем тут создавать стандарты? Агентные фреймворки не новы.

Кому-нибудь новый язык нужен? :rolleyes:
Язык - вряд ли. А вот агентный фреймворк на CLR был бы полезен для некоторых задачь. Но вот что-то у меня сильное сомнение по поводу совместимости таких вещей с императивным подходом. Совместить-то можно, но будет ли это столь же эффективным как в функциональном подходе?
Походу Axum это лишь большая сахарница, сделанная по мотивам Erlang-а. На днях скачаю и гляну что там под капотом.
 

sami

Местный
На днях скачаю и гляну что там под капотом.
Да, как и предполагал, линейный код преобразуется компилятором в конечный автомат, висящий в куче.
Вот такой пример из Guide-а
Код:
 public AdderAgent() 
{ 
int result = receive(PrimaryChannel::Num1) + 
receive(PrimaryChannel::Num2); 
PrimaryChannel::Sum <-- result; 
}
Преобразуется в нечто:
Код:
[Strict]
public override void Invoke(IActivationFrame __leaf)
{
IActivationFrame __selframe$1;
bool __neverPaused = this.ContinueAt == 0;
IActivationFrame __lframe = this;
switch (this.ContinueAt)
{
case 2:
break;

default:
__selframe$1 = this.SelectFrame(__leaf);
if (__selframe$1 == __lframe)
{
__selframe$1 = this.__parent.__CreateAsync__receive<int>(this.__parent.PrimaryChannel.Num1, this);
__leaf = __selframe$1;
}
__selframe$1.Invoke(__leaf);
if (!__selframe$1.Exited)
{
this.ContinueAt = 1;
return;
}
__leaf = __lframe;
__leaf.ContinueAt = -1;
break;
}
IActivationFrame __selframe$2 = this.SelectFrame(__leaf);
if (__selframe$2 == __lframe)
{
__selframe$2 = this.__parent.__CreateAsync__receive<int>(this.__parent.PrimaryChannel.Num2, this);
__leaf = __selframe$2;
}
__selframe$2.Invoke(__leaf);
if (!__selframe$2.Exited)
{
this.ContinueAt = 2;
}
else
{
__leaf = __lframe;
__leaf.ContinueAt = -1;
this.result = ((MethodFrame<int>) __selframe$1).Result + ((MethodFrame<int>) __selframe$2).Result;
Agent.asend<int>(this.__parent.PrimaryChannel.Sum, this.result);
this.Complete(__neverPaused);
}
}

От Side Effect-ов решили избавиться путем изоляции мутабельных состояний в неких "доменах" (подобие класса). Судя по всему (пока догадка), в домене может крутиться только один поток. Походу при принятии компонентой сообщения, поток заходит в домен, переключает автомат в очередное состояние и выходит. Доступ к состоянию без синхронизации, значит логично предположить что синхронизация где-то выполняется при входе в домен.

Итого, Axum - высокоуровневый agent-based язык, берущий синихронизацию на себя.
Эффективность такого решения спорная как в плане производительности, так и в плане стоимости разработки (довольно многословен).

Кроме того, решения по упрощению распараллеливания на базе конечных автоматов уже известны и в голом .Net 2.0 (здесь). А это значит что C#, F#, Nemerle, VB.net и многие другие языки платформы могут без проблем использовать такой подход.
 

sami

Местный
Наткнулся на статью Functional Programming For The Rest of Us и вспомнил, что есть ее перевод на русский.

Очень рекомендую ознакомиться тем, кто не знаком с преимуществами функционального программирования.
Статья доходчивая, примеры императивные. Базовых знаний ФП не требуется.
 

notacat

Местный
Algorithm implementation/Sorting/Quicksort
Обширный набор реализаций одного и того же алгоритма на различных языках.
Довольно любопытно выглядит в сравнительном аспекте.
впечатляет. Некоторые языки не доступны моему пониманию. Я б все примеры поделила по принципу human-readable и не-readable-at-all. Интересно, как люди эти нечитаемости изучают - один раз посмотришь и прикасаться не хочется.
 

sami

Местный
впечатляет. Некоторые языки не доступны моему пониманию. Я б все примеры поделила по принципу human-readable и не-readable-at-all. Интересно, как люди эти нечитаемости изучают - один раз посмотришь и прикасаться не хочется.
Нормально изучается! Если знаешь один императивный язык высокого уровня, то другие императивные языки высокого уровня как минимум понимаешь. Так же и с другими.
Начал недавно изучать F# (порт OCaml-а на .NET платформу), и с удивлением обнаружил, что основные из функциональных языков стали вполне читаемые для меня. Из этого списка Erlang, Haskell, семейство LISP, Python, Prolog, семейство *ML вполне себе стали доступными для понимания. Писать, конечно, с разбега на них не смогу.
 

SCTRWD

Местный
впечатляет. Некоторые языки не доступны моему пониманию. Я б все примеры поделила по принципу human-readable и не-readable-at-all. Интересно, как люди эти нечитаемости изучают - один раз посмотришь и прикасаться не хочется.

ИМХО, это только вопрос отношения. Я Lisp изучал в универе, если честно, тогда очень тяжело дался :lol:. Но потом уже на производстве программил под Емакс и Gimp - просто прелесть. Настолько изящно многие концепции в него укладываются, даже диву даёшся. Когда окунёшся внутрь, всё становится элементарным и простым. B) Хотя со стороны, полностью согласен, кажется просто чем то жутким.
 

Жадный КаБан

Санкт-Петербург

sami

Местный
Раз тема зачахла, надо немного ее разрядить:
Программисты: эволюционный подход
Я тут смотрела фотки с нового года для детей сотрудников и поняла - основой нового общества станут программисты. То есть, как после атомного взрыва выживут тараканы и крысы, так после постмодернизма, "смерти взрослых", социетального кризиса и окончательного исчезновения реальности выживут программисты. Я практически уверена. Они будут господствующей разумной формой жизни на Земле, потому что, именно они обладают всеми признаками обеспечивающими выживание.
http://users.livejournal.com/akme_/154221.html
 

~Бес~

Новичок
Вот решил спросить кто за что. Я видел тысячи программ на Delphi и C++. Сам учусь программировать на Delphi. Хочу узнать ваше мнение по поводу обоих сред. Приводите лучшие проги написанные на этих языках. Преимущества - недостатки.
P.S. В одной нашей школе прямо на уроках по информатике детей мучают Delphi с 9 класса.

Ммм...дельфи...язык студента...изучай ассэмблер,намного эффективнее будет)
 

vortex

shaken, not stirred
Кстати, некоторые суперкомьютеры (из последних, возможно еще в разработке) имеют на борту несколько дюжин GPU, что и выводит их на первые места по производительности. Где-то была ссылка на форуме...
Ну что сказать? Начните этим РЕАЛЬНО заниматься, для реального серьёзного промышленного комплекса - и всё сами поймёте.
Уверяю Вас, я этим плотно занимался, и знаю о чём говорю. Просто вдруг, откуда ни возьмись, выплывут некие ограничения, которые сведут всю идею на нет.
SCTRWD, надеюсь этим авторитетам вы доверяете?:
The Top Trends in High Performance Computing
For the nearest future scenario of HPC systems we expect that the hardware architecture will be a combination of specialized CPU and GPU type cores.
Для примера- работающий кластер:
Supercomputer "Tsubame" from the institute of Technology in Tokyo we have the first system in the TOP500 list that is running "Tesla"-Graphics-Chip from Nvidia. The system-cluster consists of 170 Tesla-S1070-systems resulting in 170 Teraflops –theoretically. In practice the system reaches 77,48 Teraflops, which means number 29 in the ranking of the TOP500 list (November 2008).

Есть уже готовы решения на базе NVIDIA GPU, которые предлагаются, в том числе, отечественными производителями.
http://www.nvidia.com/object/io_1226945999108.html
 

SCTRWD

Местный
SCTRWD, надеюсь этим авторитетам вы доверяете?:

Надеюсь, Вы хоть прочитали текст по ссылке.

А так: затраты на перевод программы под работу под GPU просто несоизмеримы с "мнимым" выйгрышем.

А их авторитеты и бенчмарки мне до фени. Я пробую уложить СВОЮ программу в их рамки, и ничего не получается. GPU именно потому такой быстрый, что пользует только свою, маленькую память. Это - залог успеха в бенчмарках и тестах. Но это - 1% всех возможных применений, ещё и специально притянутый за уши и переписывание программы с ног наголову.

Вам нравится GPU? Дайте мне возможность работать с минимум 4Gb памяти на процесс, с возможностью координации процессов своей работы(хотя бы тривиальный Mutex). Иначе все Ваши GPU - дорогая, ни кому не нужная игрушка. Для серьёзных программ пара сотен килобайт - это не размеры, и никак не оправдает никаких изменений в коде.

Стоит только завести речь о серьёзных массивах данных - гигобайтах, как вся GPU шумиха сходит на нет и всё возвращается на круги своя - SMP процессоры, их взамодействие, переключение контескта и т.д.

Ну не все программы можно перевести в режим Spoon feed. Не все задачи к этому готовы. И уж реальные, боевые программы, - точно не Ваш клиент.
 
Сверху