мне, я поржал. видос есть ниже
Я посмотрел его
Hello, World! 🎄
Snusmumriken
А ещё многомерный сишный массив можно тупо кастануть в одномерный, и работать с ним и так и так по желанию.
Hello, World! 🎄
Snusmumriken
Может быть иначе, например в луашке.
Где таблички раскиданы хз где по памяти, и расположение элементов многомерного массива в физической памяти нифига не линейное.
Схожие вещи например в сишке с динамическими списками.
Luсky
можно наверное подрубить ffi и теребить сишные массивы быстро
Hello, World! 🎄
Snusmumriken
Я тут видел товарища, который в ловке кастил ImageData в ffi-массив для резкого ускорения доступа без проверок границ и прочего.
Скорость игры в жизнь выросла раз в двести, в сравнении с imagedata:mapPixel()
Hello, World! 🎄
А я вот все думаю про массивы, почему если массив в стеке то читать быстро, но изменять дорого. А если в куче поменять элементы быстро, а получить долго.
Мне вот что не понятно, почему нельзя допустим сделать массив который хранит ссылку на каждый 1000 элемент и по на выходе получим и скорость записи и доступа
Upd: Для тех кто не понял я говорю про массив на стеке и про массив в виде связного списка в heap
Snusmumriken
Это почти и называется кеш у цпу.
Погугли схему работы кешей а ля l2/l3.
А ещё про промахи кешей.
Snusmumriken
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! 🎄
Snusmumriken
Да, я помню что мы делали
Snusmumriken
В чате ловки, мы делали разные версии GoL
Hello, World! 🎄
Ну да
Hello, World! 🎄
У меня там в репозитории на Lua и на glsl
Hello, World! 🎄
Надо бы на полупроводниках сразу сделать, хотя ладно делать нечего что-ли
Hello, World! 🎄
Кстати подскажите какие-нибудь полезные каналы по программированию на английском.
Я смотрю:
Fireship, 3DSage, CoderSpace.
По математике: 3Blue1Brown
Veritasium (там разный контент)
Hello, World! 🎄
Кстати подскажите какие-нибудь полезные каналы по программированию на английском.
Я смотрю:
Fireship, 3DSage, CoderSpace.
По математике: 3Blue1Brown
Veritasium (там разный контент)
Если конечно у вас есть какие-то интересные каналы
Aqendo
разве что Alek OS
Hello, World! 🎄
Но это не на английском
Aqendo
Молодец
Aqendo
Mental Outlaw
Hello, World! 🎄
Чтобы слова изучать новые да и просто какой нибудь контент полезный найти
Aqendo
Почему?
Aqendo
Ну и зря
Aqendo
Человек разбирается в том, о чём говорит
Hello, World! 🎄
Если красиво оформлено
Aqendo
лол
Aqendo
тебе нужен хороший фотошопер или хороший прогер?
Hello, World! 🎄
тебе нужен хороший фотошопер или хороший прогер?
Ещё на голос обращаю внимание, чтобы было приятно для звука
Aqendo
У него хорошая дикция
Aqendo
Ну как хочешь
Aqendo
Мне в кармане не прибавится в любом случае
Hello, World! 🎄
Может, там и полезная информация есть, но у меня выбор вкуса разный
Aqendo
Hello, World! 🎄
Либо мне так показалось
UtoECat
А я вот все думаю про массивы, почему если массив в стеке то читать быстро, но изменять дорого. А если в куче поменять элементы быстро, а получить долго.
Мне вот что не понятно, почему нельзя допустим сделать массив который хранит ссылку на каждый 1000 элемент и по на выходе получим и скорость записи и доступа
Upd: Для тех кто не понял я говорю про массив на стеке и про массив в виде связного списка в heap
Эммм... Что?
Оно одинаково по скорости должно быть.
Вероятно, ты с алгоритмами там что-то намудрил. Вот оно у тебя и медленно.
Hello, World! 🎄
Hello, World! 🎄
Ладно, не важно
Hello, World! 🎄
Эммм... Что?
Оно одинаково по скорости должно быть.
Вероятно, ты с алгоритмами там что-то намудрил. Вот оно у тебя и медленно.
Вот я тебе на хабр нашел про массив и связный список: https://habr.com/ru/articles/339656/
Hello, World! 🎄
Эммм... Что?
Оно одинаково по скорости должно быть.
Вероятно, ты с алгоритмами там что-то намудрил. Вот оно у тебя и медленно.
А я наверно там же не описал, что в heap массив мы реализуем в виде связного
UtoECat
А я наверно там же не описал, что в heap массив мы реализуем в виде связного
😂 ну да, список ведь располагается так-же упорядоченно и линейно в памяти, как и массив (Нет)
Если ты выделишь массив в куче - доступ будет к нему одинаков по скорости как и к массиву в стеке. Вот о чём я.
UtoECat
А я вот все думаю про массивы, почему если массив в стеке то читать быстро, но изменять дорого. А если в куче поменять элементы быстро, а получить долго.
Мне вот что не понятно, почему нельзя допустим сделать массив который хранит ссылку на каждый 1000 элемент и по на выходе получим и скорость записи и доступа
Upd: Для тех кто не понял я говорю про массив на стеке и про массив в виде связного списка в heap
Тогда поздравляю, ты изобрёл линейную хеш-мапу.
Вот только надо юзать не каждый 1000-ный элемент, а хешировать ключ элемента, приводить хеш к размеру массива (можно операцией модуля, или, если размер массива хешмапы является степенью двойки, то (key&(size-1)) и вставлять в список по этому индексу.
В лучшем случае "скорость" доступа будет О(1).
Но... Мне кажется это лишним.
Потомушо, как я понял, ты, какого-то лешего, пытаешься использовать список как массив, а так делать не надо.
Так как ты, судя по всему, пишешь на сишке, то и юзай указатель на ноду в списке, а сам список используй в основном в переборе элементов и т.д и т.п.
Но, вообще, зависит от задачи, да.
mb6ockatf
всегда думал, что синонимы
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);
mb6ockatf
Список, это односвязная/двусвязная цепочка из нод, ака
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 и несанкционированное изменение участков памяти других объектов)
Ну и, само собой, поиск элементов не по его порядку, а, например, по значению, будет не очень в обоих структурах. Тут лучше юзнуть хешмапу, как я писал выше