Недавно вышла статья которая неплохо показывает тенденцию в машинном обучении последних лет. Если коротко: число стартапов в области машинного обучения в последние два года резко упало.

Ну что. Разберём “лопнул ли пузырь”, “как дальше жить” и поговорим откуда вообще такая загогулина.
Читать полностью »
Рубрика «memory» - 2
Время фрагментарно; немного о сходстве распределенных систем и слабой модели памяти
2018-11-24 в 13:27, admin, рубрики: .net, c++, consistency, distributed systems, memory, multithreading, Блог компании Издательский дом «Питер», вычисления, параллельное программирование, распределенные системыПривет всем!
Сегодня мы хотели бы в очередной раз затронуть тему одновременного и последовательного выполнения в различных программах, особенно — в распределенных системах. Еще в сентябре мы публиковали статью "Синхронность — это миф" на эту тему, а теперь публикуем перевод более серьезного исследования, которое, надеемся, поможет вам лучше сориентироваться с распределенными системами.
Читать полностью »
Что происходит за кулисами С#: основы работы со стеком
2018-10-29 в 7:33, admin, рубрики: .net, C#, compiling, inside, JIT-компилятор, memory, stack, structlayout, ненормальное программирование, оопПредлагаю посмотреть все то, что стоит за простыми строками инициализации объектов, вызова методов и передачи параметров. Ну и, разумеется, использование этих сведений на практике — вычитывание стека вызывающего метода.
Дисклеймер
Прежде, чем приступить к повествованию, настоятельно рекомендую ознакомиться с первым постом про StructLayout, т.к. там разобран пример, который будет использоваться в этой статье.
Весь код, кроющийся за высокоуровневым, представлен для режима отладки, именно он показывают концептуальную основу. JIT оптимизации — это отдельная и большая тема, которая здесь рассматриваться не будет.
Также хотелось бы предупредить, что данная статья не содержит материал, который стоит применять в реальных проектах.
Начинаем с теории
Любой код в конечном итоге становится набором машинных комманд. Наиболее понятно их представление в виде инструкций языка Ассемблера, прямо соответсвующих одной (или нескольким) машинным инструкциям.

Пропихиваем параметры в небезопасные операции в безопасном коде
2018-09-21 в 12:29, admin, рубрики: .net, C#, inside, memory, method table, structlayout, ненормальное программирование, ооп, Проектирование и рефакторингВсем привет. В этот раз продолжаем смеяться над нормальным вызовом методов. Предлагаю ознакомится с вызовом метода с параметрами без передачи параметров. Также попробуем преобразовать ссылочный тип в число — его адрес, без использования указателей и unsafe кода.

Не уважаю инкапсуляцию, или использование таблицы методов другого типа для быстрого вызова приватных методов
2018-09-18 в 12:09, admin, рубрики: .net, C#, inside, memory, method table, structlayout, высокая производительность, ненормальное программирование, оопВсем привет. Хотелось бы поделиться примером использования StructLayout для чего-то более интересного, чем примеры с байтами, интами и прочими цифрами, в которых все происходит чуть более, чем ожидаемо.
Читать полностью »
[DotNetBook]: Span, Memory и ReadOnlyMemory
2018-08-13 в 12:40, admin, рубрики: .net, C#, clrbook, DotNetBook, memory, span
Этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
Memory<T> и ReadOnlyMemory<T>
Визуальных отличий Memory<T> от Span<T> два. Первое — тип Memory<T> не содержит ограничения ref в заголовке типа. Т.е., другими словами, тип Memory<T> имеет право находиться не только на стеке, являясь либо локальной переменной либо параметром метода либо его возвращаемым значением, но и находиться в куче, ссылаясь оттуда на некоторые данные в памяти. Однако эта маленькая разница создает огромную разницу в поведении и возможностях Memory<T> в сравнении с Span<T>. В отличии от Span<T>, который представляет собой средство пользования неким буфером данных для некоторых методов, тип Memory<T> предназначен для хранения информации о буфере, а не для работы с ним.
Эта статья — вторая из цикла про Span<T> и Memory<T>. Она является вводной для Memory<T> в том плане что здесь я решил расписать общую терминилогию, а вот примеры совместного использования — решил вывести в отдельную статью
- Span<T>: новый тип данных .NET
- Span<T> и ReadOnlyMemory<T>
- Практика использования Span<T> и Memory<T>
[DotNetBook] Span: новый тип данных .NET
2018-08-01 в 13:15, admin, рубрики: .net, C#, clrbook, memory, memory management, span, unsafe![[DotNetBook] Span: новый тип данных .NET - 1 [DotNetBook] Span: новый тип данных .NET - 1](https://www.pvsm.ru/images/2018/08/01/DotNetBook-Span-novyi-tip-dannyh-NET.jpeg)
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом (уже готово около 200 страниц книги, так что добро пожаловать в конец статьи за ссылками).
Как язык, так и платформа существуют уже много лет: и все это время существовало множество средств для работы с неуправляемым кодом. Так почему же сейчас выходит очередной API для работы с неуправляемым кодом если по сути он существовал уже много-много лет? Для того чтобы ответить на этот вопрос достаточно понять чего не хватало нам раньше.
Разработчики платформы и раньше пытались нам помочь скрасить будни разработки с использованием неуправляемых ресурсов: это и автоматические врапперы для импортируемых методов. И маршаллинг, который в большинстве случаев работатет автоматически. Это также инструкция stackallloc, о которой говорится в главе про стек потока. Однако, как по мне если ранние разработчики с использованием языка C# приходили из мира C++ (как сделал это и я), то сейчас они приходят из более высокоуровневых языков (я, например, знаю разработчика, который пришел из JavaScript). А что это означает? Это означает что люди со все большим подозрением начинают относиться к неуправляемым ресурсам и конструкциям, близким по духу к C/C++ и уж тем более — к языку Ассемблера.
Статья хоть и большая, но является вводной в тему
Span<T>иMemory<T>. Планируется что выйдет еще две: первая проMemory<T>, MemoryManager<T>, MemoryHandler<T>иMemoryPool<T>. Вторая — про низкоуровневые особенности и вопросы кSpan<T>иMemory<T>.
Сколько объектов выделяет Python, выполняя скрипты?
2018-07-26 в 12:35, admin, рубрики: gc, memory, python, ПрограммированиеНекоторые Python программисты сильно удивляются, когда узнают сколько временных объектов интерпретатор питона выделяет во время работы простого скрипта.
CPython позволяет получить статистику по выделяемым объектам, для этого его нужно скомпилировать с дополнительными флагами.
./configure CFLAGS='-DCOUNT_ALLOCS' --with-pydebug
make -s -j2
Java и без 16Gb памяти?
2017-07-16 в 12:11, admin, рубрики: ads-b, heap, java, memory, Raspberry Pi, Satellite, спутникиОднажды меня посетила мысль о том, что надо закодить что-нибудь на Java для RaspberryPI. Предыстория того, как я дошёл до жизни такой, сама по себе потянет на отдельный пост. Но вот сочные технические подробности, трудности и счастливый конец ниже под катом.


