OberonCore

Если взаимодействуют два отдельных приложения - то неважно на кластерах они или нет. Насчет стиля только сомнения могут быть. Вполне возможно что такая связка и не соответствует в чем-то оригиналу.

Извини, отвечаю в свободное время.



В каком общем плане?



Я не собираюсь отстаивать свое предложение.

Демагогия какая-то. В каком месте синтаксис оберона обеспечивает контроль выхода за пределы массива или ошибочное приведение типов? А адресной арифметики в managed коде на уровне синтаксиса в том же C# тоже нет.



Ну отсутсутствует, и чего?



Где результаты тестов?

В спецификации уважаемый... На самом деле все это требования ЕДИНСТВЕННОГО языка, и можно все смело оптимизировать не оглядываясь на другие языки (а в .net - приходится оглядываться! - это и есть managed). Более того, сами синтаксические конструкции были выбраны с учетом максимальной эффективности их компиляции и оптимизации, а все то, без чего можно обойтись (но, возмножно, нельзя эффективно скомпилировать) - было выкинуто. В этом и отличае изначальных постановок задач у .net и "оберон". И язык промежуточный для того же - чтобы объединять разные языки.
Я хочу подчеркнуть что считаю .net - отличной платформой для определенного круга задачь. Но далеко не все задачи можно эффективно решать в .net. А в ББ - гораздо больше (вот еще бы многозадачность )

Возможно есть тесты, где .net быть будет в вигрыше, я не буду априорно спорить. Но я знаю, что на задачах обработки нестандартных данных - il ассемблер проигрывает (и именно по своей универсальной природе) . Мне пришлось учавствовать в оптимизации двух задачь под нет: цифровая обработка изображений (RGBA формат) и парсинг больших текстовых файлов в нестандартных кодировках. Обе задачи оптимизировалиь в тесном контакте со специалистом из MS. Результат - всегда быстрее оберон. Совет специалиста из MS - сделайте нативную библиотеку на C++ и подцепите к .net...

Дополнительно насчет "демагогии". На самом деле все далеко не так однозначно как кажется. Приведу пример из другой точной науки - математики:
Широко извесна аксиома параллельности Евклида, которая гласит: параллельные прямые не пересекаются (а также две ей противоположные: параллелные прямые пересекаются/расходятся). Однако окола ста лет назад по поводу этой аксиомы разгарались отнюдь не шуточные страсти. И одним из камней предкновения был именно вопрос о терминах. дело в том, что подчти из одних и тех - же аксиом (не считая аксиомы параллельности) были получены в общем то похожие, но в частностях абсолютно противоположные результаты. И когда адепты одной "школы" начинали употреблять термин "рассотояние между прамыми" - другие приходили в бешенство, говоря что такой термин не может быть даже определен - и все были правы. Все дело в базовых понятия. И ТУТ именно так. Все вроде похоже, так как описывается общая "реалность" ("модульно-структруные" языки программирования), но все дело именно в "ОТТЕНКАХ" смысла, из которых можно сделать ой как неодинаковые выводы.

Цитату приведешь?



Пример?



Синтаксические конструкции могут упрощать оптимизацию. Учитывая то, что оптимизит все равно компилятор, а не человек, не вижу смысла в том, чтобы жертвовать ради этого наглядностью/удобностью и т.д.



И это проблема. Язык, приносящий в жертву простоте компилятора все остальное, интересен только как язык удобный для компилирования.



И в этом причина "непопулярности" оберона. А вовсе не маркетинг...



Я плакаль... (с)



Да ладно. Покажи тесты, где BB не в проигрыше Будет очень интересно посмотреть.



Код в студию!

Не собираюсь я вам ничего доказывать. Просто я излишне углубился в ненужные (не относящиеся к теме вопроса) технические подробности и вы тут-же подхватили. Для обсуждения подобных тем есть другие ветки, вроде Си vs Паскаль. Здесь же речь идет о многопоточности и проблемах ее введения конкретно в ББ. Давайте лучьше обсудим конкретный вопрос. К тому же, как я понял, у вас богатый опыт парралельного программирования...

Интересно, откуда сделан этот вывод. Тема образована модератором из темы посвященной именно многопоточности. В общем с тем же составом участников. Другое дело, если обсуждается оригинальная идея. Тогда выигрывают все. А сейчас, увы.

Он не был в курсе о сравнении с обероном . Просто давал советы как оптимизировать код на .net (когда еще никто не знал толком что это такое). Нашли его через форум тех. поддержки MS, так что ни в каких проектах он не учавствовал... но это и не запрещено. Есть такой граф. редактор Paint .NET - он OpenSource и прямо поддерживается MS. В нем как раз на все теже грабли (что и мы) и наступили. Но мы в конце концов реализовали все через нативный код (наш проект не OpenSource).

Давайте. Хотя вроде уже пришли к выводу, что наиболее работающий вариант - несколько инстансов + передача сообщений и, очевидно, механизм сериализации.



Не очень богатый. И я никогда не сталкивался с устройством многопоточных GC.

Так вот. Практически единственными возможностями, играя которыми из С++ можно выжать более эффективный код (по сравнению с .NET), остались отсутствие GC и шаблоны. Ни того ни другого в оберонах нет. Поэтому откуда был сделан вывод о том, что совет о применении "нативной библтотеки на С++ для большей эффективности", можно применить и к оберонам - я не понял.

Я думаю, что этот вывод был сделан в результате проведения тестов Oberon- и .Net варианта. Хотя тесты могут давать не то что заявляется. Учитывали ли они время подготовки приложения к работе? Оно, вероятно, все-таки разное.
P.S. Однако, этот вопрос действительно лучше отдельно обсуждать. Меня, например, волнует относятся ли возможности специализированных решений больше к возможностям окружения или к установившемуся стилю использования среды.

Да, да. То-то уже упомянутый Paint .Net (http://www.eecs.wsu.edu/paint.net/) тормозит безбожно по сравнению с любым нормальным (нативным) графическим редактором. А в разработке учавствует между прочим MS (и крайне в ней заинтересована как в рекламе возможностей .net). И GC тут ни причем - MS предоставила достаточно механизмов для "тонкого" управления сбором мусора, чем Paint .Net с успехом пользуется. А как влияет на скорость готового кода препроцессор я вообще не понимаю.


Да, так оно и есть. Просто сначала хочется разработать концепцию интерфейса (модуля/модулей) для посылки/приема сообщений, а уж затем что-то реализовывать. Хочется чего-то не очень сложного...

"edu" - это что, еще одна студенческая поделка?



Это ни о чем не говорит. Вот если бы она туда грохнула денег, как в фотошоп...



Начни с понимания того, что шаблоны это не препоцессор.



Ну вот тебе с ходу:



Проще некуда

Пожалуй, стоит добавить в этот список

Однако, не лучше ли вначале определиться с тестовой задачей и начать её реализовывать. А потом и до обобщений в интерфейсе дойдем.

Для отписки есть message_connection, который возвращается при подписке. Но это непринципиально. Просто еще один уровень индирекции иногда может оказаться удобнее.



Ну это к тому, кому многозадачность нужна прямо сейчас.

[quote="Алексей Елин"]Абсолютно согласен. К сожалению для меня это ОЧЕНЬ большой барьер для использования BB - остуствие ПОДДЕРЖКИ параллельного программирования хотя бы в каком-то виде.[/quote]
imho ona prosto tam i ne nugna sovershenno))
BlackBox eto sreda dlya razrabotki i zapuska PRIKLADNYH programm. dlya kagdoy zadachi - svoya, lichnaya. Komponentnost BB oznachaet tesnuyu integraciju chastey, eto meshaet rasparallelivaniuy v principe!
Mnogozadachnost ge eto delo OS. eto EE problema kak delat neskolko zadach srazu. A esli zadacha hochet delat neskolko deystviy srazu, ona prosto doljna imet v sebe svoy lichny prostenkiy kooperativny specializirovanny sheduler procedur vnutri. Eto obychno na poryadok bystree chem ispolzovat universalnie
(i tormoznie) sredstva OS. No delo ne tolko v skorosti a eshe i
v bolshey prostote i determinirovannosti resheniya. To est - glukov prosto ne budet... polistayte obzor OS Portos, Contiki...
kstati sistema Oberon toge odnozadachna... pochemu OldNick tak sdelal, a?))... odnozadachnost ne meshaet ni processoru ni polzovatelu delat neskolko del srazu))...
eshe primery... est odnozadachnie bystrie web-servery (tipa thttpd),
servery baz dannyh... i tak dalee... mnogopotochnost prikladnym programmam NE NUGNA! SOVSEM!
a vot NABOR iz neskolkih programm konechno moget rabotat na neskolkih processorah srazu, obmenivatsya dannymi, reshat obschuyu zadachu... eto uge vygodno v plane ispolzovaniya kesha i ekonomii propusknoy sposobnosti pamyati...

tak chto imho luchshe by vsem jelayuschim sosredotochit usuliya na portirovanii originalnogo BlackBox pod NetBSD i Linux, na razvitii ego kompilyatora... vot eto bylo by ochen polezno... i ne zanimatsya resheniem problem kotoryh na samom dele NET...

vot imenno ETO budet v duhe Oberona))

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

popodrobnee pliz, s primerami boli))
posmotrim i podumaem, realnye li byli problemy...
neoborimie trudnosti s deleniem dlinnogo vychisleniya na etapy?

ved pod shedulerom ne sleduet ponimat nechto slognoe,
s prioritetami i t.p... obychnaya procedura eto toge sheduler))
on nastolko prost chto ih moget byt neskolko na vse sluchai))

kstati sudya po literature golovnaya bol naoborot padaet.
potomu chto strogo determinirovano vypolnenie i prosto ottestirovat.
a "dopolnitelnie sredstva sinhronizacii" prosto ne nugny...

vzaimodeystvie ge s OS odinakovo slognoe nezavisimo ot "potochnosti"
programmy...

Боль в том, что вообще надо что-то делить. Из-за этого в коде появляются инородные включения в лице всяких callback'ов и т.п.



Ну конечно. Представь простейшую ситуацию - интерфейсный поток (кнопочки, окошки) и вычислительный. И попробуй написать "шедулер", который будет нормально распределять ресурсы между обоими (а не тупо переключаться с одного на другой). Нет, я понимаю если речь идет о какой-то железке, где все в твоих руках и даже ОС нет. Тогда можно все по тактам расчитать под конкретный проц. А если речь идет об обычной винде/маке/линуксе - программа с таким "шедулером" будет жрать 100% ресурсов и при этом ничего полезного не делать.



Какого года эта литература? Народ вовсю многоядерными процами затаривается, а вы нам тут W3.11 рекламируете....



В общем случае все равно нужны.



Очень хочу посмотреть на однопотоковую работу с COM-портом в винде.