Pull to refresh
12
0

Пользователь

Send message
Кроме этого ни что не мешает вынести критичный код в библиотеку (с + asm) и вызывать уже оттуда.


А вот люди, что полагаются на возможности SIMD из статьи ниже думают совсем иначе :)
Integrating native code libraries into .NET code for the sake of performance is not guaranteed to yield the benefits of native code optimization unless the custom code itself is also optimized. With the high-level programming models in .NET for SIMD, concurrency I/O, database access, network programming, and many other kinds of operations, developers could choose to develop all their HPC code in .NET and avoid incurring the cost and effort of integrating low-level native code into their applications.


В случае .net jit это только малая часть от данных результатов. Понятное дело, что если векторные оптимизации сами по себе бы не дали таких результатов в managed языке. В целом все развивается вокруг идеи low alloc типов и апи, что не аллоцируют. И высокоуровневое апи для работы с ними, что не требуют писать unmanaged код. Поэтому кроме нормальной поддержки SIMD у них еще большинство апи работают через memory pooling с буферами, что не создают GC pressure со стеком(работать с которым теперь, к слову, так же можно не прибегая к unmanaged коду) или native memory — опять же это все скрыто внутри удобных высокоуровневых Апи не требующих писать тон boilerplate кода как в С/C++ — скорее всего они будут иметь какой-то perf penalty но в целом будут работать соизмеримо и выглядеть куда предпочтительней.
И этот бред кочует из статьи в статью, в.т.ч по Яве, не имея никаких доказательств реального, а не возможного теоретически.

дНет будет иметь «большое преимущество перед C++», когда его хоть как то догонит =)


.net векторизация с оптимизациями недавними рантайма уже вполне сопоставим работает с unmanaged кодом, просто в статье этой нет сравнения с C/C++ — вот почитайте как эти же векторы для мандельброта в managed коде сравнивают с различными комбинациях c unmanaged код на C++. В целом он будет работать быстрее чем невекторизированный код на C/C++. Векторизированный нативный код хоть и быстрее, на с# для SIMD задач скейлится отлично и в режиме многопоточности работает быстрее чем однопоточный векторизированный нативный код.

www.codeproject.com/Articles/1223361/%2FArticles%2F1223361%2FBenchmarking-NET-Core-SIMD-performance-vs-Intel-IS

Если сопоставить с трудозатратами и временем на разработку такого и кода и использованием высокроуневого АПИ на С# — последний очевидно будет более предпочтительным.
Что произойдет если кол-ва начнут расходиться
1. вы можете продать больше товаров, чем у вас есть на самом деле и как следствие потерять клиента
2. не распродать весь сток и тем самым нанести компании убытки

Понятно. То о чем вы говорите называется требование strong write consistency.
Вашим подходом вы не решаете эту проблему вроде как проблему. Если там кто-то у вас руками решает конфликты и получает письма, с сагами, например, вы можете собственно делать тоже самое и даже больше(делать роллбек не руками, в момент покупки и обеспечивать транзакционность даже для распределенных данных). При этом не уходя от event driven дизайна системы, не изобретая велосипед и не создавая связей между сервисами.

Еще можно обратить внимание на дизайн сервисов. Где находиться Core domain — например если склад первичен, то резервация по идее и должна делаться через него. В read-only стейт Stock Service вообще вроде как не имеет требований строгой read консистентности(там банально из-за concurrency может закончиться товар пока он лежит в корзине).
Это поверх messaging надо еще городить еще один механизм? а как же low coupling между микросервисами при разработке таких костылей можно просто работать с монолитом — так как у вас все равно тесная зависимость на контракты другого сервиса, и если меняеться домен сервиса как либо надо диплоить все зависимость — и код обновлять?
По поводу rx это врядли можно считать поддержкой backpressure т.к имплементируешь сам. По поводу channels — оно вроде как ещё очень далеко от production ready функционала. Все эти вещи впринципе можно сделать на Blocking Collection из коробки далеко не надо ходить. Другое дело что все это не затачивалось под оптимизацию нагрузки на gc, и работу с sequence/slices потока — инструменты для разных задач будем говорить прямо.
Могу ошибаться, но в rx вроде как нет backpressure вообще — простой producer/consumer. В data flow ещё есть bounded buffer, но там на клиенте надо делать все — исходя из результата post. А в pipelines backpressure сделан внутри самой либы и flush блочит producer’a.
Возьмите готовый веб сервер с байндингом на какой-то из файловых типов. Задача описанная в статье и предложенный апи немного более низкоуровневая и описанный инструмент так же вернёт вам готовый файл, только сделает это создавая меньше нагрузки на gc при возможности.
Это ограниченность by design.

В чем проблема спрятать эти ifdef в реализации jvm и добавить api в java? Все дело в реализации рнтайма, компилятора, обратной совместимости и языковом дизайне, да и только.

Нет, там на уровне концепции языка нет стека практически. Java программа же не зависит от платформы, виртуальной машины итп.

В том то и дело, все дело в языке — если он не имеет апи для поддержки работы с памятью это ограниченность языка, комплилятора и рантайма — не более, а не ограничение наложенной кросплатформенной моделью разработки.
Единственный способ, спрятать unsafe сейчас с помощью Span это коллбек, что довольно неуклюже.
public delegate void Callback(Span span);

public unsafe void Invoke(Callback callback) {
Span s = stackalloc double[100];
callback(s);
}


Еще можно вот так и в отлчии от Java аллокатора дает гарантировнный результат
	
                static void Main(string[] args)
		{
			var array = "1,3,5,".AsSpan();
			var separator = ",".AsSpan();
			Span<int> span = stackalloc int[3];

			int idx, parsed = 0;
			while ((idx = array.IndexOf(separator)) != -1)
			{
				var val = int.Parse(array.Slice(0, idx));
				array = array.Slice(idx + 1);
				span[parsed++] = val;
			}

			var res = 0;
			foreach (var i in span)
			{
				res += i;
			}

			Console.WriteLine(res);
			Console.ReadLine();
		}


unsafe не нужен при работе со стеком.
Но тот же new Object() может заалоцировать объект хоть в хипе, хоть на стеке, хоть вообще по регистрам раскидать его.

www.beyondjava.net/escape-analysis-java
shipilev.net/jvm-anatomy-park/18-scalar-replacement
Вот это ваш прорыв в мире jvm?
dotnet делает это намного более предсказуемо и стабильно и делал это намного раньше чем появилось в java. Не думаю, что кто либо полагается на ваш new () аллокатор, который даже не может дать предсказуемого результата по выделении памяти в рамках метода. Как микрооптимизация, если сработало — ок, не сработало — сорри. Концептуально на проблемы работы с managed памятью это никак не повлияло — фрагментация, STW паузы и прочие прелести тормознутой managed платформы остались на месте.

Дело не только в стеке, но и в возможности работать c native memory не задействуя механизмы CLR и значительно оптимизируясь механизмы выделения памяти, освобождения. в .net нам это апи переписаны многие стандартные net framework вещи — работа с сокетами, parsing api, работа с потоками(TPL) и т.д как результат интенсивные вычисления чувствительные к аллокациям даже из высокоуровневого api делают с производительностью native кода


https://www.codeproject.com/Articles/1223361/Benchmarking-NET-Core-SIMD-performance-vs-Intel-IS


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

Stop/start вызывается когда стартует/останавливается хост. Впринципе это чего не было в asp.net из коробки ранее, все остальное как что шедулить и останавливать забота девелопера.

Эта возможность есть и в Ef 6 platform кстати.

В Ef core 2.0 есть возможность мапить функции из коробки без необходимости расширять библиотеку.
http://anthonygiretti.com/2018/01/11/entity-framework-core-2-scalar-function-mapping/

Ну так приватный код на то и приватный, что б не через рефлексию его дёргать в продакшин коде.
Кстати, такой вопрос чем все- таки обусловлена использования Linux контейнера для интеграции с wcf, ntlm?

В asp.net core так же используется web.config если приложение хостится под iis для настройки веб сервера и параметров запуска хоста — например environment.

Упустили самую интересную часть — как настраивали AD аутентификацию из под Linux контейнера. Kestrel бекенд сервер, это по сути обертка над с++ библиотекой сетевого i\o, веб сервером его с натяжкой можно назвать. Для него вроде есть что-то что работает под виндой с NTLM, но обычно всегда берут серьезный front-end сервер для этих задач c готовыми решениями — например iis или nginx под Linux, а их уже использует kestrel как reverse proxy.

Про kubrrnetes тоже интересно почитать, обычно в один контейнер запихивать все приложение и для этого брать оркестратор типа kubernetes вообще решение не много непонятное, к тому же если у вас on-premise решение, а не облако.
Что бы развивать asp.net core быстрее чем стандарт. Owin это просто интерфейс/адаптер, через которые можно подключать больше компонентов совместимых с owin спецификацией. Middleware это просто ещё один способ обозвать всем известный паттерн chain of responsibility, он был и до появления owin — в веб формах, классическом mvc(http modules), в web api — message handlers/delegating handlers.
Вообще не понятно зачем при такой задаче как пробросить данные из источника используется сериализация-десериализация. Пустой бесполезный оверхед, который и сьедает всю память. Подход неоптимальный впринципе.

Information

Rating
Does not participate
Registered
Activity