Здравствуйте, ·, Вы писали:
S>> Еще раз NGEN и .Net Native это разные вещи. S>>Из-за рефлексии нельзя многе оптимизировать компилятору. И по сути NGEN приводит только к снижению затрат на загрузку, но по сути то компилятор то тот же JIT. ·>Это как? ngen вроде работает до запуска приложения. Как оно может JIT?
Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
• Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
• NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
S>>>> Один раз скопилировали под плптформу и её уже устанавливают на миллионы устройств. Какая нафин нагрузка? Найти в Базе нужную модель? S>>·>Я не о количестве самих устройств. Почитай внимательно что я пишу. Компилировать _каждое_ приложение под _каждую_ платформу _каждой_ версией фреймворка. Тот же андроид и под армы, и под интелы, и под 32 бита, и под 64. Конечно, если будет одна единственная платформа и версия фреймворка, то проблем со сборкой будет меньше, я это и говорил. Но это имеет свои недостатки. S>> Ну и сколько этих самых платформ? То есть твой хваленый JIT справляется, а С++ компилятор нет? Мало того многие приложения на С++ распространяются в исходниках, что бы компилировались под машину. ·>Я точно не знаю, вроде больше десятка платформ. ·>Какой "мой хвалёный JIT"? Очередной раз повторяю — в ART сделали AOT. А до этого был Dalvik с JIT; что интересно переход был абсолютно прозрачным, они заменили реализацию платформы, а андроид-программисты вообще это не заметили, те же бинарики просто стали работать на новой платформе, уже с AOT вместо JIT. А не этот пипец от майкрософт, когда они каждый год-два выпускают новую несовместимую технологию (ты уж штук пять назвал).
А ART может работать без платформы? Или все таки это аналог NGEN? Различие читай выше.
S>>>>·>Какой ещё "более" оптимизирующий компилятор? Более чем что? S>>·>Ы? S>> Еще раз. Кроме инлайнинга, оптимизации алгоритмов. Есть еще и проблема с рефлексией? которые тоже не дают обширное поле для оптимизации S>>https://msdn.microsoft.com/Ru-ru/library/dn600640(v=vs.110).aspx ·>А какая проблема с рефлекией в Java на Андроиде? Просто она работает значительно медленнее, но никаких модификаций кода не требуется.
Угу. Тогда это аналог NGEN.
S>>·>А в .net native есть? S>> Не знаю. Но там используется С++ компилятор который это умеет. S>>>>stackalloc программист сам знает где вставить, зачем мучать JIT компилятор. S>>·>Компилятор железный, его не жалко мучить. А программисты денег хотят за мучения. S>> Ну программист использует await или Linq, а stackalloc ничем не сложнее ·>await/linq даёт более красивый, короткий, читабельный код. stackalloc — это просто средство ручной оптимизации.
А чем это плох stackalloc ? Он ничем не хуже ref returns
S>>Кроме того появятся ref returns ·>Интересная фича. Спасибо.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>
S>>Универсальная платформа Windows (англ. Universal Windows Platform, сокр. UWP) — платформа, созданная Microsoft и впервые представленная в Windows 10. Целью данной платформы является помощь в создании универсальных приложений Windows[en], запускаемых как на Windows 10, так и на Windows 10 Mobile без изменения в коде. Есть поддержка создания таких приложений на C++, C#, VB.NET и XAML. API реализован в C++ и поддерживается в C++, VB.NET, C#, F# и JavaScript.[1] Разработанная как расширение для Windows Runtime платформа была представлена в Windows Server 2012 и Windows 8, где позволяла запускать приложения на разных аппаратных платформах.[2]
_>Встречал уже на этом форуме глупые ожидания какого-то прорыва от UWP. Но пока ни один из фанатов данного подхода не смог ответить на один мой простейший вопрос: кто и зачем будет сейчас разрабатывать приложения под UWP? UWP позволяет писать приложения работающие на win10 и win10 mobile (мёртвой платформе). А банальные древние win32 приложения позволяют писать приложения работающие на win10 и на всех старых виндах (которые кстати пока ещё даже популярнее win10). Соответственно совершенно непонятно кто в своём уме будет тратить ресурсы на переобучение под новую технологию, которая в итоге принесёт гораздо меньше пользы чем старая.
Есть Xamarin который типа поддерживает и UWP.
_>Сразу отмечу, что я критикую не саму абстрактную идею универсальных приложений (сама то по себе идея не плохая и теоретически даже имела бы некие шансы на успех скажем в 2007-ом году, когда MinMobile занимала 2-ое место на рынке смартфонов), а конкретный бизнес подход в конкретный момент времени. Сейчас я не вижу ни единой разумной причины для перехода независимых разработчиков на UWP. Вот переход с win32 на некий инструмент (не важно что это конкретное — есть несколько принципиально разных подхода), позволяющий писать приложения сразу и под Windows (желательно всех версий) и под Android, наоборот кажется крайне актуальным.
Смотри Xamarin S>> Еще раз для .Net Native используется С++ компилятор.
_>Вот уже не первый раз встречаю это утверждение на форуме, но при этом без всякой расшифровки. А она очевидно весьма нужна, т.к. всё же там явно подразумевается не создание некого транслятора C# в C++, а нечто другое. А раз нечто другое, то это требует ещё отдельного исследования эффективности.
Здравствуйте, vdimas, Вы писали:
V>·>Ты всё ещё уверен, что очереди двунаправленные? V>На твоём рисунке даже нарисованы две стрелочки навстречу друг другу.
Надо смотреть не количество стрелочек, а направление. Направление стрелочек в одну сторону (на данном рисунке — по часовой стрелке). Т.е. движение однонаправленное. Ты можешь мысленно удалить одну из стрелочек — смысл не поменяется:
Двунаправленная очередь (deque) позволяет добавлять и удалять элеметны с обоих концов, двигаясь в обоих направлениях.
V>>>Собственно, сама схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть, по следующим причинам: V>·>Не понял. Ты выше что описал — кольцевой буфер или две очереди? V>А какая м/у ними разница?
Так я тебя и спрашиваю. Судя по твоим словам есть какая-то разница, ибо "две очереди — классика жанра", а "кольцевой буфер — нубство".
Но вообще разница таки есть. Очередь это АТД, а кольцевой буфер это одна из возможножных имплементаций (array based) этой самой очереди (ещё можно использовать linked list или гибрид linked list+arrays).
V>·>Это значит что читатель не справляется. Тут два варианта — либо блокировать писателей, либо начать дропать пакеты (оба варианта поддерживаются в disruptor). Третьего не дано. V>Третье — это увеличивать очередь для моментов пиковых нагрузок. Желательно задешево. V>И желательно затем, после спадания пика нагрузки, вот эту всю выделенную для такого увеличения память не прогонять через кеши проца, обходясь тем самым минимумом. V>Ты мне можешь показать, кста, участок в коде, где disruptor увеличивает размер своего буфера? V>А то я увидел лишь несколько реализаций блокирующих стратегий, что есть полная ж-па, ес-но.
Дизраптор использует преаллоцированный буфер, во время работы размер не меняется. Типично там десятки-сотни миллионов ячеек, так что проблем с его переполнением нет. То что он хранит все эти элеметы даёт ещё один бенефит в том, что можно восстанавливаться после сбоев (проигрывая потерянные события) и late joiners.
V>>>- для целей переиспользования памяти выгодней брать те её линейки, что есть уже в кеше, т.е. наиболее выгодным устройством пула объектов является структура с характеристикой LIFO, но не в коем случае не FIFO. V>·>Тогда читатели и писатели будут конкурентно бороться за одну линейку кеша. А так получается твой любимый конвеер. V>А если объект улетит из L1 кеша в случае длинного кольцевого буфера, то это будет совсем ж-па. На выбор. V>Если в обеих очередях хотя бы один элемент, то уже не принципиально даже на максимальной загрузке, пакеты даже по 10-гигабитной сетке приходят с конечной скоростью. V>Для обеспечения такого буфферного элемента СНАЧАЛА текущее сообщение пуляют в очередь, а ЗАТЕМ берут из пула элемент "на будущее" и в него уже пишут следующие пришедшие данные. Т.е. не должно быть задержки по приходу сообщения, а между самим сообщениями в сети всё-равно есть задержки.
Ну как в дизрапторе: ringBuffer.next()/ringBuffer.publish()
V>·>Не совсем пофиг с технической т.з, распределение нагрузки разное. Т.к. разные инструменты ведут себя по-разному. Сток торгуется медленно, дай боже 1 ордер в минуту (зато миллионы инструментов), а валюты — сотни/тысячи ордеров в секунду от каждого клиента (но инструментов только несколько сот). V>А валюта разбита на кучу конкретных инструментов, та же пара USD/EUR разбита по датам исполнения, а по каждому конкретному инструменту всё-равно свой ордербук.
Это фьючерсы же или как их там. Бывает и так, но бывает и так как я описал.
V>>>По единичной позиции EUR/USD никогда не генерится более 30-40 тыс матчей в секунду. Для HFT это не нагрузка, а холостой ход. V>>>Если у вас эти цифры составляют 90% трафика, то ты НЕ знаешь, что такое HFT. V>·>Я же написал не матчи, а ордера. V>Все ордера не нужны для поддержания, нужны топовые, а там картинка меняется только при каждом матче, ведь матчатся всегда только и исключительно топовые.
Топовые это для бедных брокеров. Для богатых market data клиентов есть order book depth, там бывает 10 уровней и более (lmax предлагает до 20), а не только топ.
V>А если подключиться к каналу, по которому шлют вообще все ордера, то такой канал на самой бирже идёт в виде крупных батчей с ОЧЕНЬ большими задержками от момента постановки/снятия/изменения самих ордеров. Большими в сравнении с тем самым HFT. Т.е. торговать по событиям в этом фиде заведомо нелепо — этот фид нужен для оценки общего состояния рынка, разве что. Мало ли где там в конце хвоста кто-то что-то присунул ("в конце" означает "дал худшую цену"). Даже если ты мгновенно на это среагируешь (на худшую цену) до неё очередь дойдёт ой как не скоро.
Ага, батчи крупные, но средняя задержка 300мкс.
V>·>Большинство этих ордеров — cancel-replace mass orders, т.е. смена цены или размера ордеров, притом для пачки инструментов сразу (атомарно). И это порождает туеву хучу market data. V>Да какая разница? Биржа всё-равно матчит последовательно и с конечной скоростью. V>И да, повторюсь, на биржах, типа NASDAQ (и вообще на всех OMnet-based), инфа о конкретных ЧУЖИХ ордерах приходит сильно с запозданием от реалтаймовой market data.
Хз.. тут не в курсе. Хотя это может быть объяснением, почему собственно все эти другие биржи существуют, а не только nasdaq.
V>>>·>Где ты нашел двустадийный CAS? V>>>В схеме ring-buffer. V>·>А точнее? V>А сам?
Я не хочу телепатить твои мысли. Пиши явно сам что хочешь сказать.
V>Везде идут последовательности при записи, типа таких: V>sequencer.tryNext()/next() — тут CAS V>затем V>tryPublishEvents()/publishEvents() в теле которых опять V>sequencer.tryNext()/next()
Ну вот видишь, ты опять не разобрался толком. publishEvent(s) это просто удобная try-finally обёртка вокруг ресурса "ячейка(ек) буфера": "seq = next()" -> [translate event] -> "publish(seq)".
V>После обработки события в случае множества потребителей опять будет многостадийный CAS в случае, если потребители закончат обработку не в той последовательности, в которой взяли данные из кольцевого буфера. Посмотри на операции вокруг SequnceGoup и вызывающей её publish со стороны обработчика данных.
В случае 1P-1C схемы, которую мы обсуждаем (?) это не используется.
V>>>Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов. V>·>Ты давал FIX engine, насколько я помню. V>Оно же на чем-то построено? ))
Я-то откуда знаю, исходников ты не давал.
Притом ты давал разные документы с разными тестами, прямого сравнения я не заметил. Сравнение ваших java/c++ имплементаций не особо интересно, не говорит о том, что ваша имплементация лучшая (а ты упомянул развесистые fix-сообщения, что говорит не о самой эффективной наивной реализации).
V>>>Бывает, конечно. Когда стоимость обработки сообщения (задачи) на многие порядки превышает стоимость обслуживания межпоточной очереди, то да, имеет смысл балансить буквально каждую задачу. Но! даже при таком подходе есть разные алгоритмы наиболее дешевого баланса. Самый популярный на сегодня — это алгоритм work stealing. Очевидно, что твой дисраптор никакого алгоритма шедуллинга не выполняет вообще для сценария многие-ко-многим, реализуя заведомо наихудшую (дефолтную) стратегию из всех известных на сегодня. V>·>Это вообще-то scheduling algorithm, а не метод перекачки данных между потоками. V>Данные перекачиваются не для того, чтобы любоваться ими, а чтобы их обрабатывать. V>Там всей разницы, что в случае перекачки "абстрактных задач" мы перекачиваем пару {данные, обработчик}, а в нашем случае обработчик считается известным.
scheduling algorithm интересен в случае если обработка тасков может дать новые таски, которые могут дать ещё новые таски и т.п., эти таски должны в какой-то момент слиться и дать результат — как с этим управиться эффективно — сложная задача.
В обсуждаемом нами случае обработка идёт по одному пути исполнения, с фиксированным графом data flow.
V>·>Дизраптор _может_ использоваться совместно с work stealing, а можно что-то другое заюзать, ту же BlockingQueue. V>Не может, у него алгоритм чтения текущего возможного элемента тупой до посинения — берется минимальный по номеру из последовательности.
Потому что дизраптор в первую очередь разрабатывался для другого сценария — строго определённой последовательной обработки событий, их переупорядочивать запрещено.
V>Кароч, кое-какая оптимизация там есть — это попытка забирать данные батчами. Это удешевляет схему в пересчёте на сообщение. Но эта оптимизация для конкретного этого дисраптора хороша только в случае единичного обработчика, потому что, если обработчиков много, то освободившиеся обработчики не будут иметь доступа к необработанным еще сообщениям другого, притормаживающего обработчика; свободные обработчики тупо опять полезут в буфер, вместо того, чтобы как можно быстрее обработать принятые ранее и уже "перекаченные" данные. Т.е. основной фишки "work stealing" он не может.
Батчи тут нужны для немного другого, не просто для "перформанса". Скажем, разбить mass order (который всё равно надо выполнять только целиком) на блок элементарных операций с каждым конкретным order book.
V>·>Какой исходник? Я хочу услышать хоть какое-нибудь подтверждение твоих слов, что в LMAX больше не используют дизраптор: "Раз они выложили дисраптор в паблик, значит им он больше не нужен". V>Так я уже своё мнение озвучивал. Полезное Ноу-хау никто выкладывать не будет.
Ну т.е. это твоя фантазия. Так я тебе точно говорю — это не так, они используют disruptor и сегодня, практически во всех компонентах системы, хотя заопенсорсили его лет 5 назад.
V>·>Ты всё разжевываешь только телепатически. А пишешь какие-то обрывки и не читаешь что тебе пишут. V>Самое главное, что после получения новой инфы ты, вместо того, чтобы что-то порыть по теме, задалбываешь меня подколками разной степени провокационности (а докажи? а ссылку? сам придумал?) в попытках заставить меня таскать для тебя подробности из Интернета. Фокус стар как мир и выдаёт лентяев сходу. Ну я примерно 10% таких просьб исполняю, сугубо из альтруистических побуждений и корпоративной солидарности... но совесть же тоже иметь надо? ))
А ты правда считаешь, что я должен искать доказательства для твоих мнений?
Да и не особо много новой инфы я от тебя получил, больше я продираюсь через твои шарады с двумя двунаправленными священниками, а в итоге узнаю что-то банальное.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>>Из-за рефлексии нельзя многе оптимизировать компилятору. И по сути NGEN приводит только к снижению затрат на загрузку, но по сути то компилятор то тот же JIT. S>·>Это как? ngen вроде работает до запуска приложения. Как оно может JIT? S>(NGEN) компилирует сборки в машинный код S>• Если для конкретного метода нет образа в машинном коде,
Почему его может не быть? Потому что видимо, не для всех сборок выполнили ngen. Но почему бы в случае того же mobile тупо не выполнить его для всех?
S>• NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Это лишь проблемы зависимостей (с которыми в MS всегда всё плохо), а не производительности.
S>• Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.
Что не имеет смысла в контексте мобильных приложений.
S>·>Я точно не знаю, вроде больше десятка платформ. S>·>Какой "мой хвалёный JIT"? Очередной раз повторяю — в ART сделали AOT. А до этого был Dalvik с JIT; что интересно переход был абсолютно прозрачным, они заменили реализацию платформы, а андроид-программисты вообще это не заметили, те же бинарики просто стали работать на новой платформе, уже с AOT вместо JIT. А не этот пипец от майкрософт, когда они каждый год-два выпускают новую несовместимую технологию (ты уж штук пять назвал). S> А ART может работать без платформы?
Не может, но зачем без?
S> Или все таки это аналог NGEN? Различие читай выше.
Да, аналог ngen но сделанный без косяков как выше.
S>>> Ну программист использует await или Linq, а stackalloc ничем не сложнее S>·>await/linq даёт более красивый, короткий, читабельный код. stackalloc — это просто средство ручной оптимизации. S> А чем это плох stackalloc ? Он ничем не хуже ref returns
stackalloc не даёт никаких новых языковых средств, он просто по сути хинт компилятору о том, как компилировать данный участок кода в машкод.
refs returns позволяет интересную фичу — иметь ссылку на элемент массива и там внутри его прямо и менять. В той же java пришлось бы возвращать индекс эл-та, который теряет взаимосвязь с самим массивом и это чревато ошибками:
String apples[] = {"a", "b", "c"};
String oranges[] = {"n"};
int foundIndx = find(apples);
oranges[foundIndx] = "x"; // вот тут у тебя нужен сам массив для доступа к его эл-ту, можно ошибиться, использовать другой массив.
vs
String apples= {"a", "b", "c"};
String oranges[] = {"n"};
ref String foundElem = find(apples);// гипотетическая фича
foundElem = "x"; // вот тут сразу имеем нужный эл-т, меньше простора для ошибок
Т.е. он не просто позволяет сделать код более быстрее, а даёт новые возможности для написания кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Встречал уже на этом форуме глупые ожидания какого-то прорыва от UWP. Но пока ни один из фанатов данного подхода не смог ответить на один мой простейший вопрос: кто и зачем будет сейчас разрабатывать приложения под UWP? UWP позволяет писать приложения работающие на win10 и win10 mobile (мёртвой платформе). А банальные древние win32 приложения позволяют писать приложения работающие на win10 и на всех старых виндах (которые кстати пока ещё даже популярнее win10). Соответственно совершенно непонятно кто в своём уме будет тратить ресурсы на переобучение под новую технологию, которая в итоге принесёт гораздо меньше пользы чем старая. S> Есть Xamarin который типа поддерживает и UWP.
У тебя что-то очень странное с логикой. ) Я говорю что "UWP никому не нужна", а ты на это отвечаешь, что Xamarin умеет UWP. Ну можно их поздравить с поддержкой этой никчемной платформы. Только какое это имеет отношение к моему тезису? )
_>>Вот уже не первый раз встречаю это утверждение на форуме, но при этом без всякой расшифровки. А она очевидно весьма нужна, т.к. всё же там явно подразумевается не создание некого транслятора C# в C++, а нечто другое. А раз нечто другое, то это требует ещё отдельного исследования эффективности. S> Ну я этим не занимался. Заявления здесь https://msdn.microsoft.com/ru-RU/library/dn584397(v=vs.110).aspx
Из этой ссылки тоже ничего не понятно.
Кстати, добавлю ещё несколько размышлений на эту тему. Компилятор C++ способен творить чудеса в случае компиляции канонического C++ кода. А в случае написания кода в лучших традициях Java/C# никаких принципиальных чудес ждать уже не стоит. Т.е. конечно же всё равно будет намного лучше чем .net jit, но настоящей производительности добиться не удастся. Соответственно даже если предположить, что в данном проекте попытались как-то задействовать готовый оптимизатор от компилятора C++, то всё равно ничего особо интересного от этого ждать не приходится. Т.е. если попытаться сосредоточиться на производительности .net кода, то в первую очередь надо озаботиться неким высокоуровневым преобразованием (типа статического escape-анализа), а только потому говорить о подключение оптимизатора из C++.
Здравствуйте, ·, Вы писали:
V>>·>Ты всё ещё уверен, что очереди двунаправленные? V>>На твоём рисунке даже нарисованы две стрелочки навстречу друг другу. ·>Надо смотреть не количество стрелочек, а направление. Направление стрелочек в одну сторону
Ну так вытяни на фотошопе рисунок так, чтобы кружок стал сильно вытянутым овалом.
·>Т.е. движение однонаправленное.
И не стыдно?
·>Двунаправленная очередь (deque) позволяет добавлять и удалять элеметны с обоих концов, двигаясь в обоих направлениях.
Речь была о двух встречных очередях, от А к Б и от Б к А.
V>>·>Не понял. Ты выше что описал — кольцевой буфер или две очереди? V>>А какая м/у ними разница? ·>Так я тебя и спрашиваю.
Так и отвечал уже — разница в подробностях реализации, а не в семантике.
·>Судя по твоим словам есть какая-то разница, ибо "две очереди — классика жанра", а "кольцевой буфер — нубство".
Ну вот в этих подробностях реализации и есть разница. А решаемая задача одно и та же.
·>Но вообще разница таки есть. Очередь это АТД, а кольцевой буфер это одна из возможножных имплементаций (array based) этой самой очереди (ещё можно использовать linked list или гибрид linked list+arrays).
Кольцевой буфер — это всегда две очереди. Причем, самая ж-па в том, что суммарное кол-во элементов в двух очередях фиксированное.
V>>Ты мне можешь показать, кста, участок в коде, где disruptor увеличивает размер своего буфера? V>>А то я увидел лишь несколько реализаций блокирующих стратегий, что есть полная ж-па, ес-но. ·>Дизраптор использует преаллоцированный буфер, во время работы размер не меняется.
ЧТД.
·>Типично там десятки-сотни миллионов ячеек, так что проблем с его переполнением нет.
Кошмар.
Прикинь, сколько памяти перегоняется даже не через L0 или L1, а уже через L2, при озвученных тобой цифрах.
Я надеюсь, что в реальности длину кольцевого буфера подбирают резко меньше, в единицы тысяч элементов от силы.
·>То что он хранит все эти элеметы даёт ещё один бенефит в том, что можно восстанавливаться после сбоев (проигрывая потерянные события) и late joiners.
Потерянные в каком месте? Если потеряли UDP-пакет, то восстановление без взаимодействие с посылающей стороной невозможно.
V>>А если объект улетит из L1 кеша в случае длинного кольцевого буфера, то это будет совсем ж-па. На выбор. V>>Если в обеих очередях хотя бы один элемент, то уже не принципиально даже на максимальной загрузке, пакеты даже по 10-гигабитной сетке приходят с конечной скоростью. V>>Для обеспечения такого буфферного элемента СНАЧАЛА текущее сообщение пуляют в очередь, а ЗАТЕМ берут из пула элемент "на будущее" и в него уже пишут следующие пришедшие данные. Т.е. не должно быть задержки по приходу сообщения, а между самим сообщениями в сети всё-равно есть задержки. ·>Ну как в дизрапторе: ringBuffer.next()/ringBuffer.publish()
Ну вот как раз твой next будут доставать уже из ОП, а не из кеша. Причем, доставать придётся прямо после прихода каждого нового пакета.
Блин, я тут за L1 рассуждаю, а мне про миллионы ячеек. Разве не жесть? Это же другая реальность у тебя там происходит.
V>>А валюта разбита на кучу конкретных инструментов, та же пара USD/EUR разбита по датам исполнения, а по каждому конкретному инструменту всё-равно свой ордербук. ·>Это фьючерсы же или как их там. Бывает и так, но бывает и так как я описал.
Так основной трафик именно по ним, если речь о валютах.
·>Топовые это для бедных брокеров. Для богатых market data клиентов есть order book depth, там бывает 10 уровней и более (lmax предлагает до 20), а не только топ.
Это и есть топовые. Да, обычно на биржах есть подписка топ-1, топ-5, топ-10 и т.д.
Обновление топа идёт инкрементальное, никто повторы не шлёт, шлют только изменения, а они практически всегда (в 99.9% случаев) идут одновременно с матчем.
И да, подписавшись на full order depth (который шлется батчами не быстро) + на топ-1, в 99.9% случаев можно иметь самую актуальную market data.
V>>А если подключиться к каналу, по которому шлют вообще все ордера, то такой канал на самой бирже идёт в виде крупных батчей с ОЧЕНЬ большими задержками от момента постановки/снятия/изменения самих ордеров. Большими в сравнении с тем самым HFT. Т.е. торговать по событиям в этом фиде заведомо нелепо — этот фид нужен для оценки общего состояния рынка, разве что. Мало ли где там в конце хвоста кто-то что-то присунул ("в конце" означает "дал худшую цену"). Даже если ты мгновенно на это среагируешь (на худшую цену) до неё очередь дойдёт ой как не скоро. ·>Ага, батчи крупные, но средняя задержка 300мкс.
Это уже поздно рыпаться, все сливки снимут по каналу, работающему на 10-микросекундных задержках.
V>>Да какая разница? Биржа всё-равно матчит последовательно и с конечной скоростью. V>>И да, повторюсь, на биржах, типа NASDAQ (и вообще на всех OMnet-based), инфа о конкретных ЧУЖИХ ордерах приходит сильно с запозданием от реалтаймовой market data. ·>Хз.. тут не в курсе. Хотя это может быть объяснением, почему собственно все эти другие биржи существуют, а не только nasdaq.
Потому что географически раскиданы по крупным финансовым центрам.
И на других биржах не лучше, не обольщайся. ))
V>>Везде идут последовательности при записи, типа таких: V>>sequencer.tryNext()/next() — тут CAS V>>затем V>>tryPublishEvents()/publishEvents() в теле которых опять V>>sequencer.tryNext()/next() ·>Ну вот видишь, ты опять не разобрался толком. publishEvent(s) это просто удобная try-finally обёртка вокруг ресурса "ячейка(ек) буфера": "seq = next()" -> [translate event] -> "publish(seq)".
Я-то прекрасно разобрался, вижу два CAS.
А твой коммент не в тему.
Взгляни на свой publish.
V>>После обработки события в случае множества потребителей опять будет многостадийный CAS в случае, если потребители закончат обработку не в той последовательности, в которой взяли данные из кольцевого буфера. Посмотри на операции вокруг SequnceGoup и вызывающей её publish со стороны обработчика данных. ·>В случае 1P-1C схемы, которую мы обсуждаем (?) это не используется.
В большинстве бирж идёт схема ооP:1C, потому что каналы восстановления для потерянных UDP-сообщений — отдельные. Т.е. из нескольких фидов, относящихся к одному инструменту, надо сливать в один обработчик.
V>>>>Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов. V>>·>Ты давал FIX engine, насколько я помню. V>>Оно же на чем-то построено? )) ·>Я-то откуда знаю, исходников ты не давал.
ЧТД.
Мне кажется я и так слишком болтаю тут, а тебе прямо исходники нужны. ))
·>Притом ты давал разные документы с разными тестами, прямого сравнения я не заметил.
Я давал два идентичных по структуре док-та. Да, в двух окнах надо открыть идентичные графики или таблицы из этих док-ов.
·>Сравнение ваших java/c++ имплементаций не особо интересно, не говорит о том, что ваша имплементация лучшая (а ты упомянул развесистые fix-сообщения, что говорит не о самой эффективной наивной реализации).
Для клиентов зато эффективно. Они же все-равно читают строки, а не последовательности байт. Т.е. операция преобразования всё-равно будет и тут не важно — на вашей стороне (в вашей библиотеке), или на стороне клиентской программы.
V>>·>Это вообще-то scheduling algorithm, а не метод перекачки данных между потоками. V>>Данные перекачиваются не для того, чтобы любоваться ими, а чтобы их обрабатывать. V>>Там всей разницы, что в случае перекачки "абстрактных задач" мы перекачиваем пару {данные, обработчик}, а в нашем случае обработчик считается известным. ·>scheduling algorithm интересен в случае если обработка тасков может дать новые таски, которые могут дать ещё новые таски и т.п., эти таски должны в какой-то момент слиться и дать результат — как с этим управиться эффективно — сложная задача. ·>В обсуждаемом нами случае обработка идёт по одному пути исполнения, с фиксированным графом data flow.
Я уже делал то замечание, что в случае неконтроллируемого многие-ко-многим будет хаотичная картинка обработки данных.
В этом хаосе постоянно возникают out-of-order обрабатываемых данных, что тоже требует лишних телодвижений по упорядочиванию (в инкрементальном фиде обязательно, а трафик HFT почти всегда гонится инкрементально).
Причем, такие телодвижения для упорядочивания происходят из конкурирующих потоков, что есть полная ж-па сама по себе.
V>>·>Дизраптор _может_ использоваться совместно с work stealing, а можно что-то другое заюзать, ту же BlockingQueue. V>>Не может, у него алгоритм чтения текущего возможного элемента тупой до посинения — берется минимальный по номеру из последовательности. ·>Потому что дизраптор в первую очередь разрабатывался для другого сценария — строго определённой последовательной обработки событий, их переупорядочивать запрещено.
Для случая многих продюсеров никакой строгой последовательности не будет (Multiproducer или как там его зовут в дисрапторе), каждая операция next() в конкурентном цикле lock-free пробует отжать себе очередную ячейку для записи. В случае многих консьюмеров — аналогично на стороне чтения. Т.е. на обоих концах происходит нарушение исходной последовательности событий.
·>Батчи тут нужны для немного другого, не просто для "перформанса".
Разработчики преподносят фичу батчей именно как повышающую эффективность и с ними абсолютно согласен.
V>>Так я уже своё мнение озвучивал. Полезное Ноу-хау никто выкладывать не будет. ·>Ну т.е. это твоя фантазия. Так я тебе точно говорю — это не так, они используют disruptor и сегодня, практически во всех компонентах системы, хотя заопенсорсили его лет 5 назад.
Где-то в некритичном месте может и используют.
Дисраптор хорош своим удобным джавовским АПИ.
Это как взять те же FIX-сообщения. Можно хранить их как обычный джавовский граф, т.е. удобно для разработки и поддержки, а можно через хардкорное байтодрочерство. Боюсь, в критических местах системы у них будет такое же корявое на вид байтодрочерство, которое практически бесполезно выкладывать в опенсорс без всего окружающего такие места кода.
V>>Самое главное, что после получения новой инфы ты, вместо того, чтобы что-то порыть по теме, задалбываешь меня подколками разной степени провокационности (а докажи? а ссылку? сам придумал?) в попытках заставить меня таскать для тебя подробности из Интернета. Фокус стар как мир и выдаёт лентяев сходу. Ну я примерно 10% таких просьб исполняю, сугубо из альтруистических побуждений и корпоративной солидарности... но совесть же тоже иметь надо? )) ·>А ты правда считаешь, что я должен искать доказательства для твоих мнений?
Я ничего не доказываю.
Я просто делюсь инфой.
·>Да и не особо много новой инфы я от тебя получил, больше я продираюсь через твои шарады с двумя двунаправленными священниками, а в итоге узнаю что-то банальное.
Да, ладно, "банальное".
Ты как минимум должен был уже понять, что кольцевой буфер — это не фича, а подробности реализации, а фишка там в общей схеме/задаче. И под эту задачу (круговорота преаллоцированных объектов) есть более одного решения.
S>Да, и индекс TIOBE также показывает заметный рост Java. Всё-таки восьмая версия с большим количеством нововведений многим пришлась по вкусу. Даже былым скептикам.
А в "Java" входят JavaScript/NodeJS?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Встречал уже на этом форуме глупые ожидания какого-то прорыва от UWP. Но пока ни один из фанатов данного подхода не смог ответить на один мой простейший вопрос: кто и зачем будет сейчас разрабатывать приложения под UWP? UWP позволяет писать приложения работающие на win10 и win10 mobile (мёртвой платформе). А банальные древние win32 приложения позволяют писать приложения работающие на win10 и на всех старых виндах (которые кстати пока ещё даже популярнее win10). Соответственно совершенно непонятно кто в своём уме будет тратить ресурсы на переобучение под новую технологию, которая в итоге принесёт гораздо меньше пользы чем старая. S>> Есть Xamarin который типа поддерживает и UWP.
_>У тебя что-то очень странное с логикой. ) Я говорю что "UWP никому не нужна", а ты на это отвечаешь, что Xamarin умеет UWP. Ну можно их поздравить с поддержкой этой никчемной платформы. Только какое это имеет отношение к моему тезису? )
Мертвая не мертвая, но живет и развивается https://habrahabr.ru/post/306964/
Опять же под NetStandard 2 станет значительно проще создавать приложения для мобильных устройств.
Никому — это не верно. Её применяют, правда значительно меньше чем для андроид или АйФона. Но программировать на C# с XAML взрослым языком значительно проще чем на огрызке Java или Objective-C.
Хотя сейчас хвалят Свифт, но он не кроссплатформенный.
Плюс XBOX сы продаются как пирожки и для него можно писать на UWP https://msdn.microsoft.com/ru-ru/windows/uwp/xbox-apps/index
MS хочет сделать универсальную платформу
Все течет, все меняется.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>>>На твоём рисунке даже нарисованы две стрелочки навстречу друг другу. V>·>Надо смотреть не количество стрелочек, а направление. Направление стрелочек в одну сторону V>Ну так вытяни на фотошопе рисунок так, чтобы кружок стал сильно вытянутым овалом.
Какая разница какой овальности у тебя кружок? Направление-то одно — пл часовой стрелке.
V>·>Т.е. движение однонаправленное. V>И не стыдно?
Похоже, что нет — лжёшь и не краснеешь.
V>·>Двунаправленная очередь (deque) позволяет добавлять и удалять элеметны с обоих концов, двигаясь в обоих направлениях. V>Речь была о двух встречных очередях, от А к Б и от Б к А.
Я не знаю о чём была речь в телепатиеграмме, я её не получил, но тут в форуме ты писал именно о двунаправленной очереди, твоя цитата: "является главным тормозом двунаправленной очереди".
V>>>А какая м/у ними разница? V>·>Так я тебя и спрашиваю. V>Так и отвечал уже — разница в подробностях реализации, а не в семантике.
У очереди нет подробностей реализации, это АТД (ты кстати только об одной реализации рассуждал — кольцевой буфер). Так какая другая таинственная реализация правильнее?
V>·>Судя по твоим словам есть какая-то разница, ибо "две очереди — классика жанра", а "кольцевой буфер — нубство". V>Ну вот в этих подробностях реализации и есть разница. А решаемая задача одно и та же.
Так расскажи наконец-то об этих подробностях.
V>·>Но вообще разница таки есть. Очередь это АТД, а кольцевой буфер это одна из возможножных имплементаций (array based) этой самой очереди (ещё можно использовать linked list или гибрид linked list+arrays). V>Кольцевой буфер — это всегда две очереди. Причем, самая ж-па в том, что суммарное кол-во элементов в двух очередях фиксированное.
Это твоя странная интерпретация понятий, никто больше не описывает циклический буфер как две очереди. Скажем, одна из стандартных JDK имплементаций очереди как раз использует тот же циклический буфер: ArrayBlockingQueue.
V>·>Типично там десятки-сотни миллионов ячеек, так что проблем с его переполнением нет. V>Кошмар. V>Прикинь, сколько памяти перегоняется даже не через L0 или L1, а уже через L2, при озвученных тобой цифрах.
L0??
V>Я надеюсь, что в реальности длину кольцевого буфера подбирают резко меньше, в единицы тысяч элементов от силы.
Зависит от задач. Размер буфера это просто параметр конструктора.
V>·>То что он хранит все эти элеметы даёт ещё один бенефит в том, что можно восстанавливаться после сбоев (проигрывая потерянные события) и late joiners. V>Потерянные в каком месте? Если потеряли UDP-пакет, то восстановление без взаимодействие с посылающей стороной невозможно.
Если получатель видит gap в sequence number, он посылает nack и потерянные сообщения посылаются повторно.
Причины потери не принципиально важны.
V>>>Для обеспечения такого буфферного элемента СНАЧАЛА текущее сообщение пуляют в очередь, а ЗАТЕМ берут из пула элемент "на будущее" и в него уже пишут следующие пришедшие данные. Т.е. не должно быть задержки по приходу сообщения, а между самим сообщениями в сети всё-равно есть задержки. V>·>Ну как в дизрапторе: ringBuffer.next()/ringBuffer.publish() V>Ну вот как раз твой next будут доставать уже из ОП, а не из кеша. Причем, доставать придётся прямо после прихода каждого нового пакета. V>Блин, я тут за L1 рассуждаю, а мне про миллионы ячеек. Разве не жесть? Это же другая реальность у тебя там происходит.
Зависит от задач. Можно и уменьшит размер буфера, зато проблемы с recovery могут начаться.
V>>>А валюта разбита на кучу конкретных инструментов, та же пара USD/EUR разбита по датам исполнения, а по каждому конкретному инструменту всё-равно свой ордербук. V>·>Это фьючерсы же или как их там. Бывает и так, но бывает и так как я описал. V>Так основной трафик именно по ним, если речь о валютах.
Всё равно трафик сильно смещён, нет равномерного распределения по ордербукам.
И ещё раз повторяю — т.к. у нас mass order — мы обрабатываем пачку ордербуков — притом обязаны это делать атомарно и последотвательно.
V>·>Топовые это для бедных брокеров. Для богатых market data клиентов есть order book depth, там бывает 10 уровней и более (lmax предлагает до 20), а не только топ. V>Это и есть топовые. Да, обычно на биржах есть подписка топ-1, топ-5, топ-10 и т.д. V>Обновление топа идёт инкрементальное, никто повторы не шлёт, шлют только изменения, а они практически всегда (в 99.9% случаев) идут одновременно с матчем.
Неверно, обновление топа идёт с каждым cancel-replace ордером. Т.е. большинство ордеров не матчатся, но цена/кол-во в ордербуке меняется постоянно.
V>·>Ага, батчи крупные, но средняя задержка 300мкс. V>Это уже поздно рыпаться, все сливки снимут по каналу, работающему на 10-микросекундных задержках.
Ты опять какие-то сравнения несравнимых таймингов делаешь.
V>>>затем V>>>tryPublishEvents()/publishEvents() в теле которых опять V>>>sequencer.tryNext()/next() V>·>Ну вот видишь, ты опять не разобрался толком. publishEvent(s) это просто удобная try-finally обёртка вокруг ресурса "ячейка(ек) буфера": "seq = next()" -> [translate event] -> "publish(seq)". V>Я-то прекрасно разобрался, вижу два CAS.
Ну так покажи. Почему ты опять заставляешь доказывать твои фантазии?
V>А твой коммент не в тему.
Ты ошибся написав, что после next() вызывается publishEvents(). Это не так.
V>Взгляни на свой publish.
Я взглянул, ничего не такого не увидел. Если есть что-то показать конкретное — показывай.
Ну подумай сам: next уже с помощью Compare-And-Set нам выдал личный для треда номер, мы его используем экслюзивно, никому больше он достаться не может. Зачем при publish делать ещё какую-то Compare? Что с чем сравнивать-то?
V>>>После обработки события в случае множества потребителей опять будет многостадийный CAS в случае, если потребители закончат обработку не в той последовательности, в которой взяли данные из кольцевого буфера. Посмотри на операции вокруг SequnceGoup и вызывающей её publish со стороны обработчика данных. V>·>В случае 1P-1C схемы, которую мы обсуждаем (?) это не используется. V>В большинстве бирж идёт схема ооP:1C, потому что каналы восстановления для потерянных UDP-сообщений — отдельные. Т.е. из нескольких фидов, относящихся к одному инструменту, надо сливать в один обработчик.
Слив идёт на уровне UDP-multicast во внутренней сети биржи (за всех не скажу, но именно так в бирже которую я видел изнутри).
V>>>>>Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов. V>>>·>Ты давал FIX engine, насколько я помню. V>>>Оно же на чем-то построено? )) V>·>Я-то откуда знаю, исходников ты не давал. V>ЧТД. V>Мне кажется я и так слишком болтаю тут, а тебе прямо исходники нужны. ))
Хоть что-нибудь кроме телепатиергамм.
V>·>Притом ты давал разные документы с разными тестами, прямого сравнения я не заметил. V>Я давал два идентичных по структуре док-та. Да, в двух окнах надо открыть идентичные графики или таблицы из этих док-ов.
То что документы написаны в одном стиле не означает, что тестирование проходило в одинаковых условиях. Значительная величина различия даже нативных имплементаций вызывает серьёзные сомнения.
V>·>Сравнение ваших java/c++ имплементаций не особо интересно, не говорит о том, что ваша имплементация лучшая (а ты упомянул развесистые fix-сообщения, что говорит не о самой эффективной наивной реализации). V>Для клиентов зато эффективно. Они же все-равно читают строки, а не последовательности байт. Т.е. операция преобразования всё-равно будет и тут не важно — на вашей стороне (в вашей библиотеке), или на стороне клиентской программы.
Читают строки человеки, а не hft-роботы. А там где человеки — там плевать на hft: всё что меньше 1 секунды — не задержка.
V>·>scheduling algorithm интересен в случае если обработка тасков может дать новые таски, которые могут дать ещё новые таски и т.п., эти таски должны в какой-то момент слиться и дать результат — как с этим управиться эффективно — сложная задача. V>·>В обсуждаемом нами случае обработка идёт по одному пути исполнения, с фиксированным графом data flow. V>Я уже делал то замечание, что в случае неконтроллируемого многие-ко-многим будет хаотичная картинка обработки данных. V>В этом хаосе постоянно возникают out-of-order обрабатываемых данных, что тоже требует лишних телодвижений по упорядочиванию (в инкрементальном фиде обязательно, а трафик HFT почти всегда гонится инкрементально). V>Причем, такие телодвижения для упорядочивания происходят из конкурирующих потоков, что есть полная ж-па сама по себе.
Многие-ко-многим это на высоком уровне. А внутри там вначале всё упорядочивается.
V>>>·>Дизраптор _может_ использоваться совместно с work stealing, а можно что-то другое заюзать, ту же BlockingQueue. V>>>Не может, у него алгоритм чтения текущего возможного элемента тупой до посинения — берется минимальный по номеру из последовательности. V>·>Потому что дизраптор в первую очередь разрабатывался для другого сценария — строго определённой последовательной обработки событий, их переупорядочивать запрещено. V>Для случая многих продюсеров никакой строгой последовательности не будет (Multiproducer или как там его зовут в дисрапторе), каждая операция next() в конкурентном цикле lock-free пробует отжать себе очередную ячейку для записи. В случае многих консьюмеров — аналогично на стороне чтения. Т.е. на обоих концах происходит нарушение исходной последовательности событий.
Поэтому и ставят sequencer посередине, который каждому событию поставит уникальный инкрементальный номер.
V>·>Батчи тут нужны для немного другого, не просто для "перформанса". V>Разработчики преподносят фичу батчей именно как повышающую эффективность и с ними абсолютно согласен.
Понятно, но это даётся не бесплатно, а ценой latency.
V>>>Так я уже своё мнение озвучивал. Полезное Ноу-хау никто выкладывать не будет. V>·>Ну т.е. это твоя фантазия. Так я тебе точно говорю — это не так, они используют disruptor и сегодня, практически во всех компонентах системы, хотя заопенсорсили его лет 5 назад. V>Где-то в некритичном месте может и используют.
Ну опять же домыслы? Могу уверенно сказать что используют везде, сам видел.
V>Дисраптор хорош своим удобным джавовским АПИ. V>Это как взять те же FIX-сообщения. Можно хранить их как обычный джавовский граф, т.е. удобно для разработки и поддержки, а можно через хардкорное байтодрочерство. Боюсь, в критических местах системы у них будет такое же корявое на вид байтодрочерство, которое практически бесполезно выкладывать в опенсорс без всего окружающего такие места кода.
Как ты хранишь данные и какое API ты предоставляешь — несколько ортогональные понятия.
V>>>Самое главное, что после получения новой инфы ты, вместо того, чтобы что-то порыть по теме, задалбываешь меня подколками разной степени провокационности (а докажи? а ссылку? сам придумал?) в попытках заставить меня таскать для тебя подробности из Интернета. Фокус стар как мир и выдаёт лентяев сходу. Ну я примерно 10% таких просьб исполняю, сугубо из альтруистических побуждений и корпоративной солидарности... но совесть же тоже иметь надо? )) V>·>А ты правда считаешь, что я должен искать доказательства для твоих мнений? V>Я ничего не доказываю. V>Я просто делюсь инфой.
"Где-то в некритичном месте может и используют. " — это не инфа, это фантазии. И это не единственное.
V>·>Да и не особо много новой инфы я от тебя получил, больше я продираюсь через твои шарады с двумя двунаправленными священниками, а в итоге узнаю что-то банальное. V>Да, ладно, "банальное". V>Ты как минимум должен был уже понять, что кольцевой буфер — это не фича, а подробности реализации, а фишка там в общей схеме/задаче. И под эту задачу (круговорота преаллоцированных объектов)
Это я тебе рассказал, спасибо что хоть материал урока усвоил.
V>есть более одного решения.
Но ты так и не рассказал ни об одном из них.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>На твоём рисунке даже нарисованы две стрелочки навстречу друг другу. V>>·>Надо смотреть не количество стрелочек, а направление. Направление стрелочек в одну сторону V>>Ну так вытяни на фотошопе рисунок так, чтобы кружок стал сильно вытянутым овалом. ·>Какая разница какой овальности у тебя кружок? Направление-то одно — пл часовой стрелке.
Здравствуйте, vdimas, Вы писали:
V>>>Ну так вытяни на фотошопе рисунок так, чтобы кружок стал сильно вытянутым овалом. V>·>Какая разница какой овальности у тебя кружок? Направление-то одно — пл часовой стрелке. V>Кошмар )) V>Два плюс два сложить не в состоянии...
Я не собираюсь ничего складывать. Если есть что сказать по делу — говори, доказывать твои заблуждения и разгадывать шарады со священниками мне неохота.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>У тебя что-то очень странное с логикой. ) Я говорю что "UWP никому не нужна", а ты на это отвечаешь, что Xamarin умеет UWP. Ну можно их поздравить с поддержкой этой никчемной платформы. Только какое это имеет отношение к моему тезису? ) S>Мертвая не мертвая, но живет и развивается https://habrahabr.ru/post/306964/ S>Опять же под NetStandard 2 станет значительно проще создавать приложения для мобильных устройств.
И какое отношение этот твой текст имеет к моему тезису о ненужности UWP? )
S> Никому — это не верно. Её применяют, правда значительно меньше чем для андроид или АйФона. Но программировать на C# с XAML взрослым языком значительно проще чем на огрызке Java или Objective-C.
Никакой бизнес не выбирает свои целевые платформы из соображений "проще программировать". Интересует исключительно объём потенциальной аудитории. У Windows (десктоп), Android (мобильные устройства в первую очередь), iOS (мобильные устройства), OSX (десктоп), Linux (сервера, встраиваемые решения) аудитория есть. У windows mobile аудитории нет. Так что абсолютно не важно как там под неё программируется.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>У тебя что-то очень странное с логикой. ) Я говорю что "UWP никому не нужна", а ты на это отвечаешь, что Xamarin умеет UWP. Ну можно их поздравить с поддержкой этой никчемной платформы. Только какое это имеет отношение к моему тезису? ) S>>Мертвая не мертвая, но живет и развивается https://habrahabr.ru/post/306964/ S>>Опять же под NetStandard 2 станет значительно проще создавать приложения для мобильных устройств.
_>И какое отношение этот твой текст имеет к моему тезису о ненужности UWP? )
S>> Никому — это не верно. Её применяют, правда значительно меньше чем для андроид или АйФона. Но программировать на C# с XAML взрослым языком значительно проще чем на огрызке Java или Objective-C.
_>Никакой бизнес не выбирает свои целевые платформы из соображений "проще программировать". Интересует исключительно объём потенциальной аудитории. У Windows (десктоп), Android (мобильные устройства в первую очередь), iOS (мобильные устройства), OSX (десктоп), Linux (сервера, встраиваемые решения) аудитория есть. У windows mobile аудитории нет. Так что абсолютно не важно как там под неё программируется.
Да не уж то. И у XBOX её нет.
Все зависит от количества разработчиков и конкуренции. Что толку от этих ос если там конкуренция сумасшедшая.
У жены Люмия 640 с последними обновлениями до этого были андроиды и айфон. У сына Айфон. Так по качеству Люмия мало уступает Айфонам, но при той же цене значительно превосходит андроиды.
Приложений какие ей нужны все есть, а объем рынка достаточный https://akket.com/windows/34609-pochti-polmilliarda-elektronnyh-ustrojstv-uzhe-rabotayut-pod-upravleniem-windows-10.html
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Никакой бизнес не выбирает свои целевые платформы из соображений "проще программировать". Интересует исключительно объём потенциальной аудитории. У Windows (десктоп), Android (мобильные устройства в первую очередь), iOS (мобильные устройства), OSX (десктоп), Linux (сервера, встраиваемые решения) аудитория есть. У windows mobile аудитории нет. Так что абсолютно не важно как там под неё программируется. S> Да не уж то. И у XBOX её нет. S> Все зависит от количества разработчиков и конкуренции. Что толку от этих ос если там конкуренция сумасшедшая. S>У жены Люмия 640 с последними обновлениями до этого были андроиды и айфон. У сына Айфон. Так по качеству Люмия мало уступает Айфонам, но при той же цене значительно превосходит андроиды.
Вот меня так веселят фанаты винды. Как говорить о низкой значимости Линуха в мире десктопов в связи с их низким процентом популярности, так нет проблем. А как переходим к аналогичному рассуждению относительно WinMobile, так сразу начинаем рассуждать о том что оно там вроде как не плохо шевелится. Так Линух на декстопе на самом деле тоже очень не плохо шевелится, только вот кого это волнует? )
S>Приложений какие ей нужны все есть, а объем рынка достаточный S>https://akket.com/windows/34609-pochti-polmilliarda-elektronnyh-ustrojstv-uzhe-rabotayut-pod-upravleniem-windows-10.html
Популярность win10 не имеет к обсуждаемой теме никакого отношения, потому что на ней и так отлично работают древние win32 приложения — нет никакого смысла переходит с них на UWP.
Одними из ключевых составляющих следующего обновления Creators Update для операционной системы Windows 10 станет поддержка 3D и смешанной реальности. Так, компания Microsoft представила обновлённую версию графического редактора Paint с приставкой 3D. С его помощью пользователи смогут создавать различный 3D-контент. Кроме этого, смартфоны на Windows 10 Mobile можно будет использовать для создания 3D-моделей объектов. Работать с таким контентом удобнее в виртуальной или дополненной реальности, поэтому партнёры Microsoft выпустят недорогие VR-шлемы.
Среди партнёров Microsoft, которые будут производить шлемы виртуальной и дополненной реальности, указаны HP, Dell, ASUS, Acer и Lenovo. К сожалению, про технические характеристики и сроки появления этих девайсов Microsoft ничего не рассказала. Известно лишь то, что шлемы будут стоить от $299.
Уже в течение продолжительного времени вокруг обновления Windows 10 Mobile Redstone 2 ходят слухи о том, что обновленная версия ОС будет сфокусирована именно на мобильных устройствах. На второй день конференции Microsoft Ignite 2016 в сессии под названием «Что нового ждет Windows 10 Mobile для телефонов и маленьких планшетов» создатели сделали ряд анонсов относительно новшеств Redstone 2. Также будет функция Proximity Connect, которая даст возможность вам устанавливать беспроводное соединение с док-станцией, не доставая смартфон из кармана.
Для Windows 10 Mobile основной killer-фичей является Continuum — возможность использовать совместимый смартфон как ПК, подключив его к наружному монитору. Док-станция, вероятно, будет обнаруживать его через Bluetooth.
Другой главной особенностью будет то, что вы сможете самостоятельно настроить меню запуск.
Работа с Continuum больше будет сходна на ПК-опыт. Размеры окон приложений можно будет менять и прикреплять их друг к другу.
Более того, опыт применения режима Continuum максимально приблизится к опыту применения Windows 10 на ПК (Не хватает только Win32 приложений): сейчас, вы сможете изменять размер окон приложений (Раньше они запускались только на весь экран) и делить дисплей на 2 и более части, для размещения на экране сразу нескольких приложений. На текущий момент интерфейс больше похож на планшетный, с только полноэкранными приложениями. Какие изменения коснутся всей ОС рассказано, как не прискорбно не было, однако, все-таки возможно, для этого будет сделана отдельная конференция осенью, на которой, также, должен быть показан мифический Surface AIO и некоторые устройства от партнеров.
Буквально только что в рамках специального мероприятия в Нью-Йорке компания Microsoft анонсировала обновление Creators Update для ОС Windows 10. Финальная версия обновления выйдет в начале 2017 года, тогда как участникам программы тестирования Windows Insider оно станет доступно намного раньше – релиз соответствующей сборки состоится уже на этой неделе.
В ходе презентации Microsoft раскрыла лишь некоторые из новых функций и возможностей из обновления Creators Update. Говоря точнее, руководитель подразделения Microsoft по разработке Windows Терри Майерсон перечислил три ключевых элемента, на которых будет сосредоточено грядущее обновление системы, недавно перешагнувшей отметку в 400 млн устройств. Это 3D-контент и технологии смешанной реальности, поддержка игр в разрешении 4K, и прямые игровые трансляции. Также в ходе анонса обновления упоминались новые, более быстрые способы обмена информацией и связи с друзьями и семьей.
Как уже отмечалось выше, одной из ключевых аспектов обновления Creators Update станет работа с 3D-контентом. Программный гигант рассчитывает, что Windows 10 Creators Update сделает 3D доступным всем и каждому.
В рамках одной из демонстраций Меган Сондерс, курирующая разработку гарнитуры виртуальной реальности HoloLens и другие передовые разработки, показала работу специального мобильного приложения для создания 3D-моделей различных объектов, используя смартфон HP Elite x3 под управлением Windows 10 Mobile. Меган сделала несколько снимков песчаного замка с разных ракурсов, используя камеру смартфона, а затем приложение использовало их для создания 3D-модели этого замка.
Важной частью обновления станет существенно обновленное и улучшенное приложение Paint, которое позволит создавать 3D-объекты и обрабатывать трехмерные изображения. Напомним, что видео с презентацией новой версии Paint для Windows 10 утекло в сеть в начале этого месяца. Функциональность, связанная с 3D и виртуальной реальностью, появится не только в Paint, но и других приложениях, в том числе и в браузере Microsoft Edge. Демонстрация с песчаным замком завершилась создание его голограммы.
Следующая ключевая особенность обновления – игровые трансляции в один клик. Начать трансляцию можно будет прямо из рабочего окружения Windows 10. Достаточно будет одной простой комбинации клавиш – «Win+G», всю тяжелую работу в данном случае выполняет сервис Xbox Live. Используя возможности Xbox Live Arena, игроки смогут создавать собственные турниры. Увы, о поддержке разрешения 4K играх, помимо того, что она будет, больше ничего сказано не было. Вероятно, связано это с тем, что функциональность пока находится на самых ранних стадиях разработки.
screen-shot-2016-10-26-at-10-49-52-amВ Windows 10 Creators Update будет существенно ускорен обмен документами и файлами с одними и теми же контактами посредством функции Share Charm. Кроме того, Windows-приложения (Skype, Mail, Xbox Live и т.д.) станут более понятливыми.
Остается добавить, что обновление выйдет не только для ПК и ноутбуков, но и для смартфонов.
То есть фич предостаточно. А для продвижения нужна фича типа покемонов, а уж программировать под UWP достаточно легко.
и солнце б утром не вставало, когда бы не было меня
_>Популярность win10 не имеет к обсуждаемой теме никакого отношения, потому что на ней и так отлично работают древние win32 приложения — нет никакого смысла переходит с них на UWP.
Инструменты для работы с унаследованными проектами
За долгую историю операционной системы Windows для нее было создано колоссальное количество самых разных приложений. С выходом Windows 8 и WinRT (а позже Windows 10 и UWP) старые классические приложения остались в прошлом, поскольку только в настольных Win 8 и Win 10 поддерживаются классические Win32-, COM-, .NET-приложения. От этого в Microsoft стало грустно. Но ребята смекнули, что могут разработать конвертер, который будет преобразовывать старые приложения для новой продвинутой UWP-подсистемы. Из этого родился Desktop App Converter.
Скачать его можно отсюда. Текущее состояние продукта — предварительная версия. Уже сейчас он позволяет преобразовывать классические приложения, написанные для Win32 и .NET 4.6.1, в приложения для платформы UWP.
Преобразованное приложение сохраняет функциональность предка плюс обретает возможности UWP-приложений: удобную установку, обновление, удаление. Также оно получает другие средства современных Windows-программ: push-уведомления, живые плитки, способность выполняться в качестве фоновой задачи, широкий диапазон контрактов. Одна из самых привлекательных возможностей — это продажа унаследованных приложений в Windows Store.
Desktop App Converter представляет собой приложение с интерфейсом командной строки. На входе оно получает: путь к дистрибутиву приложения, которое планируется преобразовать, путь к файлу-результату и путь к файлу — образу системы. Последний будет использован для чистой установки конвертируемой программы.
На выходе Desktop App Converter выдает каталог со всем установленным при инсталляции стаффом и два файла: манифест и файл регистрации приложения. После этого с помощью другой тулзы командной строки из образованного контента создается установочный файл UWP-приложения AppX. Затем это приложение можно установить в операционку и пользоваться им, как любым другим универсальным приложением, в том числе на Windows 10 Mobile.
Мало того
После этого парни из Microsoft подумали: для iOS есть множество крутых мобильных приложений, было бы неплохо дать разработчикам возможность запилить их под нашу мобильную ось. Так появился проект с открытым исходным кодом Windows Bridge for iOS.
Преобразование Xcode-проекта выполняется в два шага. Сначала надо добавить подсветку синтаксиса языка Objective-C в Visual Studio: установить расширение objc-syntax-highlighting.vsix из папки winobjc\bin. Затем с помощью утилиты командной строки vsimporter.exe надо преобразовать проект на Xcode в проект на VS. После этого полученный sln-файл можно открыть в студии, где синтаксис Objective-C будет подсвечен. Можешь построить и запустить приложение, оно будет выполняться так же, как все другие Windows-программы.
Разрази меня гром, как это удивительно — видеть в Visual Studio корректно подсвеченный код Objective-C!
Для компиляции кода Obj-C используется свободный компилятор Clang. Поскольку на выходе получается стандартное UWP-приложение, его можно запустить на мобильном устройстве в среде Windows 10 Mobile. В одной программе может быть код на C++ и на Obj-C.
Вывод OpenGL на эмуляторе смартфона Windows 10 Mobile
Если у тебя есть проект для прошлой версии Windows Phone, то есть 8.1 (или 8.0), то, когда ты его откроешь в VS 2015, студия автоматически обновит проект, чтобы он соответствовал требованиям универсального приложения Windows (UWP). Будет преобразована не только разметка пользовательского интерфейса на XAML, но и вместе с ней программная логика на JS/C++/C#/VB. Если в коде были вызовы подсистемы WinRT, тогда они будут преобразованы в вызовы UWP.
Есть еще распространенный тип приложений — игры. iOS и Android визуализируют посредством низкоуровневого интерфейса OpenGL. С другой стороны, на Windows 10 Mobile для вывода изображения в играх используется DirectX 11. Получается несовместимость. Но есть решение — открытый проект ANGLE. ANGLE (Almost Native Graphics Layer Engine) — движок почти нативного графического слоя — позволяет пользователям Windows бесшовно запускать OpenGL ES приложения на аппаратуре, работающей с DirectX 11. Это достигается путем преобразования вызовов с OpenGL ES API на DirectX 11 API. ANGLE полностью поддерживает следующие три типа приложений:
поддерживает следующие три типа приложений:
◾универсальные приложения для Windows 10 (Universal Windows apps);
◾приложения для Windows 8.1 и Windows Phone 8.1;
◾классические приложения для рабочего стола Windows (Windows desktop applications).
То есть появляются инструменты для преобразования Win 32 приложений и компиляции кода Obj-C и игр.
Поживем увидим, но MS гнет свою линию.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
V>>>>Ну так вытяни на фотошопе рисунок так, чтобы кружок стал сильно вытянутым овалом. V>>·>Какая разница какой овальности у тебя кружок? Направление-то одно — пл часовой стрелке. V>>Кошмар )) V>>Два плюс два сложить не в состоянии... ·>Я не собираюсь ничего складывать.
Тогда что ты делаешь на сайте программистов?
·>Если есть что сказать по делу — говори
Было сказано много, но меня раздражает, сорри, когда оппонент демонстрирует дремучую несообразительность.
Получается топтание на месте, а это минус 50 в карму.
·>разгадывать шарады со священниками мне неохота.
Было сказано про чётки. Ты знаешь, что такое чётки? Даже если бы не знал, интернет тебе помог бы.
В любом случае, если даже эта аналогия не помогла тебе понять схему работы кольцевого буфера, то наука тут бессильна.
Здравствуйте, vdimas, Вы писали:
V>>>Два плюс два сложить не в состоянии... V>·>Я не собираюсь ничего складывать. V>Тогда что ты делаешь на сайте программистов?
Развлекаюсь.
V>·>Если есть что сказать по делу — говори V>Было сказано много, но меня раздражает, сорри, когда оппонент демонстрирует дремучую несообразительность. V>Получается топтание на месте, а это минус 50 в карму.
Я и не собирался демонстрировать сообразительнось, не на экзамене ведь.
V>·>разгадывать шарады со священниками мне неохота. V>Было сказано про чётки. Ты знаешь, что такое чётки? Даже если бы не знал, интернет тебе помог бы. V>В любом случае, если даже эта аналогия не помогла тебе понять схему работы кольцевого буфера, то наука тут бессильна.
Я знаю что такое чётки и знаю как кольцевой буфер устроен. И даже ссылки тебе присылал на картинки и на исходники. И ни разу не просил тебе объяснять его устройство.
Я просил объяснить что значит вот это: "схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть". Я просил пояснить какая именно "схема из двух очередней", альтернативная кольцевому буферу является "правльной"?
И с какого бодуна кольцевой буфер это внезапно "две очереди"? А как реализованы эти очереди-то? Кольцевым буфером?!
У тебя причина со следствием перепутаны. Ветер дует потому что деревья качаются. Кольцевой буфер это и есть реализация очереди, притом _одной_ очереди, вот одна из таких реализаций: ArrayBlockingQueue.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Я просил объяснить что значит вот это: "схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть". Я просил пояснить какая именно "схема из двух очередней", альтернативная кольцевому буферу является "правльной"?
Ты не можешь НИЧЕГО тут спрашивать до тех пор, пока не поймешь принципы работы кольцевого буфера.
Тебе ведь всё еще кажется, что продюссеры и консюмеры бегают по кругу по памяти (потому что такова реализация на основе массива фиксированного размера). Но по семантике продюсеры и консюмеры стоят на месте — это просто два разных процесса (потока), а м/у ними бегают навстречу друг другу пустые и полные ячейки памяти (элементы).
·>И с какого бодуна кольцевой буфер это внезапно "две очереди"?
Потому что две очереди образуют структуру данных "Circular Linked List" с такой же точно семантикой.
·>А как реализованы эти очереди-то?
Linked List.
·>У тебя причина со следствием перепутаны. Ветер дует потому что деревья качаются. Кольцевой буфер это и есть реализация очереди, притом _одной_ очереди
"Одной очереди"?
Ты действительно не понимаешь или троллишь, я чего-то понять не могу? )))
Когда Читатель не справляется, мы вынуждены блокировать Писателя, верно?
А почему, не понял еще? )) Потому что его очередью является очередь пустых элементов, и эта очередь пуста.
Так вот, в случае реализации такой же схемы на "Circular Linked List", если очередь пустых элементов пуста, то мы можем легко добавить новый пустой элемент, выделив его из памяти.
Здравствуйте, vdimas, Вы писали:
V>·>Я просил объяснить что значит вот это: "схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть". Я просил пояснить какая именно "схема из двух очередней", альтернативная кольцевому буферу является "правльной"? V>Ты не можешь НИЧЕГО тут спрашивать до тех пор, пока не поймешь принципы работы кольцевого буфера. V>Тебе ведь всё еще кажется, что продюссеры и консюмеры бегают по кругу по памяти (потому что такова реализация на основе массива фиксированного размера). Но по семантике продюсеры и консюмеры стоят на месте — это просто два разных процесса (потока), а м/у ними бегают навстречу друг другу пустые и полные ячейки памяти (элементы).
Какая разница? Движение относительно.
V>·>И с какого бодуна кольцевой буфер это внезапно "две очереди"? V>Потому что две очереди образуют структуру данных "Circular Linked List" с такой же точно семантикой.
Неправда, ты опять толком не разобрался. Кольцевой буфер это вполне конктреная имплементация очереди. Ознакомься хотя бы с вики https://en.wikipedia.org/wiki/Circular_buffer
A circular buffer, circular queue, cyclic buffer or ring buffer is a data structure that uses a single, fixed-size buffer as if it were connected end-to-end
V>·>А как реализованы эти очереди-то? V>Linked List.
Это слишком теоретично и абстрактно. Вспомни-ка, что для linked list нужна динамическая память, а значит менеджер памяти, который сам по себе некая структура данных. Может в обычном приложении это не имеет значение, т.к. менеджер памяти это некий такой абстрактный всемогутер, работающий нулевое время, но когда рассуждаешь в терминах LL надо сразу говорить как это ляжет на конкретное железо. Как как этот самый linked list будет реализован на обычном железе с его кешами, многопоточной обработкой, постраничным доступом, prefetch-ем етс?
V>·>У тебя причина со следствием перепутаны. Ветер дует потому что деревья качаются. Кольцевой буфер это и есть реализация очереди, притом _одной_ очереди V>"Одной очереди"? V>Ты действительно не понимаешь или троллишь, я чего-то понять не могу? )))
Я использую общепринятую терминологию, я тебе уже несколько ссылок послал именно с таким пониманием. Зачем ты настаиваешь на своей странной интерпретации понятий?
V>Когда Читатель не справляется, мы вынуждены блокировать Писателя, верно?
Вариантов много. Можно отреджектить, можно заблокировать, можно дропать, можно динамически отресайзить.
V>А почему, не понял еще? )) Потому что его очередью является очередь пустых элементов, и эта очередь пуста. V>Так вот, в случае реализации такой же схемы на "Circular Linked List", если очередь пустых элементов пуста, то мы можем легко добавить новый пустой элемент, выделив его из памяти.
Проблема linked list что он не очень friendly к железу. Создаёт лишние индирекции и требует хитрого менеджера памяти.
Кстати, размер памяти тоже таки fixed size, что делать если память закончится? Так что этот твой подход полезен в случае приложения с множеством таких очередей, между которыми будет перераспределяться свободная память.
В случае LL-системы там таких буферов немного, и их количество фиксированно. Поэтому проще просто выделить нужные объёмы памяти под каждый и не надеяться на то что менеджер всегда может предоставить любой объём памяти.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Фокус стар как мир и выдаёт лентяев сходу. Ну я примерно 10% таких просьб исполняю, сугубо из альтруистических побуждений и корпоративной солидарности... но совесть же тоже иметь надо? ))
