>когда пара ядер дергает одну блокировку, при каждом дергании происходит ещё сброс соответствующих кэш-линий у «соседнего» ядра
что это значит? если под понятием «дергании» имеется ввиду операция попытки захвата, то это несколько не так: сброс кеш-линии будет происходить только при операции записи значения «счетчика», а попытка захвата — лишь чтение изначально.
Да, при успешной записи L1-кеш у каждого ядра обновится и общий L2 — тоже. Однако это справедливо для любой операции записи.
И вот здесь самое интересное: мгновенный сброс кеш-линий (или эмуляция оного для юзера) для каждой записи возможен, но только если существует total-store-order между потоками. эта очень вещь затратная и все стараются такие операции записи обходить. здесь уже появляется lock-free код.
критическая секция в Win32 устроена внутри как CAS-цикл, т.е. захват может не всегда быть удачным при первой и последующих попытках, но цикл будет продолжаться. Таким образом, попытка захвата — лишь чтение изначально, но не запись.
графики показывают очень важную вещь (что есть правда) — чем больше кол-во конкурирующих между собой потоков — тем больше проседает система.
здесь необходимо сделать ремарку: lock-free является вещью опасной, т.к. оно еще плохо сочетается с планировщиком ОС. Если система должна быть высококонкурентной, то нужно пользоваться SwitchToThread и т.п. (использовать что-то наподобие spin-wait), иначе
>накладные расходы на блокировки начинают влиять на общую производительность
Еще на конференции Build 2016 рассказали планы по .NET Standard. Кстати, RC2 тулинг для VSCode уже показывает NETStandard1.5 профиль для запуска проектов.
Если опустить разницу в доступности публичных API между версиям, то .NET Core RC2 спокойно подтягивает весьма сложные библиотеки. Кстати в RC2 уже идут патчи для RyuJIT, доступные в апдейтах .NET 4.6.
с импортозамещением лишь одна проблема: нужно время!
в современном мире есть понятие технологического стека (про который Вы прекрасно знаете, я надеюсь).
в связи с этим вопрос: какой технологический стек появился у нас за последние 5 лет? и будет ли он хотя бы через 10?
кроме оборонки никто не интресуется собственно разработкой технологий, да и первые не слишком активно это делают.
хочу заметить, что «Сократ» не является ИИ, который будет штамповать технологии, издавать законы и управлять вооруженными силами страны. да, весьма интересный проект по планированию экономики. но не единственный в природе.
а про «H.R. 516 Return Jobs in America Act» — посмотрим. пока что объем налогов и соц. взносов в США весьма крупный.
хочу заметить, что вопрос про применимость матлаба для НАСА не обсуждался.
p.s.
коррекция лазера, конечно, круто. НО! здесь есть люди, которые создают/разрабатывают системы (не утилиты/программы в полстраницы) в сотни тысяч строк кода и более, которые должны обеспечивать надежность/масштабируемость и сопровождаемость в будущем для организаций в десятки раз больше, чем НАСА, например. При этом UI является лишь частью (наверное, меньшей частью из всего).
то, что Вы описываете, называется RAD. А еще лучше: UI-компоненты (Controls). Класс UI фреймворков, не зависящих от языка, платформы и т.д.
Они были, есть и будут как для десктопной разработки на .NET (Silverlight бывший), так и для Delphi, JavaScript (ExtJS, например).
А вот данный момент меня смущает очень сильно:
для системы Инвентори одной из компаний в США хватило средств Visual Studio for Windows
для системы автоматизации труда дискрайберов в той компании США использовал Delphi for Windows
чем обусловлен данный выбор? хоть Delphi, хоть C#, хоть Java являются алгоритмическими языками. Да и экосистема компонентов (т.е. UI Controls) также существует.
для физико — математических задач (для НАСА) мне подошел только Матлаб
Однако! пакет (т.е. специализированный набор функций, структур и т.д.) внезапно сравнивается с самой разработкой приложений.
Вместо Матлаб здесь могла бы быть реклама любая др. библиотека.
p.s.
пожалуйста, не надо вспоминать про WebForms и ко. (JavaServer Faces и т.д.). Для спагетти кода (мягко выражаясь), конечно, подходит на отлично. НО как дело доходит до поддержки, то все.
Да, на WebForms можно писать качественные приложения. использовать MVP-шаблон вместо MVC. но сколько таких разработчиков все еще на WebForms, а? все перешли на MVC.
при открытии любого .NET Core проекта Visual Studio автоматически сконвертирует .xproj в .csproj, перенеся данные из project.json в файлы конфигурации и сам .csproj файл
кто сказал, что у фреймворка больше нет сообщества ?!
ASP.NET Core — тот же MVC, только в профиль. основная работа ведется по кросплатформенному запуску веб-приложений, т.к. предыдущие версии (т.е. pipeline обработки запросов) сильно были завязаны на инфраструктуру IIS.
также поступает большое кол-во pull-реквестов от сообщества. чего только стоит патч увеличивающий производительность до более 1 млн. запросов в секунду.
MVC был создан под влиянием Ruby on Rails. Core — ориентирован на быстрое развертывание а-ля node.js.
ах да, забыл самое главное: ASP.NET востребован в Ынтерпрайзе, где много капиталовложений.
нет, я не считаю, что с появлением dynamic в C# появился multiple dispatch.
вышеназванный шаблон прекрасно эмулируется через if, switch, visitor pattern в C, Java, C++ и т.д. даже reflection подойдет как крайний случай.
но обычно предполагается, что visitor является примером решения/частным случаем самого double dispatch и обычно используется для отделения данных от алгоритмов.
Типичным примером для visitor'a является (как Вы сами прекрасно знаете) обход какого-либо набора данных, скажем AST.
как и в случае с примером из статьи, вместо CollideWith — Visit/Accept. плюсом является использование принципа открытости/закрытости.
НО, visitor — это поведенческий шаблон, в то время как double/multiple dispatch являются такими же атрибутами полиморфизма как и параметрический полиморфизм (aka обобщения aka generics).
Ведь оба вводят понятие динамической диспетчеризации в пику single dispatch.
Почему double dispatch — частный случай multiple dispatch?
Потому что он (т.е. double dispatch) эмулирует последний (multiple dispatch), используя single dispatch. выбор перегрузки осуществляется на этапе компиляции, не так ли?
т.о., multiple dispatch является понятием более широким, чем double dispatch.
visitor, в свою очередь, является лишь примером решения/реализации double dispatch. в ситуации, когда сущности и их поведение сильно сплетены, то, увы, даже большой с натяжкой будет трудно это назвать visitor'ом. называть это можно будет как угодно, но double dispatch будет.
p.s.
надеюсь, что мы не потеряли еще одну важную деталь: double dispatch оперирует с 2-мя аргументами (где 1-й сам экземпляр, например), а multiple dispatch — со всеми аргументами метода, что только подтверждает умозаключения в статье.
спасибо кэп) только вот не надо путать возможности системы типов и ООП. есть системы, где этого нет.
>В таких случаях я всегда применяю Visitor
круто! принцип timtowtdi должен быть всегда, но по теме?
причинно-следственную связь между параграфами держать не обязательно?
т.е. надо писать статью в виде твита: не используешь visitor, тогда мы идем к вам, да? изобиловать выражениями вида «ну вы поняли».
>Не нужно в этом месте придумывать велосипед.
т.е. Вы назвали целый блок паттернов велосипедом. угу…
верно подмечено! т.к. сам visitor относится к семейству шаблонов динамической диспетчеризации так же, как и double dispatch, то хотелось «разбавить» статью. visitor подошел бы тоже
Тип System.__Canon никогда не виден ни при написании MSIL'a, ни при приведении типов. Данная особенность является внутренней оптимизацией CLR и может не применяться др. реализациями. так это позволяет упростить сам процесс выявления зависимостей между типами загрузчиком, т.к. происходит трекинг лишь System.__Canon.
p.s.
Это никак не влияет на кодогенерацию MSIL будь то Mono.Cecil, либо Reflection.Emit и т.п.
Код загрузки типов в основном сосредоточен в секции vm. Несколько размазан, но конкретно по теме: загрузка generics. Вместо метода CheckInstantiationForRecursion из проекта Rotor (sscli20) код стал более ООП-шным и теперь используется граф (RecursionGraph).
кстати, по архитектуре загрузчика типов более подробно.
что это значит? если под понятием «дергании» имеется ввиду операция попытки захвата, то это несколько не так: сброс кеш-линии будет происходить только при операции записи значения «счетчика», а попытка захвата — лишь чтение изначально.
Да, при успешной записи L1-кеш у каждого ядра обновится и общий L2 — тоже. Однако это справедливо для любой операции записи.
И вот здесь самое интересное: мгновенный сброс кеш-линий (или эмуляция оного для юзера) для каждой записи возможен, но только если существует total-store-order между потоками. эта очень вещь затратная и все стараются такие операции записи обходить. здесь уже появляется lock-free код.
критическая секция в Win32 устроена внутри как CAS-цикл, т.е. захват может не всегда быть удачным при первой и последующих попытках, но цикл будет продолжаться. Таким образом, попытка захвата — лишь чтение изначально, но не запись.
графики показывают очень важную вещь (что есть правда) — чем больше кол-во конкурирующих между собой потоков — тем больше проседает система.
здесь необходимо сделать ремарку: lock-free является вещью опасной, т.к. оно еще плохо сочетается с планировщиком ОС. Если система должна быть высококонкурентной, то нужно пользоваться SwitchToThread и т.п. (использовать что-то наподобие spin-wait), иначе
>накладные расходы на блокировки начинают влиять на общую производительность
планы по WebAssembly и т.п.: экспериментируют со многими вещами, в том числе и LLVM.
Даже был компилятор в JS.
Но это никоим образом не влияет на корпоративный план (т.е. менеджмента, а не разработчиков), что только подтверждают изменения project.json и т.д.
Если опустить разницу в доступности публичных API между версиям, то .NET Core RC2 спокойно подтягивает весьма сложные библиотеки. Кстати в RC2 уже идут патчи для RyuJIT, доступные в апдейтах .NET 4.6.
в современном мире есть понятие технологического стека (про который Вы прекрасно знаете, я надеюсь).
в связи с этим вопрос: какой технологический стек появился у нас за последние 5 лет? и будет ли он хотя бы через 10?
кроме оборонки никто не интресуется собственно разработкой технологий, да и первые не слишком активно это делают.
а про «H.R. 516 Return Jobs in America Act» — посмотрим. пока что объем налогов и соц. взносов в США весьма крупный.
p.s.
коррекция лазера, конечно, круто. НО! здесь есть люди, которые создают/разрабатывают системы (не утилиты/программы в полстраницы) в сотни тысяч строк кода и более, которые должны обеспечивать надежность/масштабируемость и сопровождаемость в будущем для организаций в десятки раз больше, чем НАСА, например. При этом UI является лишь частью (наверное, меньшей частью из всего).
Они были, есть и будут как для десктопной разработки на .NET (Silverlight бывший), так и для Delphi, JavaScript (ExtJS, например).
А вот данный момент меня смущает очень сильно:
чем обусловлен данный выбор? хоть Delphi, хоть C#, хоть Java являются алгоритмическими языками. Да и экосистема компонентов (т.е. UI Controls) также существует.
Однако! пакет (т.е. специализированный набор функций, структур и т.д.) внезапно сравнивается с самой разработкой приложений.
Вместо Матлаб
здесь могла бы быть рекламалюбая др. библиотека.p.s.
пожалуйста, не надо вспоминать про WebForms и ко. (JavaServer Faces и т.д.). Для спагетти кода (мягко выражаясь), конечно, подходит на отлично. НО как дело доходит до поддержки, то все.
Да, на WebForms можно писать качественные приложения. использовать MVP-шаблон вместо MVC. но сколько таких разработчиков все еще на WebForms, а? все перешли на MVC.
ASP.NET Core — тот же MVC, только в профиль. основная работа ведется по кросплатформенному запуску веб-приложений, т.к. предыдущие версии (т.е. pipeline обработки запросов) сильно были завязаны на инфраструктуру IIS.
также поступает большое кол-во pull-реквестов от сообщества. чего только стоит патч увеличивающий производительность до более 1 млн. запросов в секунду.
MVC был создан под влиянием Ruby on Rails. Core — ориентирован на быстрое развертывание а-ля node.js.
ах да, забыл самое главное: ASP.NET востребован в Ынтерпрайзе, где много капиталовложений.
p.s.
наверное, имели в виду статическую типизацию, ибо тот же Python — язык динамический, но со строгой типизацией.
вышеназванный шаблон прекрасно эмулируется через if, switch, visitor pattern в C, Java, C++ и т.д. даже reflection подойдет как крайний случай.
но обычно предполагается, что visitor является примером решения/частным случаем самого double dispatch и обычно используется для отделения данных от алгоритмов.
Типичным примером для visitor'a является (как Вы сами прекрасно знаете) обход какого-либо набора данных, скажем AST.
как и в случае с примером из статьи, вместо CollideWith — Visit/Accept. плюсом является использование принципа открытости/закрытости.
НО, visitor — это поведенческий шаблон, в то время как double/multiple dispatch являются такими же атрибутами полиморфизма как и параметрический полиморфизм (aka обобщения aka generics).
Ведь оба вводят понятие динамической диспетчеризации в пику single dispatch.
Почему double dispatch — частный случай multiple dispatch?
Потому что он (т.е. double dispatch) эмулирует последний (multiple dispatch), используя single dispatch. выбор перегрузки осуществляется на этапе компиляции, не так ли?
т.о., multiple dispatch является понятием более широким, чем double dispatch.
visitor, в свою очередь, является лишь примером решения/реализации double dispatch. в ситуации, когда сущности и их поведение сильно сплетены, то, увы, даже большой с натяжкой будет трудно это назвать visitor'ом. называть это можно будет как угодно, но double dispatch будет.
p.s.
надеюсь, что мы не потеряли еще одну важную деталь: double dispatch оперирует с 2-мя аргументами (где 1-й сам экземпляр, например), а multiple dispatch — со всеми аргументами метода, что только подтверждает умозаключения в статье.
предлагаю на этом закончить дискуссию :)
спасибо кэп) только вот не надо путать возможности системы типов и ООП. есть системы, где этого нет.
>В таких случаях я всегда применяю Visitor
круто! принцип timtowtdi должен быть всегда, но по теме?
причинно-следственную связь между параграфами держать не обязательно?
т.е. надо писать статью в виде твита: не используешь visitor,
тогда мы идем к вам, да? изобиловать выражениями вида «ну вы поняли».>Не нужно в этом месте придумывать велосипед.
т.е. Вы назвали целый блок паттернов велосипедом. угу…
нужно: используя ссылку базового типа — выбрать правильную перегрузку.
reflection — не то что план B, а самый H :)
System.__Canonникогда не виден ни при написании MSIL'a, ни при приведении типов. Данная особенность является внутренней оптимизацией CLR и может не применяться др. реализациями. так это позволяет упростить сам процесс выявления зависимостей между типами загрузчиком, т.к. происходит трекинг лишьSystem.__Canon.p.s.
Это никак не влияет на кодогенерацию MSIL будь то Mono.Cecil, либо Reflection.Emit и т.п.
кстати, по архитектуре загрузчика типов более подробно.