И если я 1000 потоков вызову, то получается на каждый поток по 100 кб будет выделено или нет?

А если мы память выделяем через malloc: auto m = malloc(1000_000_00); то она сразу после старта резервировться должна или там тоже не все так просто?

Просто у меня потребление памяти приложением почему-то не меняется после конструкции выше

операционка выделяет память при первой записи в неё, а не на malloc. пройдись и обнули и всё будет

а как обнуление вышлядит? Мне нужно указатель создать и им как-то пройтись?

malloc уже вернул указатель, правда нетипизированный. обычно при исользовании malloc принято сразу кастовать в нужный тип

ну а имея указатель обычный for (size_t i = 0; i < size; ++i)

а зачем тебе malloc? что такого специфичного хочется, что GC память не устраивает?

Просто пока разбираюсь как оно работает.

auto m = malloc(1000_000_00); for (size_t i = 0; i < size; ++i) { m[i] = 0; } Я херню написал?

да :)

size_t size = 10_000_000; ubyte* m = cast(ubyte*)malloc(size); for (size_t i = 0; i < size; ++i) { m[i] = 0; }

нет дишного компилятора под рукой, но как-то так

А зачем кастить память в тип? По умолчанию она в null? И что будет если не в ubyte кастануть?

будет void*

а m[i] будет отсчитывать не i байт от начала, а i* sizeof(void*) байт, что равно 4 или 8 в зависимости от архитектуры

адресная арифметика коварна, не стоит пытаться использовать malloc не понимая её

эта та самя часть про которую говорят "C - сложный язык, там указатели"

ага, А потом видят что-то типа char** и в неокрепшем организме происходит паническая атака :)

ну это лучше чем char * const *, который даже С++ программисты читают вспотыкаясь

сложное заклинание :D

хотя это уже не про указатели, а про способ объявления типов. в D с этим гораздо проще благодаря транзитивности конста и возможности расстановки скобочек после const

const(char*) * всё же лучше выглядит

sizeof(void*) это равно размерности указателя для архитектуры? Просто я погуглил говорят что воид нулевой размерности

:) типа памяти не занимает :) можно харнить бесконечное количество указателей? :)

void это одно void* это другое

Второе указатель который можно к любому типу привести?

угу

Почему мы кастуем к указателю на тип, а не не просто к типу?

malloc возвращает указатель на выделенную память

ну у тебя есть дебагер? скасти к типу и спосмотри на результат)

я сейчас посоветую очень странную вещи, многие могут не согласится, но попробуй попрограммировать на Brainfuck. Уникальный язык из 8 операторов, который мне дал мне не просто понимание работы с памятью, а внутреннее ощущение работы с ней

стоит написать тривиальную работу с массивами на bf и C перестаёт быть сложным

Я дебаге тока в шарпе децл юзал

я сейчас посоветую очень странную вещи, многие могут не согласится, но попробуй попрограммировать на Brainfuck. Уникальный язык из 8 операторов, который мне дал мне не просто понимание работы с памятью, а внутреннее ощущение работы с ней

Да пусть на ассемблере, хотя бы для микроконтроллёров попишет

Или вот

да, асм тоже хорош для этих целей

для меня когда-то в bf был порог входа ниже. Да и фана больше

вундервафля? я написал строчек 20 кода, дебагер не осилил, брекпоинты в перегруженых операторах не ловяся, значения переменных не отображаются...

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

Dcd ни у кого с включенным пунто свитчером не падает?

В саблайме

Хотя у меня и без него падает...

Кто-нибудь писал одновременно синхронный и асинхронный код ? Это вообще реально?

Хочется чтобы как в go, без всяких yield он сам переключался на другие таски, если запущен асинхронно, и работал как обычно если синхронно.

я нечто подобное делал на С++. все функции пытаются найти общий event loop, если его нет, значит синхронный мод, а значит каждая внутри себя запускает луп и ждёт его завершения

кстати насчтё eventloop'ов, кто-нибудь юзал vibe'овский вместе с gtk-d ?

Я хочу написать библиотечку небольшую, и чтобы она работала универсально

vibed будет слишком толсто тянуть как зависимость, то есть это все должно опираться максимум на стандартную библиотеку.

А как без yield ведь непонятно как таск можно выполнять. Можно ли его запустить на квант времени или он долго будет что то молотить

единственный вариант, который я вижу - делать колбечный интерфейс. то есть на каждую операцию, которая может быть асинхронной либа должна звать колбек, который эту операцию выполняет. Ну и соответственно 2 адаптера - под vibe.d и без него. Можно колбеки заменить на объект, удовлетворяющий интерфейсу

Хочется чтобы как в go, без всяких yield он сам переключался на другие таски, если запущен асинхронно, и работал как обычно если синхронно.

Это надо писать рантайм(шедулер) и новую io библиотеку

В го же не магия, там время отдаётся другим горутинам во время операций с io и работой с каналами

Пичально, но нет, свой рантайм писать желания нету :)

а что должна делать библиотека? как много асинхронных операций надо в ней делать?

Да это апи клиент http

ну тогда вынеси в отдельный интерфейс запрос к http и проси объект его реализующий. вызов всегда выглядит синхронным, а то, что в vibe.d он там внутри пощёлкает корутинами не важно.

Чем загрузить потоки и файберы чтобы их под нагрузкой протестировать?

а что тебе дадут результаты теста?

Ну понять к примеру могу ли я 1000 потоков организовать или нет

И будут ли файберы тормозить если в них что то считать

1000 потоков это глупо

Просто тупо для изучения

Чтобы лучше разобраться

поток на ядро нужно расчитывать, иначе будет много издержек на переключения

ERROR: S client not available

Вот я это и хочу проверить

Мне не ясно сколько процентов времени будет на переключение уходить

файберы... что именно ты хочешь в них считать?

ускорения ты не получишь от того, что начал в 1000 файберов расчитывать 1000 разных частей задачи

можно просто все части запустить последовательно

а ускорение можно получить за счёт многопоточности

но вот только пока не упрёшься в кол-во ядер

дальше не будешь получать

Я хочу попробовать два кейса. В первом в файбере запускать вычисления. Во втором кучу тормозных операций типа доступа к БД

Тормозное подключение к БД это проблема БД, а не твоего кода

у тебя тут только 1 выбор, открыть в начале несоклько подлючений, и использовать их по кругу

Я понимаю. Я просто хочу искусственные ситуации обыграть чтобы на практике убедиться.

Кстати диспетчер задач память в хипе показывает только или еще и в стеке?

В доке ошибка? https://dlang.org/library/core/stdc/stdlib/malloc.html У меня оно тока uint ест

А там пишут что ulong

Или оно архитектурно зависимое? uint если я не туплю это 512mb?

uint это 32 бита

По логике должно хавать size_t

А он уже в свою очередь меняет размер от архитектуры

Олег, можно ли говорить, что в документации ошибка или это там какой-то более глубокий смысл? Просто я когда на это все смотрю думаю "может это просто я чего-то там не понимаю"

Ну посмотри исходник stdlib.d

void* malloc(size_t size);

auto m = cast(ubyte)malloc(100_000); for(size_t i; i<size_t.max; i++) { m[i] = 0; } Error: only one index allowed to index ubyte

Ты скастил указатель в ubyte?

Почему ты создаешь 100000 А бежишь по size.max

я так и не понял зачем его кастить...

у него же размер от архитектуры зависит

Влом объяснять, читай что такое указатель

ok

"указатель - переменная, содержимым которой является адрес другой переменной" Тоесть получается указатель всегда равен размеру той переменной на котоhe. он указывает?

Не другой переменной, а адресу памяти

ну в статье так написано...