Pavel
А если и свопа не хватает для всей области которую хотят зарезервировать? Просто я удивлен, почему это критично для приложения или же причина что нет обработки этого эксепшена в приложении...
Pavel
Я думал что резервация это лишь как бы метка что вот такой набор адресов не занимать
Yura
честно, на 100% я не знаю, но думаю, что зависит тупо от ОС... а память в куче выделяетсяГ?
Pavel
Нет
Yura
НА СТЕКЕ???????!?!?!?!?!?
Pavel
На стеке вродь не может много резервировать, там пару мегобайтов выделенно на каждый стек
Pavel
Я не смотрел куда резервируется, но сделаю это. Спасибо за наводку
JeisonWi
Бедные индейцы
Pavel
Нашел статью для чайников и понял. https://blogs.msdn.microsoft.com/tess/2006/09/06/net-memory-usage-a-restaurant-analogy/
Aiwan \ (•◡•) / _bot
не уж то сессия?
­
У меня самого через 4 часа заSHITа...
­
Ну что, держите там пальцы и щупальца за меня. Уже совсем скоро я буду ВКР зачищать.
kitsu
kernel debugger will help you
kitsu
только в windbg тыкался для линупса тоже что-то подобное в гугле должно быть
JeisonWi
Kgdb
Viktor
И kdb на macOS
Viktor
А вообще проще исходники посмотреть
Viktor
А вообще проще исходники посмотреть
в Linux системные вызовы определяются через макро SYSCALL_DEFINE{N}, где N -- число агрументов
Viktor
у write их три
Viktor
что позволяет довольно быстро найти файл fs/read_write.c
Viktor
А именно вот эту строчку в нем https://elixir.bootlin.com/linux/v4.17.4/source/fs/read_write.c#L607
Viktor
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf, size_t, count) { return ksys_write(fd, buf, count); }
Viktor
а вот и ksys_write, который тоже довольно просто найти через lxr: https://elixir.bootlin.com/linux/v4.17.4/source/fs/read_write.c#L591
Viktor
дальше думаю сам найдешь
Viktor
вот еще в тему: https://0xax.gitbooks.io/linux-insides/SysCall/linux-syscall-5.html
Viktor
ну и конечно же "debugging linux kernel" дает довольно много результатов
Viktor
https://www.kernel.org/doc/html/v4.17/dev-tools/gdb-kernel-debugging.html
Viktor
https://elinux.org/Debugging_The_Linux_Kernel_Using_Gdb
Viktor
https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks
Viktor
https://medium.com/square-corner-blog/a-short-guide-to-kernel-debugging-e6fdbe7bfcdf
Viktor
Google твой друг, @morph0
Pavlo
Кто-нить знает есть ли gdb-multiarch под Windows систему?
dukeBarman
возможно только через wsl
Pavlo
Мда, вариант. Спасибо. Хорошо, что десятка позволяет такие вещи)
dukeBarman
👍
Anonymous
MSVC 19 2017 mov eax, DWORD PTR [rbp-4] inc eax mov DWORD PTR [rbp-4], eax GCC 8.1 add DWORD PTR [rbp-4], 1 А теперь вопрос. Второе будет сильно быстрее первого?
Anonymous
вырезка из Си кода: case 0: length++; break;
Anonymous
я просто думаю, что ADD address, value; тоже будет также выгружать данные из ОЗУ, потом изменять, а после загружать обратно. Вот и стало интересно, а что собсна эффективнее
Anonymous
было бы прикольно, если бы для таких простейших операций в ОЗУ встроили АЛУ, который смог был складывать, вычитать ну и побитовые операторы выполнять.
Anonymous
ну это так, выдумки конешн
Anonymous
Хотя че я, можно через счетчик таков чекнуть, лол
Vladimir
какие ключи оптимизации стояли?
Anonymous
Vladimir
А разве так можно?
00000000 FF45FC inc dword [rbp-0x4]
Vladimir
вообще в 64-битном режиме существуют только r/m версии команд inc/dec
Vladimir
старые однобайтовые ушли под REX
Anonymous
мне просто как-то надо было чекнуть опкоды, нашел какой-то онлайн компилятор под x86-32 и он таки не смог inc address. Я тогда не знал, что так можно, просто предполагал, а после того как попробовал, подумал, что нельзя.
Anonymous
ну ладно, буду знать, спасибо)
Anonymous
старые однобайтовые ушли под REX
Апо части скорости какие мысли?
Vladimir
Апо части скорости какие мысли?
Это надо знать внутреннее устройство проца, как он там преобразует команды. Мы имеем три микрокоманды во всех случаях: fetch, inc, store. Если принять во внимание спекулятивное исполнение, то тут становится понятно только то, что нихера не понятно ) В общем случае скорость не должна сильно отличаться
Vladimir
Можно взять увесистый томик Intel optimization manual или как его там. Хотя не факт, что там описаны все нюансы
Vladimir
Точнее факт, что там НЕ описаны все нюансы )
Vladimir
Вот раньше хорошо было - для всех команд писались такты, и можно было понять, что работает быстрее, а что - медленнее
Vladimir
Это ты про всякие старые добрые 8080?)
да вроде даже и в 80386 было
Anonymous
Ладно, я тогда ради интереса попробую измерить кол-во тактов. Уж больно интересно. А GCC с флагом -O3 сразу возвращает eax, с изменением значения через lea
JeisonWi
Ладно, я тогда ради интереса попробую измерить кол-во тактов. Уж больно интересно. А GCC с флагом -O3 сразу возвращает eax, с изменением значения через lea
Такты не очень актуальны с параллельным выполнением, кэшированием и предсказанием ветвлений и данных
Anonymous
как все сложно с этими x86. Походу я пошел в MIPS/ARM :(
Vladimir
как все сложно с этими x86. Походу я пошел в MIPS/ARM :(
Как будто там нет кэшей и спекулятивного исполнения
Anonymous
не знаю, может я еще неопытен, но x86 для меня уже выглядит как ЖИРНЫЙ швейцарский нож, которым так сложно пользоваться. Да еще и с кучей рудиментов.
Vladimir
а в MIPS ещё такая срань как delay slots
Anonymous
это как понимать?
Anonymous
это какое-то асинхронное поведение?
Vladimir
задержка слота?
после команды перехода можно поставить ещё одну команду, которая выполнится перед переходом
Vladimir
для простоты это может быть nop. но оптимальнее туда пихнуть какую-нть команду
Anonymous
хм, понял, да это дичь какая-то
Vladimir
Anonymous
Да, но концепция RISK`ов не говорит о том, что нужно творить подобную дичь
Vladimir
Концепция RISC - чем проще, тем лучше. Часто внутренности на виду, как dealy slots в MIPS или смещение на 2 команды в ARM