61.5
Karma
0
Rating
Павел Тупицын @kefirr

Ignite.NET maintainer

Асинхронный рассинхрон: антипаттерны в работе с async/await в .NET

0

Очень хорошее замечание. На мой взгляд, лучше лишний раз не думать (и не заставлять коллег думать) и всегда писать async/await. Далеко не все даже опытные разработчики держат в голове все эти тонкости.

Ломаем фундаментальные основы C#: выделение памяти под ссылочный тип на стеке

0

Занятно! К картинкам можно добавить подпись, что все эти размеры полей и смещения — для 32 битного режима.

Алло, мы ищем фрилансеров: завтра открывается сезон поиска новой работы

-1
это не то же самое, что 40-часовая рабочая неделя в офисе

С учетом того, что ехать никуда не надо, примерно то на то и выходит (если дорога от получаса и больше в один конец).


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

Apache Ignite.NET 2.4: Тонкий и кроссплатформенный

0

Именно поэтому сделан тонкий клиент, который использует только чистый .NET и дополнительных требований не имеет.

Apache Ignite.NET 2.4: Тонкий и кроссплатформенный

Apache Ignite.NET 2.4: Тонкий и кроссплатформенный

+2

Представим узлы кластера А и Б, толстый клиент К, тонкий клиент Т подключен к узлу А.


При попытке извлечь данные, находящиеся на узле Б, толстый клиент отправит запрос напрямую. Тонкий же работает только через узел А.


А как толстый клиент с JVM обшается? Это быстро?

Через JNI и указатели на unmanaged (offheap) память. Да, это намного быстрее сокета.

Анатомия .NET Core: как мы настроили NTLM под Linux

[DotNetBook] Stackalloc: забытая команда C#

0

Сколько в стеке свободного места есть. Размер стека по умолчанию на винде 1 или 4 метра (32/64 бит), на Линухе по-разному, частый вариант — 8 метров.


Ну и часть этого места наверняка занята самим стеком вызовов.

[DotNetBook] Stackalloc: забытая команда C#

+1

Думаю, что stackalloc используется так редко, потому что либо размер буфера предопределён и данные структурированы, тогда просто заполняется struct и берётся указатель, либо размер буфера непредсказуем.

[DotNetBook] Stackalloc: забытая команда C#

+2

В Ignite.NET использование stackalloc для передачи JNI аргументов (varargs / va_list) вместо params JavaValue[] подняло перформанс реальных кэшовых операций на 15% и избавило от лишних аллокаций / GC.


Код на гитхабе: UnmanagedUtils.cs


Ещё пример, перетасовка байт: WriteGuidSlow

Кроссплатформенная новогодняя демка на .NET Core и Avalonia

+2
msil-инструкцию calli, которая выполняет прямой вызов по указателю без автоматических преобразований

Интересно, а где можно на это посмотреть?

Кроссплатформенная новогодняя демка на .NET Core и Avalonia

+10

В JSON даже комментарии нельзя вставлять, не говоря уже о схемах и прочем.
Для передачи данных да, он компактнее и, может, более читаем. Но для разметки, конфигов я предпочту XML.

Кроссплатформенная новогодняя демка на .NET Core и Avalonia

+6

"Неторопливая" — очень относительное понятие. Да, PInvoke медленный по сравнению с прямым вызовом функции, он добавляет от 10 до 30 инструкций (см MSDN). Но надо понимать, что эта разница — порядка наносекунд, и в случае вызова функций сложнее a+b просто теряется. Например, Ignite.NET работает с JVM через PInvoke, и тормозов от этого не испытывает.


Electron:


  • тащит за собой целый браузер, жрёт немеряно памяти и создаёт новый процесс на каждый чих
  • C# быстрее JavaScript и лучше во всех отношениях
  • XAML лучше HTML

Другое дело, что layout & rendering в Electron действительно может быть быстрее для некоторых сценариев, браузерный движок очень круто заоптимизирован под это дело.

Кроссплатформенная новогодняя демка на .NET Core и Avalonia

ААА! Пришло время переписывать на .NET Coreǃ

+1

.NET Standard не содержит кода, это просто перечень API. Код находится в фреймворках (.NET 4.6 или .NET Core 2.0, например). Фреймворки реализуют ту или иную версию стандарта.

ААА! Пришло время переписывать на .NET Coreǃ

+1

Стоит упомянуть, что из проектов на .NET Core 2.0+ можно референсить сборки и нугеты ЛЮБОЙ версии .NET, и оно будет работать под линух, если либа не использует windows-specific API.


То есть если вы — автор библиотеки, то не обязательно переезжать на кору, достаточно проверить, что нет windows-specific вызовов, или обернуть их в if-else.


Мы так поступили в Apache Ignite.NET. Всё работает под линух и макось, но сохранена поддержка VS 2010.

Открытый веб-интерфейс для .NET (OWIN)

Fall Creators Update: важное для программиста

+1

Не очень понял этот комментарий.


  • XAML — это просто представление объектной иерархии. Всё, что можно выразить в XAML, можно выразить и в C# (но не наоборот).
  • XAML/BAML нужно в рантайме превратить в дерево объектов, это дороже, чем выполнить скомпилированный C# код (про CAML не в курсе, может, он решает проблему).

XAML декларативный, и он удобнее для описания UI, с этим спору нет. Но в профайлере явно видно, на что уходит время при загрузке развесистых контролов.

Fall Creators Update: важное для программиста

Fall Creators Update: важное для программиста

+1

И это работает в десятки раз быстрее.
Когда работал с WPF, стандартный подход к оптимизации, например, тяжелого DataTemplate в больших списках — перейти от XAML к аналогичному коду на C#.

Тройка, семерка, джокер — разбор решения задач из буклета GridGain на конференции Joker 2017

Что не так с уязвимостями в C# проектах?

+6

Или огорчаешься, потому что мало серьёзных проектов с открытым кодом на C#.

Используем Apache Ignite в быту

0

Почитать можно на оф. сайте.


  1. GridGain выпускает платный плагин для Ignite, там это есть


  2. Data Center Replication


  3. Да


  4. Security


  5. Management


  6. Да

Развитие идёт как раз в сторону полноценной SQL базы данных. Пробелов по сравнению с большими дядями (Oracle/Postgres/...) пока много, но работа идёт именно в этом направлении.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

+1

Существующая опция останется, это важный сценарий использования, отказываться от него никаких причин нет.


Работа над тонким клиентом уже идёт, он будет доступен в версии 2.4 (конец года).


Обе опции будут поддерживаться под .NET Core 2.0. "Серверный режим" заводится пока только под windows (любая версия уже работает), тонкий клиент работает и под Linux (если взять ночной билд, можно уже сейчас это попробовать: https://myget.org/gallery/apache-ignite-net-nightly).

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0

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

Используем Apache Ignite в быту

0
строить микросервисную архитектуру

Для этого есть Ignite Services API (упомянут в этой статье, кстати):
https://habrahabr.ru/company/gridgain/blog/327380/
https://apacheignite.readme.io/docs/service-grid


request-response взаимодействия между нодами

Да, это всё те же services, а так же Compute, который помимо map-reduce функционала позволяет выборочно выполнить код на конкретном узле.
https://apacheignite-net.readme.io/docs/compute-grid

Используем Apache Ignite в быту

0

Да, без сомнения, но сроков пока нет. Думаю, в следующем году.

Используем Apache Ignite в быту

+2

Не совсем так; in-process JVM — это детали реализации.


Межпроцессное взаимодействие осуществляется через различные API Ignite — Cache, Messaging, Compute, и так далее. Эти API есть в Java, .NET, C++. Таким образом, приложения в разных процессах, написанные на разных языках, могут взаимодействовать друг с другом.

Используем Apache Ignite в быту

Используем Apache Ignite в быту

Используем Apache Ignite в быту

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0

Там всё меняется каждый день, то одно, то другое. Слишком сыро. Плюс сложности с обратной совместимостью проектов.


На данный момент принято решение дождаться выхода .NET Standard 2.0. Подробности в каментах тикета: https://issues.apache.org/jira/browse/IGNITE-2662


уже никто не выпускает

сильное преувеличение

Делегаты и Лямбда выражения в C# .Net — Шпаргалка или коротко о главном

0
Получается довольно бессмысленно, но работает.
void MyFunc(myDelegate deleg, int arg){deleg.Invoke(arg);}

Очень даже не бессмысленно.


Пусть нам нужно выполнить тяжёлую обработку большого набора данных. Такой метод может распараллеливать вычисления автоматически между потоками (PLINQ, Parallel.ForEach) или компьютерами (Ignite):
IEnumerable<TRes> Apply<TArg, TRes>(Func<TArg, TRes> func, IEnumerable<TArg> args)


P.S. .Net -> .NET

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

-1

Я бы не сказал, что это "совершенно разные продукты". Как раз таки в основе своей они одинаковые — распределённый кэш.


У Ignite богаче функционал самого кэша, и много других фич.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0

Для Spark есть вот такая интеграция: Shared Apache Spark RDDs


Если нужно просто положить инстансы DataFrame в кэш — с этим не должно быть проблем.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0

Небольшая дискуссия образовалась там: Tarantool как основное хранилище данных для серверных приложений, написанных на .NET.


В Tarantool есть персистенс, но нет SQL, нет нормальной поддержки .NET/С++ и многого другого.


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

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0
2 кучи, 2 GC

Давайте предметно, какие проблемы вы предвидите?
Обычный .NET код сплошь и рядом дёргает системные API, у которых своя unmanaged куча, и что?


Проблемы тут могут быть в x86 (32 bit), где сильно ограничено адресное пространство. В x64 с этим проблем нет. Но речь идёт о big data, так что 32 бита нас не особо беспокоят.


2 stop the world

Не все GC делают stop the world, это раз. Аллокации в managed heap на стороне Java минимальны, это два. Пользовательские данные хранятся в неуправляемой куче через Unsafe.


порт сделать

Полноценный порт потребует титанических усилий, значительно увеличит затраты на поддержку кода, и приведёт к менее гибкому решению. Смысла мало.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

+1

В случае сегментации ("split brain") будет два кластера, да. Можно реализовать свой SegmentationResolver в качестве плагина. Плагин GridGain предоставляет свою реализацию. См тут.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

+1
  1. Персистенс возможен через Cache Store. Другой вариант — настройка реплик (CacheConfiguration.Backups), то есть только одновременный выход нескольких узлов приведёт к потере данных.


  2. Общаются по TCP, находить друг друга могут по-разному, есть multicast discovery, есть static (указать IP в конфиге). Порты по умолчанию 47500~47600 для discovery и 47100~47200 для коммуникации. Это НЕ для одного сервера. Предполагается кластер из некоторого числа серверов.


  3. Будет собирать с нескольких узлов. Данные разбиваются на партиции (1024 по умолчанию), партиции распределяются между узлами. За это всё отвечает Affinity Function. При входе нового узла каждая партиция запрашивается со случайного узла из тех, на которых она есть (в Partitioned режиме с Backups > 0 таких узлов тоже несколько).


  4. Верно, NuGet содержит в себе jar файлы, больше ничего не нужно.

Для чего нужен Apache Ignite / GridGain, на примере .NET & C#

0

Полноценный персистенс будет в 2.1 (через пару месяцев), а пока есть различные варианты write-behind или write-through в дисковую БД. Изначально это in-memory система, в угоду производительности.

1 There