rfq
+2
про паттерны я обычно отвечаю, что я как господин Журден, который не знал, что разговаривает прозой. Но как-то удосужился просмотреть список паттернов и нашел в нем только полтора, которые следовало бы изучать — Visitor и MVC. Остальные нормальный программист переизобретет, как только они ему понадобятся.
rfq
+1
они все думают, что в 46 станут большими начальниками. А кто не стал тот лузер.
rfq
0
«Идеи, использованные в языке FP, были использованы при создании языка LISP» — это ж надо было такое написать. FP — 1977, LISP -1958 год.
rfq
0
Я сам слушал лекцию Бабаяна, где он говорил про переименование регистров, то ли в Э-1, то ли в Э-2. А вы про который рассказываете?
rfq
+3
Это вы тут пытаетесь передергивать, утверждая, что якобы «отрицать наличие» это не то же самое, что «утверждать отсутствие».
rfq
0
Я полагаю, проблема 95/5 настолько сложна, что одним каким-то способом ее решить невозможно. Если «отторжение дефективных» в каком-то виде поможет ее решить, его надо применять. Например, минусовать ръяных минусователей с пометкой, чтобы всем было видно, что это тролль. И вообще, я за то, чтобы свою схему расчетов репутаций и прав могло ввести любое достаточно значительное подмножество пользователей, не лишаясь доступа к общей базе вопросов и ответов.
rfq
0
«Сколько недо-продуктов будет нас окружать?»
Так уже.
Домашний компьютер, Windows 10: выдает тихий звук. Переустановка драйвера возвращает звук в норму. На следующий день опять тихо.
IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
Лифт в здании, где я работаю: иногда отказывается везти на 4 этаж.
Накачал музыкальных обучающих программ — ни одна не работает как следует.
rfq
–7
А они и работают быстро. Отстают от С++ в 1.5...2 раза: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp
rfq
0
Нет, не из-за спекулянтов. Успешный спекулянт покупает на минимуме цены и тем самым минимальную цену поднимает, продает на максимуме и тем самым максимальную цену сбивает. То есть, без спекулянтов скачки были бы еще больше.
rfq
+1
Раз случайное блуждание, то с вероятностью 50% будет выигрыш, и 50% проигрыш.
Если же вы почти гарантированно совершаете сделку на невыгодных условиях, то вот вам алгоритм: совершайте обратную сделку, покупку вместо продажи и наоборот. Если вам именно необходимо продать, то сделайте покупку бОльшего объема, и покроете убытки с лихвой.
rfq
+1
Любой запрет на торговлю приводит к тому, что либо повышается цена покупки, либо понижается цена продажи, либо то и другое вместе. Ваше «исправление ошибки» ударит по карману продавцов и/или покупателей. Соответственно, нынешний заработок спекулянтов можно рассматривать как компенсацию за то, что они улучшают цены.
rfq
+1
статистический анализ, было сказано. Анализируется статистика выполнения программы в рантайме и под нее модифицируется машинный код, например, инлайнятся процедуры.
rfq
0
а способ, описанный в github.com/stephanenicolas/robospice — он что, некорректен или неуниверсален?
rfq
0
CRP у вас это что?
rfq
+1
«В процессе развития программного обеспечения возникла потребность, чтобы система умела реагировать на множество источников данных, была устойчива и чтобы разные модули не были тесно связаны».

Можно подумать, в первые 50 лет развития программного обеспечения не было потребности, чтобы системы могли реагировать на множество источников данных и т.п.

Во всей этой reactive движухе, кроме болтологии, единственная здравая мысль — это мысль о необходимости backpressure, то есть обратной связи для предотвращения переполнения памяти в случае, если поставщик работает быстрее потребителя.
rfq
0
Только вот запустить и передать данные в изолят накладнее, чем в другой процесс ОС.
rfq
+11
За троллинг ему надо было влеплять заслуженный плюс.
rfq
0
пареллелизма в них нет настоящего.
rfq
0
Пора застолбить за собой термин (пока не застолбили другие) — «потоково-структурный дуализм», по аналогии с корпускулярно-волновым. Само понятие давно используется программистами — например, база данных может быть представлена как снапшот, или как лог транзакций, или совместно. Поток событий формирует структуру, изменения структуры формируют поток событий. Этот дуализм просматривается везде — и в объектно ориентированном программировании, и в системах управления версиями исходного кода. Беда однако в том, что обычно упор делается на одно представление, а второе рассматривается как необходимое зло, которое пытаются замести под ковер. Но насколько бы логичнее, например, рассматривать службы очередей сообщений совместно с базами данных, объединеных единым управлением транзакциями, а не отрывать их друг от друга сначала, а потом пытаться склеивать.
rfq
+1
Секвенирование — это считывание молекулярной структуры, а отнюдь не поиск мутаций. Подобные статьи надо давать на проверку описываемой организации и людям, чьи высказывания цитирутся, как это принято делать с интервью.
rfq
0
Использовались как телетайпы, так и пишущие машинки «Консул» ( с возможностью ввода-вывода на перфоленту).
rfq
0
в каком смысле соответствуют? Семафо́р — объект, ограничивающий количество потоков, которые могут войти в заданный участок кода. Можете дать какие-нибудь ссылки по этому вопросу?


Ссылок дать не могу, так как не встречал таких описаний.

Вкратце, идея такая: берем блок-схему алгоритма — это граф, по которму гуляет токен (фишка) управления. Чтобы распараллелить алгоритм, запускаем туда несколько токенов. Чтобы они не мешали друг другу, договариваемся, что каждый токен свободно гуляет по сврему участку, а общие участки посещают через синхронизаторы -это такие барьеры, напоминающие переходы в сетях Петри. У барьера несколько входов (обычно 2), на каждый вход поступают токены, и когда токены присутствуют на каждом входе, то комплект токенов (по одному с каждого входа) удалаяется. Семафор — синхронизатор с двумя входами, один для токенов управления, а другой для токена, символизирующего разрешение доступа к данному участку кода. Так вот, такую параллельную блок-схему можно реализовать, не меняя, как с помощью потоков, так и с помощью тасков. В акторах непременно присутствует такой семафор, чтобы обеспечить последовательную (предотвратить одновременную) обработку сообщений.
rfq
0
Если вы хотели противопоставить Task-based parallelism и программирование с помощью потоков управления (threads), то, с одной стороны, потоки также могут обмениваться сообщениями (через блокирующие очереди), а сдругой стороны — таски (агенты в вашей терминологииФ) могут обмениваться сигналами, то есть сообщениями без информации, и эти сигналы точно соответствуют семафорам в многопоточном программировании.
rfq
+2
Если бы это был студенческий реферат, то больше тройки я бы не поставил.

0. Повсевместное использование «message passing» вместо «передача сообщений» вызывает смутные подозрения.

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

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

3. Поскольку передаче сообщений нет альтернативы, то не понятно, в сравнении с чем описываются «особенности message passing».

4. Передача и прием сообщений могут быть организованы по разному. Хотелось бы видеть классификацию разных способов.

5. Наиболее интересная проблема в обработке сообщений — противоречие между асинхронностью и параллелизмом. Попытка исполнять callback'и параллельно часто заканчивается провалом. Причина в прямолинейном сопоставлении сообщение -> реакция, в то время как реакция должна выполняться только при поступлении полного набора токенов, как в сетях Петри.
rfq
–2
Наставили автору минусов, продемонстрировав тем самым отсутствие чувства юмора. Что кагбэ намекает, что автор прав — потому что чувство юмора — высшее проявление разума.

Отдельно хочу согласиться с тезисом о дискриминации тестировщиков. Ухарь-программист прочитал наискосок спецификацию и быстро сварганил вроде работающую программу. Тестировщик внимательно прочитал спецификацию, запрограммировал проверку corner cases и ткнул программиста в его собственное дерьмо. За это программист презирает тестировщика — как рыцари презирали купцов. И где теперь купцы, а где рыцари?
rfq
+2
Я бы предложил изменить последовательность подачи материала:

— начать с высокоуровневых понятий, а именно передачи сообщений синхронным (блокирующие очереди) и асинхронным (акторы) способом, чтобы ученики сразу имели возможность писать работоспособные программы

— соответственно, низкоуровневые и аппаратные механизмы перенести в конец, когда ученики станут способны чувствовать параллелизм и его проблемы

— не повторять в учебном плане историю развития, оставляя “неклассические архитектуры” на потом, а выработать наиболее усвояемую классификацию задач и решений и ей следовать. Научить сначала классифицировать задачу, а только потом подбирать для нее готовое решение из запаса. А то весь ваш план — список решений, причем разные решения для одной и той же задачи изучаются в разных местах, что затрудняет возможность выбора (например synchronized/wait/notify vs Lock/Condition), в то время как о проблематике как таковой ничего не говорится.

— добавить изучение CompletableFuture из java8
rfq
+2
6 этих способов можно разбить на группы:

a) универсальные:
— пессимитические: synchronized, locks
— оптимистические: lock-free, stm
b) частные:
— иммутабельные: обеспечивают только чтение общего состояния
— isolated mutability: инициирующий поток не нуждается в результате (по крайней мере, немедленно), поэтому может выдать задание (или послать сообщение) и продолжить свою работу. Замечу, выдача задания также требует работы с общим состянием (планом вычислений) и, соответственно, обращения к универсальным методам.
rfq
0
Ну как же, вот у вас работа с коллекциями: в каждой итерации цикла 2 раза Mat.get и 1 Mat.put. Кто его знает, сколько они времени тянут. В С++ версии они тоже есть?
rfq
0
причем k>log(N). Полагаю, что сортировки с временем O(N) нереализуемы, O(N*log(N)) — максимум чего можно добиться, и это как-то можно вывести в рамках теории информации.
rfq
+5
а про wavelet image stabilization вы что-нибудь читали?
rfq
0
я так понимаю, это эквивалентно future.thenApply(function)
rfq
+2
более мощная абстракция — это вы имете в виду Observable? Нет, ее нельзя сравнивать напрямую с futures/promises, это разные вещи — примерно как массив и скаляр. Вы же не будете все скаляры заменять массивами только потому, что массив — более мощная абстракция. Аналогом Observable в java8 является Stream — абстракция того же порядка, но (к сожалению) лишенная важных деталей — способности передачи ошибок и сигналов окончания.
rfq
0
Разве Promises A+ — это стандартная часть JavaScript'а? Это какая-то сторонняя библиотека. Для Явы такие сторонние библиотеки появились как минимум несколько лет назад.
rfq
0
SettableFuture беднее — не имеет методов для асинхронного заполнения, и только один метод асинхронного чтения: addListener, эквивалентный thenRunAsync.
rfq
0
Unsafe — putIfAbsent в ConcurrentMap
— это вы так назвали вариант http://stackoverflow.com/questions/21286831/managing-multiple-locks/21339300#21339300? Что ж в нем небезопасного? Если вы там обнаружили ошибку, то сообщите в комментарии к варианту.

Далее, putIfAbsent там используется только в случае столкновения на конкретном id, то есть достаточно редко.

И 12192 мс для 10^7 операций — это 1 микросекунда на операцию, а не наносекунда.
rfq
0
Вероятно, при том, что разработчики Raspberry Pi считаются ни разу не грамотными и им надо объяснять if и while.
rfq
0
http://stackoverflow.com/questions/21286831/managing-multiple-locks

В предложеном решении, как и у вас, объекты удаляются сразу, как стали не нужны. Возможно, лучше было бы выдержать некоторое время.
rfq
+1
Недавно на stackoverflow спрашивали, как сделать подобную блокировку: . Было предложено безопасное решение без блокирования таблицы локов и без создания лишних объектов.
rfq
+5
Это не причина, чтобы не ссылаться. Есть устоявшиеся правила написания научных статей.