Общие вопросы и приёмы эффективного программирования на BASIC

Вот как создать кнопку:

0

Сообщение от The trick Ну так локальные массивы к этому и относятся.

Если массив используется только этой конкретной функцией. А если кем-то еще, то нужно держать её где-то за её пределами. Если же требуется рекурсия тормоза буду просто космическими.

Сообщение от The trick И что? Как секция data поможет с локальными переменными функции (которые также могу быть массивами)?

Размещать их в статик.

0

Сообщение от CoderHuligan Крис Касперски писал, цитата, - "за размещение массивов в стеке давно пора расстреливать".

Не нужно искажать цитаты:

Сообщение от Крис Касперски ака мыщъх За бездумное размещение массивов в стеке уже давно пора расстреливать.

https://www.evilfingers.com/pu... ks-1Ch.pdf

Добавлено через 6 минут

Сообщение от CoderHuligan Если массив используется только этой конкретной функцией. А если кем-то еще, то нужно держать её где-то за её пределами. Если же требуется рекурсия тормоза буду просто космическими.

Какие тормоза, ты о чем вообще? Возможно мы про разные вещи говорим. У тебя есть функция которая имеет локальный массив в стеке (к примеру MAX_PATH байт для пути). Мы можем отправлять этот массив в любые функции вызываемые ею. static массив - это глобальный массив, он один и любая рекурсия будет перезаписывать в нем данные + еще если потоки будут то вообще там каша будет.

Сообщение от CoderHuligan Размещать их в статик.

Нет, локальные и статик переменные это вообще две разные сущности которые используются для разных целей. Уже выше написал чем статик массивы обернутся.

0

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

Так и не говорил что куча идеальна в любых ситуациях. Это ты ставишь кучу в такие условия, когда
она априори неэффективна. Всегда толдычу только об одном, об архитектуре программы. Меня
по большому счёту вся эта возьня с микронюансами не интересует настолько, чтобы утонуть в ней,
потому что знаю простую вещь, что правильно построенная архитектура(а это нефиговый такой анализ)
не даст проге работать как говно. Потому что в ней как раз и закладываются все эти будущие
узкие места, где завести память, где освободить, что и где обсчитать. Как бы никогда не сяду
прямолинейно кодить прогу потому что мол много мозгов и готов прошибать в прямом смысле стены.
А на форуме дело больше в другом, ты вот даёшь людям на откуп дубину, которой они себя потом зашибут.
Стек это реально НУ и очень тонкая работа. А какие-то строки им заводить, ну это не знаю.
В задачах где реально там циклы и надо мелкими кусками заводить много, может и будет прирост,
большие объёмы нужны чтобы этот прирост был ощутим, в реальных ситуациях такого нет
и почти всегда можно обойтись хепом, понять где завести заранее, чтобы сразу все потребности накрыть.
Т.е. как-бы аккуратно все эти штуки со стеком, а не так чтобы мол вот вам стек он работает быстрее
и мол юзайте, да там неофиты такого нагородят, потом ещё из их голов это не вытравишь никак.
да и как бы то что ты показал через тип - предполагаю в FB такое тоже есть, и пока он сам это пасёт
мне вот честное слово пофигу, я понимаю что это не топовый компиль и скоростные характеристики
меня устраивают.

0

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

Работает в финальной версии и с оптимизацией -O0 (то есть без оптимизаций)
В отладочной версии у меня падает, там кто‐то другой теребит её rsp.
Ссылка на гитхаб https://github.com/zamabuvaraeu/test
(для x86 версии ставьте gcc)

Миниатюры

 

Вложения

trunk.zip (67.7 Кб, 0 просмотров)

0

На скриншоте код функции __alloca из библиотеки ГЦЦ.

0

Сообщение от Quiet Snow Это ты ставишь кучу в такие условия, когда она априори неэффективна.

Не было такого, это ты про стек так говоришь. Про стек я написал что в некоторых сценариях он намного эффективней кучи. Все.
Вот мое оригинальное сообщение:

Не нужно освобождать такую память + выделение такой памяти намного быстрее. Есть конечно и недостатки, такие как ограниченный размер + нельзя возвращать такую память из функции, ну еще некоторые ограничения. Но вывыделение памяти в стеке может пригодится для повышения эффективности кода.

Сообщение от Quiet Snow Т.е. как-бы аккуратно все эти штуки со стеком, а не так чтобы мол вот вам стек он работает быстрее и мол юзайте, да там неофиты такого нагородят, потом ещё из их голов это не вытравишь никак.

Да сишники испокон веков юзают массивы в стеке, всякие char result[80] и т.п.

0

Сообщение от The trick изначально динамический размер (в отличии от массивов со статическим размером где размер задается константой), я не писал что его можно изменить.

Вспомни, говорил, что будут нюансы, не просто так говорил. Всплывают потихоньку.

Сообщение от The trick но так и не привел толком ничего

А что я должен привести? Описал подход к оптимизации, этот подход применял в 2004 году,
когда писал текстурирование на ассемблере. Там было около 10 версий текстур +/-, на это было убито
в общей сложности полтора года, даже больше. Это не сел и нахерачил за 5 минут пример,
который показывает лишь базовый принцип и не показывает где зарыта собака.
С тех пор много воды утекло, уже асм давно забросил, да и те навыки слабо под винду канают,
ибо x64 уже во всю, со своими 15-ю регистрами. Дай мне тогда 15 толстенных 64 битных регистра,
да я бы озверел с такой халявы. А в то время на портах например обычная горизониальная линия
быстрее работала, пример - библиотека XLib для Паскаля.

Сообщение от The trick Про стек я написал что в некоторых сценариях он намного эффективней кучи. Все.

Ну тогда я без вопросов. Так оно всё так и есть. Для меня просто слово эффективность
не может быть фиктивным, привык чувствовать эффективность, в прямом смысле слова.
Т.е. если это 5% - то уже чувствую, но меня это не сильно волнует, если 10-15% - то как-бы
на это обращу внимание, просто отложу в долгий ящик, а если 20-50% - то это делаю сразу.
Что-то менее значимое чем 5%, мной даже не рассматривается, потому что архитектура,
грамотный алгоритм и формализация совместно дают кратные прибавки и лучше потратить время
на модернизирование этих характеристик, а технические кодерские нюансы дают лишь
относительно небольшой прирост, ну если только это не SIMD или явные такие штуки типа
табличной оптимизации, но это тоже скорее больше архитектура, просто в более мелком
масштабе, на уровне конкретного алгоритма, конкретной функции.

0

Сообщение от Quiet Snow Вспомни, говорил, что будут нюансы, не просто так говорил. Всплывают потихоньку.

Ну вообще-то я изначально об этом писал:

Сообщение от The trick Ну динамическую строку, теоретически можно и в стеке выделить (просто расположить ее в самом конце локальных переменных), правда так почти никто не делает. В стеке память как правило выделяется для фиксированных данных.

Сообщение от Quiet Snow А что я должен привести?

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

0

Сообщение от The trick Ты говоришь о каких-то мифических сложностях при выделении

Не при выделении, а о дилемме во время оптимизации. И да я не курил эти компиляторы на предмет
того как они решают вопрос долгосрочности таких выделений, потому что в моих реалиях, когда кодил,
использовал стек для сохранения переменных внутри циклов, счётчиков и того что вытеснялось на время,
т.е. было не нужным для обсчёта. Уже описал этот процесс, при котором "регистры все заняты"
вроде бы должно быть понятно почему они заняты, причём, включая bp(ebp), и ситуация: ты внутри
цикла, идёт заход в ещё цикл, cx надо сохранять, куда? Стек ты подвинул, положишь что-то сверху,
ниже заведённое уже не ликвидировать, пока не вернёшься, возвращать указатель обратно тоже надо,
иначе прога дальше вытащит не свои данные(адрес возврата например на ret) и придёт кирдык.
А так то да, правил никаких, можно отдать ценнейший bp на адресацию и складывать регистры
в любую доступную память(локальную или глобальную, первое проще когда пишешь машинные коды,
второе, когда этим занимается компилятор).
Так ли всё это мифично на самом деле?

0

Сообщение от Quiet Snow Так ли всё это мифично на самом деле?

Да. Локальные переменные в случае с динамическим выделением памяти в стеке адресуются к примеру через EBP и никаких проблем о которых ты писал. Большинство компиляторов так и делают. Регистр EBP так и называется - Stack Base pointer register. Все проблемы о которых ты написал выше - ты создал себе сам.

0

Сообщение от The trick Размер массива имеют изначально динамический размер

Размер массива вычисляется во время работы программы, но после этого его размер не меняется. Каждый раз создается новый массив заданного размера.

0

Сообщение от locm Размер массива вычисляется во время работы программы

Вот именно, вычисляется, а не задается константой. Это позволяет выделять динамически буфера для временных строк (к примеру результат вызова функции lstrlen).

0

Сообщение от The trick Все проблемы о которых ты написал выше - ты создал себе сам.

Я не кодер хулиган, пачка реализованных проектов говорит сама за себя, проблем никогда не было
даже на системе, где всей этой памяти копейки, о чём пишу и делюсь своими опытом с другими.
Просто говорю, что не стал бы использовать это на каждый чих, в реале, в 99% случаев оно не даст никакой
видимой выгоды, только в каких-то редких случаях. Со строками в тех кейзах, в которых их обычно используют
- точно не даст. А разного рода геморроя может добавить порядком, особенно неопытным программистам,
которые не знают с какой стороны к этому самому стеку подойти. До сих пор уверен, что ты не осознаёшь
всю глубину проблемы, почему всё это пишу. Одно дело читать код, генеренный компилятором и совсем
другое писать этот код самому.
И когда BASIC программист увидит такой код, он будет долго ломать бошку, мол, зачем же его сделали,
если там не будет комментария. Повторюсь, оптимизирую только тогда, когда это необходимо,
т.е. когда есть явная в том потребность. Когда потребности нет в асм не лезу и не вижу смысла лезть.
И типовой кейз - это алгоритмы, а не просто потому что кто-то посчитал, что строки работают
недостаточно быстро и диалекты мол писали какие-то левые тюфяки, которые ни в зуб ногой.
Всё там работает отлично. И если внезапно начинаются проблемы - это как раз первый звоночек и
прямое свидетельство того, что архитектура проги сделана через задницу и не уделено внимание
самому главному, это также означает, что если вовремя эту работу не переделать - проблем станет больше.

Сообщение от The trick Регистр EBP так и называется - Stack Base pointer register.

Знаю как он называется и для чего используется обычно (адресация локальных переменных).
Также знаю, что операция регистр регистр выполняется быстрее, чем регистр память.
Во всяком случае так было раньше и с этим никто не спорил, это был серьёзный
ресурс для оптимизации, наряду с выравниванием, с табличкой и другими, уже более сложными.

0

Сообщение от The trick Это позволяет выделять динамически буфера для временных строк

Речь шла об изменении размера уже выделенного буфера в стеке. Просто выделить не меняя размер в дальнейшем проблем не составляет.

0

Сообщение от Quiet Snow До сих пор уверен, что ты не осознаёшь всю глубину проблемы, почему всё это пишу.

Потому что никакой особой проблемы нет. Я реверсил кучу кода и прекрасно знаю как работают вещи в реальности.

Сообщение от locm Речь шла об изменении размера уже выделенного буфера в стеке.

Я ни о чем таком не говорил, вот мое сообщение:

Сообщение от The trick Не нужно освобождать такую память + выделение такой памяти намного быстрее. Есть конечно и недостатки, такие как ограниченный размер + нельзя возвращать такую память из функции, ну еще некоторые ограничения. Но вывыделение памяти в стеке может пригодится для повышения эффективности кода.

Про изменение размера уже выделенного буфера я только написал:

Сообщение от The trick Ну динамическую строку, теоретически можно и в стеке выделить (просто расположить ее в самом конце локальных переменных), правда так почти никто не делает. В стеке память как правило выделяется для фиксированных данных.

0

Сообщение от Quiet Snow Это ты ставишь кучу в такие условия, когда она априори неэффективна

Давайте сравним выделение памяти в куче и стэке.
1. Память в стэке выделается одной командой процессора.
2. Память в куче — это вызов функции, где проверяются всякие списки, свободные места, происходит вход в критическую секцию и так далее.
3. Данные в стэке лежат прямо вместе с кодом и легко умещаются в кеш процессора.
4. Данные в куче лежат неизвестно по каким адресам, и чтобы до них добраться, процессору может потребоваться сбросить кеш.
Есть есть ли ещё сомнения, почему куча априори неэффективна?

0

Сообщение от Замабувараев Память в стэке выделается одной командой процессора.

Примера динамической строки или массива в стеке вы так не выложили.

Сообщение от Замабувараев Данные в стэке лежат прямо вместе с кодом и легко умещаются в кеш процессора.

Как одно с другим связанно? Тем боле что стек находится не в той же области памяти что код.

Сообщение от Замабувараев Есть есть ли ещё сомнения, почему куча априори неэффективна?

Ждем примеры эффективного использования стека для хранения локальных динамических строк и массивов.

0

Сообщение от locm динамической строки или массива в стеке

Функция realloc:

Описание Функция realloc выполняет перераспределение блоков памяти. Размер блока памяти, на который ссылается параметр ptrmem изменяется на size байтов. Блок памяти может уменьшаться или увеличиваться в размере. Эта функция может перемещать блок памяти на новое место, в этом случае функция возвращает указатель на новое место в памяти. Содержание блока памяти сохраняется даже если новый блок имеет меньший размер, чем старый. Отбрасываются только те данные, которые не вместились в новый блок. Если новое значение size больше старого, то содержимое вновь выделенной памяти будет неопределенным. Возвращаемое значение Указатель на перераспределенный блок памяти, который может быть либо таким же, как аргумент ptrmem или ссылаться на новое место.

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

0

Сообщение от locm Примера динамической строки или массива в стеке вы так не выложили.

Динамическую строку можно выделить в стеке, Замабувараев написал уже:

Сообщение от Замабувараев realloc тривиально заменяется на связку alloca + копирование + freea.

только freea тут не нужно. Только такой случай уже не является таким оптимальным как тот о котором я пишу. Строки в стеке эффективнее выделять когда размер не будет изменен после выделения, т.е. это очень эффективно в сценариях типа таких:
т.е. когда размер строки неизвестен на момент компиляции, но его можно вычислить в рантайме динамически (к примеру вывод каких-то данных на консоль или запись форматированной строки в файли или отправка по сети, в общем много сценариев можно придумать). Ничего не мешает конечно сделать и изменяемый размер, только стек будет расти для каждого изменения и это уже не так оптимально, хотя все-равно в некоторых случаях это будет эффективнее чем память в хипе. Если это и делать в компиляторе то нужно явно этот момент указывать - получишь настоящие динамические строки.

Сообщение от locm Тем боле что стек находится не в той же области памяти что код.

Ну это не отменяет того что данные в кэше будут. Более того стековая память с большей вероятностью будет кэширована нежели какая-то левая, т.к. она непосредственно используется процессором чаще.

0

0