Реально t.reserve(count); все разреливает

Хм...

дефолтные не при чем, см. число живых/живших

Ну оно как-ты говоришь

Он выделяет новую память и сразу, видимо, резервирует доп. элемент, в который вставляет после мой элемент

И из-за этого создается лишний элемент

больше 100 сразу 125 выделяет )

Значит нужно всегда reserve делать, если знаешь новый размер...

ты так дойдешь до статических массивов и ручным управлением памятью скоро :)

)))

Так даже перфоменс выше

Там, конечно, очень маленький прирост, но есть

ты так дойдешь до статических массивов и ручным управлением памятью скоро :)

Ты знаешь, если ты делаешь какую-то либу, которая хорошо работает, то в чем проблема, что она без GC там работает?

Пусть себе как хочет это делает, если автор дает 100% горантию, что он знает, что он делает)

Не вижу в этом ничего плохого, пусть управляет руками той памятью, которой оперирует его либа

ты так дойдешь до статических массивов и ручным управлением памятью скоро :)

А на счет извращения, вот посмотри: /mnt/c/docker$ time ./test.exe 10000000 10000000 10000381 END real 0m0.302s user 0m0.000s sys 0m0.000s

Найди "две" странности)))

10000381 это capacity?

да

А я тут обнаружил, что винда рулит, а линукс отстой. Если пишешь на D числодробилку. Ибо LDC на винде творит чудеса. А в линуксе та же версия LDC не творит чудеса. Вот простой тест с вычислениями синусов и косинусов: https://gist.github.com/thedeemon/aba0ecc2607d781ebfe81c9fef144704 В линуксе LDC лишь процентов на 10 быстрее DMD. А на винде разница в 4.4 раза! Линуксовый бинарник работает 4.92 секунды. Виндовый бинарник, собранный той же версией LDC, - 1.10 секунды!

Правда меня растроил факт, что кондишн чек в форе не кешируется :(

Тут это микробенчмарк, а я столкнулся на реальной программе, где много синусов и косинусов считалось, помимо прочей вещественной арифметики. Там виндовый бинарник где-то вдвое быстрее линуксового оказался, если компилить LDC. А если компилять DMD, то разницы практически нет. На винде LDC-шный вариант большой проги в 6 раз быстрее DMD-шного. А на линуксе лишь в 2-3 раза быстрее, что тоже хорошо, но двое медленнее винды. Причем можно через Wine виндовый бинарник запустить, и он будет вдвое быстрее нативного линуксового. Такие вот чудеса. Похоже, дело в том, какой рантайм используется, реализация тригонометрии в виндовом LDC супершустрая.

Тут это микробенчмарк, а я столкнулся на реальной программе, где много синусов и косинусов считалось, помимо прочей вещественной арифметики. Там виндовый бинарник где-то вдвое быстрее линуксового оказался, если компилить LDC. А если компилять DMD, то разницы практически нет. На винде LDC-шный вариант большой проги в 6 раз быстрее DMD-шного. А на линуксе лишь в 2-3 раза быстрее, что тоже хорошо, но двое медленнее винды. Причем можно через Wine виндовый бинарник запустить, и он будет вдвое быстрее нативного линуксового. Такие вот чудеса. Похоже, дело в том, какой рантайм используется, реализация тригонометрии в виндовом LDC супершустрая.

/mnt/c/docker$ time ./test.exe 10000000

А я его без вайна запускаю)))))))))

в какой системе?

/mnt/c$ uname Linux

lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.4 LTS Release: 16.04 Codename: xenial

а как это работает без вайна?

))))

В винду интегрировали же ядро линухи)))

Вот просто запускаю баш и фигашу)

Можно как линуксовые, так и виндовые запускать

ну так это винда тогда

С одной стороны да, но я могу использовать оба ядра

Вот я сейчас компилю под винду, а запускаю с линухи...

Извращение еще то)))

for(uint i=0; i<to!int(args[1]); ++i){ В этом случаи кондишн чек будет вычисляться каждый раз :(

Думал что компилятор такое оптимизирует

Но нет

for(uint i=0; i<to!int(args[1]); ++i){ В этом случаи кондишн чек будет вычисляться каждый раз :(

А как определил это?

Сделал так: uint count = to!int(args[1]); for(uint i=0; i<count; ++i){

И это почти в 2 раза быстрее работает

при переданом 10М ввиде параметра

/mnt/c/docker$ time ./test.exe 10000000 10000000 10000381 END real 0m0.574s user 0m0.000s sys 0m0.000s /mnt/c/docker$ time ./test.exe 10000000 10000000 10000381 END real 0m0.303s user 0m0.000s sys 0m0.000s

ну так там вызов ф-ии, и компилятор не знает, вдруг она там на каждом вызове что-то важное и новое делает.

conv.to поди не помечена как pure

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

А если помечена, то что?

в идеале, компилятор вызов чистой ф-ии мог бы вынести из цикла

Но в том же LDC оптимизатор по сути сишный, он про чистые ф-ии не знает

ну он еще должен чекнуть что ты не поменяешь args[1]

да, тоже важно

Тоже верно

Ну, так или иначе - нужно выносить в переменную

64 нужно в первую очередь для работы с большими объёмами данных. Если их нет, то и толку может не быть.

для линукса есть хак чтобы юзать на 64битной системе 32битные указатели

точнее не хак а АПИ

сегодня прогу для stm программатора под линуху нашли

stlink?

а есть ли программа, которая извлекает старую прошивку, сохраняет ее в некой базе (но без дубликатов) перед заливкой новой прошивки?

конечно, скриптик напистаь и всё

stlink?

ну да

ну да

дык это, openocd

дык это, openocd

OpenOCD? Open Obsessive-Compulsive Disorder?

apt-cache search openocd openocd - открытый внутрисхемный отладчик для систем ARM и MIPS

/// human-readable IP adress @property const (char)* addressStringz() { char[INET6_ADDRSTRLEN+1] str; return inet_ntop(AF_INET6, &address, str.ptr, str.length); }

Что если я верну указатель на массив char который был выделен на стеке во время работы функции. Он ведь не успеет сразу очиститься? =)

опасненько

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

Что если я верну указатель на массив char который был выделен на стеке во время работы функции. Он ведь не успеет сразу очиститься? =)

хранил бы string и всё

ERROR: S client not available

на спичках экономишь

на спичках экономишь

Ровно этим я люто и занимаюсь

Надо понять, можно ли выделять 46 байт на стеке только в случае ошибки или придется делать это каждый раз

точнее не хак а АПИ

https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa366527(v=vs.85).aspx https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa366796(v=vs.85).aspx -и в винде найдётся

Надо понять, можно ли выделять 46 байт на стеке только в случае ошибки или придется делать это каждый раз

что за дичь?)

может просто передавать в функцию выделенную память?

ну вот хз только насчёт его стабильности. как по мне так идея годная. у меня в разработке нет софта который требует больше 4гигов RAM

как на Си?

выделять - дораха

)

выделять - дораха

а если на стеке выделить?

тогда по входу там мусор будет же

char[46] buffer; auto result = myFunc(buffer[]);

да и вообще не 46, а 1024

чтобы любую строку можно было напечатать

и срез возвращать

Как то странно размер бинарника генерится. Был 28495 байт, а добавил эту распечтаку строк в двух местах и размер стал 32918 ?

Выравнивается по 4к чтоли

Ладно втопку, распечатаю просто 16-байтный адрес в лог, вот еще за пользователей переводить в human readable формат.

перевод уже у нас встроен давно

велосипедишь

только не в betterC ;)

только не в betterC ;)

чем идея с передачей выделенной памяти не нравится?

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

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

драститя

всё нормально будет, только не кусок буфера возвращай а это уже почти что честный аллокатор получится самобельный

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

хорошо, допустим у тебя этот метод — метод структуры

ты же можешь буфер хранить в самой структуре

и просто учитывать что он перезаписывается

а возвращать его срез

Статически?

ну да