Hello, World! 🎄
Snusmumriken
А ещё многомерный сишный массив можно тупо кастануть в одномерный, и работать с ним и так и так по желанию.
Snusmumriken
Может быть иначе, например в луашке. Где таблички раскиданы хз где по памяти, и расположение элементов многомерного массива в физической памяти нифига не линейное. Схожие вещи например в сишке с динамическими списками.
Luсky
можно наверное подрубить ffi и теребить сишные массивы быстро
Snusmumriken
Я тут видел товарища, который в ловке кастил ImageData в ffi-массив для резкого ускорения доступа без проверок границ и прочего. Скорость игры в жизнь выросла раз в двести, в сравнении с imagedata:mapPixel()
Hello, World! 🎄
А я вот все думаю про массивы, почему если массив в стеке то читать быстро, но изменять дорого. А если в куче поменять элементы быстро, а получить долго. Мне вот что не понятно, почему нельзя допустим сделать массив который хранит ссылку на каждый 1000 элемент и по на выходе получим и скорость записи и доступа Upd: Для тех кто не понял я говорю про массив на стеке и про массив в виде связного списка в heap
Snusmumriken
Это почти и называется кеш у цпу. Погугли схему работы кешей а ля l2/l3. А ещё про промахи кешей.
Snusmumriken
гдегде?
https://gist.github.com/pevzi/a55cca69dd925b449d728d5de11930b1
Snusmumriken
Шикос, 60fps на fullhd
Luсky
А вот кто подскажет по графену в игорях?
Luсky
Зделол я крч 2д-тир. Пестик от мышы шевелится, но как-то хреново по визуалу.
Snusmumriken
Покеж
Luсky
Щас
Snusmumriken
Потому что вообще можно через параллакс
Snusmumriken
Разбить пушку на несколько спрайтов разной удаленности, тип на слои нарезать, и сдвигать слои по движению мыши на коэффициент расстояния.
Luсky
Luсky
Instead-games https://instead-games.ru/game.php?ID=288
Snusmumriken
Точно та ссылка?
Luсky
да. это миниигра в нутрии
Snusmumriken
Не трогай нутрий!
Snusmumriken
Они пуськи
Lucky
В общем, пестик неприятно двигается. Стробоскопит. Хз, как описать.
Hello, World! 🎄
Шикос, 60fps на fullhd
У меня выше производительность, но я на glsl на GPU вычисления провожу: https://github.com/fhw12/game_of_life_lua/tree/main/glsl
Snusmumriken
Да, я помню что мы делали
Hello, World! 🎄
Snusmumriken
В чате ловки, мы делали разные версии GoL
Hello, World! 🎄
Ну да
Hello, World! 🎄
У меня там в репозитории на Lua и на glsl
Hello, World! 🎄
Надо бы на полупроводниках сразу сделать, хотя ладно делать нечего что-ли
Hello, World! 🎄
Кстати подскажите какие-нибудь полезные каналы по программированию на английском. Я смотрю: Fireship, 3DSage, CoderSpace. По математике: 3Blue1Brown Veritasium (там разный контент)
Aqendo
разве что Alek OS
Hello, World! 🎄
Hello, World! 🎄
Но это не на английском
Aqendo
Молодец
Aqendo
Но это не на английском
Тебе чтобы язык учить?
Aqendo
Mental Outlaw
Hello, World! 🎄
Чтобы слова изучать новые да и просто какой нибудь контент полезный найти
Hello, World! 🎄
Aqendo
Почему?
Hello, World! 🎄
Почему?
Я обычно смотрю на превью
Aqendo
Ну и зря
Aqendo
Человек разбирается в том, о чём говорит
Hello, World! 🎄
Если красиво оформлено
Hello, World! 🎄
Если красиво оформлено
То +, если нет то нет
Aqendo
лол
Aqendo
тебе нужен хороший фотошопер или хороший прогер?
Hello, World! 🎄
тебе нужен хороший фотошопер или хороший прогер?
Ещё на голос обращаю внимание, чтобы было приятно для звука
Aqendo
У него хорошая дикция
Aqendo
Ну как хочешь
Aqendo
Мне в кармане не прибавится в любом случае
Hello, World! 🎄
Может, там и полезная информация есть, но у меня выбор вкуса разный
Aqendo
Hello, World! 🎄
У него хорошая дикция
У него какая то политота
Hello, World! 🎄
Либо мне так показалось
Hello, World! 🎄
Где
На превью флаги
Hello, World! 🎄
Ладно, не важно
UtoECat
А я наверно там же не описал, что в heap массив мы реализуем в виде связного
😂 ну да, список ведь располагается так-же упорядоченно и линейно в памяти, как и массив (Нет) Если ты выделишь массив в куче - доступ будет к нему одинаков по скорости как и к массиву в стеке. Вот о чём я.
UtoECat
А я вот все думаю про массивы, почему если массив в стеке то читать быстро, но изменять дорого. А если в куче поменять элементы быстро, а получить долго. Мне вот что не понятно, почему нельзя допустим сделать массив который хранит ссылку на каждый 1000 элемент и по на выходе получим и скорость записи и доступа Upd: Для тех кто не понял я говорю про массив на стеке и про массив в виде связного списка в heap
Тогда поздравляю, ты изобрёл линейную хеш-мапу. Вот только надо юзать не каждый 1000-ный элемент, а хешировать ключ элемента, приводить хеш к размеру массива (можно операцией модуля, или, если размер массива хешмапы является степенью двойки, то (key&(size-1)) и вставлять в список по этому индексу. В лучшем случае "скорость" доступа будет О(1). Но... Мне кажется это лишним. Потомушо, как я понял, ты, какого-то лешего, пытаешься использовать список как массив, а так делать не надо. Так как ты, судя по всему, пишешь на сишке, то и юзай указатель на ноду в списке, а сам список используй в основном в переборе элементов и т.д и т.п. Но, вообще, зависит от задачи, да.
mb6ockatf
всегда думал, что синонимы
UtoECat
список это не массив о_0 ?
Нет конечно. Хотя всякие питоны и любят такое делать
mb6ockatf
Нет конечно. Хотя всякие питоны и любят такое делать
мне в питоне сказали "в сях массив, тут список". я годами так жил... неприятно; обманули получается
UtoECat
список это не массив о_0 ?
Список, это односвязная/двусвязная цепочка из нод, ака struct node { struct node* next; // указатель на следующий элемент int some_value; }; struct node* my_amazing_list = NULL; массив же - просто кусок памяти. char stack_array[512] = {0}; char *heap_array = malloc(512); ... free(heap_array);
UtoECat
а в чём разница?
В списке элемент под определённым индексом надо искать, ака проходиться по цепочке нод, пока не найдёшь нужный элемент. В массиве ты просто добавляешь к указателю начала массива смещение. Сипсок лучше массива только по аспектам вставки элемента куда хочешь, и удаления, а так-же в том, что адрес нод более-менее постоянен пока жив список, и никакая вставка/удаление не приведут к недействительным ссылкам. Вставка и удаление в массиве "быстра" только в конце. Если же надо расширить массив, то надо делать realloc() => все ссылки на предыдущую область памяти станут недействительны. (Попытка доступа к ней - в лучшем случае мусор, в худшем heap corruption и несанкционированное изменение участков памяти других объектов) Ну и, само собой, поиск элементов не по его порядку, а, например, по значению, будет не очень в обоих структурах. Тут лучше юзнуть хешмапу, как я писал выше