Молодой человек, у вас память по штанине потекла
Пока разработчики разрабатывают, а программисты программируют, байтоебы убирают мусор.
Именно поэтому я использую линейные типы.
Я учился эффективному управлению памятью 23 долгих года, а вы можете познать эту науку всего за 6.5 часа... Секреты создания профессиональных эффективных приложений с использованием линейных типов, о которых вам нигде не расскажут в более доступной форме, чем здесь (да и вообще не расскажут). 13 видеоуроков о том, КАК делать, а не ЧТО делать.
Прогресс не стоит на месте. Сегодня обычные генерационные сборщики мусора уступают место более эффективным, наглядным и результативным методикам.
Благодаря технологии линейных типов, сегодня Вы можете выделить память и начать освобождать ее на практике в три раза быстрее своего конкурента, который будет пыхтеть над malloc'ами и рвать на себе волосы от того, что не может добиться нужного результата.
Если Вы попали на данную страницу, то скорее всего Вы хотите научиться создавать уникальные указатели, либо усовершенствовать свой свою старую и сделать его более функциональным, а значит более чистой и мутабельной.
И что самое главное, Вы не хотите тратить на обновление счетчика ссылок много времени, которого и так ни на что не хватает!
Если я прав, то информация из будущего, представленная на этой странице будет очень важна и интересна для Вас.
«Память выделяли-выделяли, выделяли-выделяли, выделяли-выделяли, выделяли-выделяли, выделяли-выделяли, выделяли-выделяли, да не почистили» — знакомая проблема?
Мы знаём её решение!
Обычный си-программист - полное отсутствие вкуса.
Haskell-программист - поднимает штангу именем теории категорий (потому что с работы его уволили после того, как его опердень сожрала всю память и скрашилась.)
Rust-программисты хорошо разбираются в еде, а значит их любят девушки!
Только Сегодня! Только Для Вас! СОВЕРШЕННО ZERO-COST! Вступительный Видеоролик К Курсу «Секреты Создания Профессиональных Memory-Effective Приложений С Использованием Линейных Типов, О Которых Вам Нигде Не Расскажут В Более Доступной Форме Чем Здесь. (Да и вообще не расскажут!)»
Отзывы уже попробовавших и ОЦЕНИВШИХ наш Курс:
Спасибо Вам за гениальный курс.
Я теперь представить себе не могу, как я раньше жил без него. Чуть не потратил свою жизнь зря...
Буду советовать родным и знакомым.
Это не курс, это БОМБА!
Здравствуйте, Олег! Я всю жизнь хотел начать зарабатывать бапки, но не знал как правильно это делать. Я работал курьером, но пацаны говорят, что это отстойная работа, т.к. задача о курьере NP-полная (полная нереальных пи..цов), поэтому реальных денег она не принесет. Я пробывал делать собственные опердени на ерланге, но младший брат нашел мои пароли и стер все сайты, я только зря потратил 1799 рублей на курс того поца в пинжаке. Я пробывал самостаятельно выучить линейную логику Жирара, но непонел, почему при вложении интуиционисткой логики в линейную в правилах сокращения и ослабления нужны интуиционисткие предпосылки [A], но не линейные <!A>. Это завело меня в тупик, и я начал пить. Но встретив Ваш курс, я понел, что спасен! Это совершенно замечательный курс, он открыл мне глаза, теперь я знаю как надо делать бапки, а также как производить IO-операции в чистом языке без монад (пацаны мне сказали, что монады для лохов). Я рекомендовал Ваш курс всем пацанам на раёне, они уже пошли добывать на него деньги, что резко подняло уровень преступности, но это ненадолго, и я уверен, что того стоит.
Это новый Rust тред? Просто больше и нет юзаьельных языков без GC.
Ебстись 80% времени с памятью конечно намного лучше
Forth
Эй, байтонюх, программка память освободить хочет!
Когда-то я писал только на C и думал точно так же, но сейчас пришёл к выводу, что в нормальных языках должен быть рабочий механизм замыканий, для работы которого, в свою очередь, необходим сборщик мусора. Резюмируя: ссу опу на ебало.
>ормальных языках должен быть рабочий механизм замыканий, для работы которого, в свою очередь, необходим сборщик мусора.
Нет достаточно простого подсчета ссылок.
Пример Swift.
Монстрообразный GC который приближается по сложности и размерам к простым операционным системам не нужен.
>Ебстись 80% времени с памятью конечно намного лучше
В многопоточном приложении можно ебстись с памятью 160% времени, вот firefox КУВАНТУМ не даст соврать.
В многопотоке вручную управлять памятью чистое самоубийство.
>В многопотоке вручную управлять памятью
Всегда так делаю, ведь это забавно.
Надо же как-то развлекать себя.
Посмотри на Rust, язык с минимальным рантаймом без сборщика мусора, но с замыканиями и кучей других плюшек прямиком из языков семейства ML.
Можно конечно ебстись, а можно ограничить использование shared mutable state'а и не ебстись. Между прочим shared mutable state это проблема как Морганы многопоточных, так и однопоточных программ.
> Морганы
Ебучее автоисправление.
Ну совсем не палишься, хаха.
У меня для этого недостаточно длинная борода и я не люблю смузи
>и я не люблю смузи
Можешь начать со спермы
Это обязательное условие для программирования на Rust?
Без нормальных HKT твой раст нахуй никому не нужен.
>олжен быть рабочий механизм замыканий, для работы которого, в свою очередь, необходим сборщик мусора
Неверно. Садись, два. Иди читай SICP.
Подсчет ссылок - разновидность GC.
суки, не оценили ориджинал контент, пидоры
Единственное
SICP читал. Верно или пруфай, что неверно.
Пруфанул тебе за щеку. Весь тред линейные типы обсуждают, так сложно сложить 2 и 2?
shared_ptr - тоже разновидность GC?
оценил тебе за щеку, но на всякий случай спиздил
Тип не может быть техникой работы с памятью, глупенький. У тебя kind'ы сбились. Смарт поинтеры могут использовать rc, который является разновидностью gc.
Очевидно же, что я имел в виду не тип, а управление памятью при помощи объектов данного типа. Впрочем не считаю нужным продолжать дискуссию с человеком, который любое автоматическое управление памятью называет сборкой мусора.
>Очевидно же, что я имел в виду
Чтобы было очевидно, нужно не "иметь в виду", а писать корректные утверждения.
>продолжать дискуссию
Мы не вступали в дискуссию.
>который любое автоматическое управление памятью называет сборкой мусора.
Не знаю, где ты нашел такого человека. Нужно не домысливать, а читать, что тебе пишут.
Rust тоже не совсем юзаьельный
ATS
>достаточно простого подсчета ссылок
Что будешь делать с циклическими ссылками?
Ничего.
А что вы будете делать с программой которая запустит в бесконечном цикле выделение памяти?
Как насчет открытия ∞ количества файлов, сетевых сокетов, соединений с ДБ и тд?
Или вычисления в рантайме 0/0 ?
Ни однин полный по Тюрингу язык не может запретить писать говнопрограммы.
Это явно следует из -
https://ru.wikipedia.org/wiki/Проблема_остановки
А что вы будете делать с программой которая запустит в бесконечном цикле выделение памяти?
Как насчет открытия ∞ количества файлов, сетевых сокетов, соединений с ДБ и тд?
Или вычисления в рантайме 0/0 ?
Ни однин полный по Тюрингу язык не может запретить писать говнопрограммы.
Это явно следует из -
https://ru.wikipedia.org/wiki/Проблема_остановки
С каких пор циклические ссылки = говнопрограммы? Ты часом не жс-макака?
Странный вопрос. Будь он жс-макакой, как раз понимал бы всю суть, смысл и полезность циклических ссылок. В js вся объектная модель на них построена.
Ты ебнутый, и аналогия твоя ебнутая.
Циклические ссылки не имеют ничего общего в бесконечным выделением памяти, бесконечными циклами и прочим. Потому что это блядь структура данных, а не поток выполненения, и памяти зацикленные объекты едят статично.
Ты путаешь жс-программиста с жс-макакой.
>Ни однин полный по Тюрингу язык не может запретить писать говнопрограммы.
Так не нужен язык полный по Тьюрингу.
html хватит всем.
>С каких пор ссылки = говнопрограммы?
Со времен С++, когда они были созданы как убогие костыли
вокруг отсутсвия Copy конструктора и зоопарка Соглашений о вызове(Calling convention) на разных архитектурах.
Сейчас их, кстати, не рекомендуют использовать.
Указатели:
- проще
- эфективнее
- быстрее
- позволяют реализовать многие практичные структуры, например плавающее окно над массивом или выборку подстрок из длинной базовой строки.
Что до циклических ссылок, так это просто говно в квадрате.
Данные должны ссылаться на данные низшего порядка
Пользователь -> ИмяПользователя(строка)
и быть указуемыми данными высших ступеней иерархии
Организация -> Пользователь
Горе программист не способен создать логическую иерархию данных
>js вся объектная модель
Какая разница какая "объектная модель у js"?
Никто не программирует на голом js.
ЖС давно стал новым ассеблером.
Против Котлин, ELM, Dart - убогий jаvascript напоминает бутерброт с говном политый спермой.
Неистово двачую этого просвещенного. Чаю, коллега.
Горе-программист не способен осилить circular buffer. Иди дальше формы шлепай.
>Котлин, ELM, Dart
>А не clojurescript, reason и хотя бы ts
Мы поняли, что ты говноед, можешь не продолжать.
>Горе-программист не способен осилить circular buffer. Иди дальше формы шлепай.
Контролер буфера -> буфер
Где так нужны кольцевые ссылки?
Типа такого
typedef struct {
uint8_t * const buff ;
int head;
int tail;
const int maxLen;
} circBuf_t;
или вы знакомое слово нашли? То что буфер "кольцевой", не значит что для его реализации нужны "кольцевые" ссылки/указатели
>Горе программист не способен создать логическую иерархию данных
Все так.
>clojurescript
Практические языки, лол. А не мильоны скобочек
>reason
Да уже и голый Окамл можно в jаvascript перегонять. И C/С++.
Mне все языки приводить? Это минимум все поддерживаемые llvm + еще ∞
>ts Против ELM и Котлин
Мы поняли, что ты говноед, можешь не продолжать.
>Где так нужны кольцевые ссылки?
Я не про фиксированный ринг буфер, а про динамический кольцевой на списках.
>Типа такого
Лол, не позорился бы хоть копированием кода из википедии, стыдно же.
>вы знакомое слово нашли
Господи-боже, сколько тебе годиков-то?
>Практические языки, лол. А не мильоны скобочек
Elm (и котлин в клиент-сайде) охуенно "практические", ага, а тс, кложурскрипт и ризон с тонной продакшена ну ладно, тонны только у первых двух - не "практические", лол. Мальчик, ну ты там из манямирка вылазь иногда, ок?
Все правильно, только reference counting, только хардкор.
Свифтогосподин
Свифтогосподин
Кстати, а почему weak references никто до сих пор не упомянул?
Многопоточность и персистентные структуры данных в вашей деревне еще не изобрели?
миморегионбоярин
ты молодец, антош
Забыл.
> Свифтогосподин
Дал за щеку говноеду в этом ИТТ
Указатель тебе в жопу
С уважением, Andrew Troelsen
Как ты там в анальном рабстве?
Рабы следят за памятью, а у свободных людей есть сборщик
>Аллокатор регистров это самое поганое что когда либо было сделано в программировании. Это плевок в душу пользователя, это ленивый хуй на оптимизации это расписка в собственной лени и некомпетентности.
>вынеси мусор
Взял и вынес, я же чистоплотный. А ты пока постой в очереди на уборку, утопая в говне, как волоколамские газонюхи. Ох, не дождался - OutOfMemoryError, пойди xmx побольше сделай, да прикупи еще пару планок памяти.
> Взял и вынес, я же чистоплотный.
Ты хотя бы трудолюбивый.
> А ты пока постой в очереди на уборку, утопая в говне
В моем особняке специально обученные слуги убирают весь мусор. Но это не означает, что мне плевать на них - я их уважаю (любая работа почетна, кроме лахтодырения), не плюю на них свысока и плачу зарплату.
Байтоеб, у тебя опять мусор образовался. Байтоеб, вынеси мусор.
RAII - мусор выносит себя сам.
Подсчет ссылок все решает, без лишних накладных расходов. И слабые (weak) ссылки для кольцевых зависимостей.
Но макакам это сложно, у них обязательно память протечет.
>> Подсчет ссылок все решает, без лишних накладных расходов.
>> без лишних накладных расходов
Лол, возможно и решает, пока у нас в программе один трэд. Если тредов несколько, то начинается блядский цирк с синхронизацией доступа к счётчикам ссылок. А это вещь не дешёвая. Даже если мы сможем замутить, чтение, инкремент и декремент счётчика атомарными операциями, то всё равно придётся применять барьеры памяти (а иначе у нас всё плохо с видимостью изменений из других трэдов). А барьеры памяти штука дорогая.
Конечно, можно намутить отдельные счётчики внутри каждого трэда, но это отсутствием накладных расходов назвать сложно, так как затраты по памяти, плюс нужен какой-то супервизор, который время-от-времени должен находить для каждого объекта считать сумму счётчиков ссылок в каждом потоке, и чистить если ссылок больше нет. В такой конфигурации теряется одно из главных преимуществ подсчёта ссылок - освобождение памяти сразу, как только она становится не нужна.
Плюс у нас каждая запись в reference-переменную теперь становится достаточно дорогой, так как теперь для записи вместо одного стора, требуется лод и два стора.
В общем, вполне может оказаться, что от современного сложного трассирующего сборщика мусора меньше накладных расходов (особенно во время исполнения), чем от велосипедов со счётчиками ссылок.
Плюс, обычно, такие сборщики мусора лучше решают проблему фрагментации кучи, которая сама-по-себе тоже большая проблема.
>> без лишних накладных расходов
Лол, возможно и решает, пока у нас в программе один трэд. Если тредов несколько, то начинается блядский цирк с синхронизацией доступа к счётчикам ссылок. А это вещь не дешёвая. Даже если мы сможем замутить, чтение, инкремент и декремент счётчика атомарными операциями, то всё равно придётся применять барьеры памяти (а иначе у нас всё плохо с видимостью изменений из других трэдов). А барьеры памяти штука дорогая.
Конечно, можно намутить отдельные счётчики внутри каждого трэда, но это отсутствием накладных расходов назвать сложно, так как затраты по памяти, плюс нужен какой-то супервизор, который время-от-времени должен находить для каждого объекта считать сумму счётчиков ссылок в каждом потоке, и чистить если ссылок больше нет. В такой конфигурации теряется одно из главных преимуществ подсчёта ссылок - освобождение памяти сразу, как только она становится не нужна.
Плюс у нас каждая запись в reference-переменную теперь становится достаточно дорогой, так как теперь для записи вместо одного стора, требуется лод и два стора.
В общем, вполне может оказаться, что от современного сложного трассирующего сборщика мусора меньше накладных расходов (особенно во время исполнения), чем от велосипедов со счётчиками ссылок.
Плюс, обычно, такие сборщики мусора лучше решают проблему фрагментации кучи, которая сама-по-себе тоже большая проблема.
>так как теперь для записи вместо одного стора, требуется лод и два стора
Поправочка, как минимум, лод и два стора. Чаще всего же будет два лода и три стора.
А теперь покури Rust и перечитай снова весь тот бред, что ты написал
Да и вообще конкуретный доступ к мутабельной памяти без мутекса опасен независимо от наличия сборщика мусора. А конкурентный доступ к иммутабельной памяти нормально работает через `Arc`.
Подсчет ссылок - самая неэффективная форма гц, к сожалению. Он предпочтителен только там, где ему нет альтернатив (в языках с тонкими рантаймами).
>Если тредов несколько, то начинается блядский цирк с синхронизацией
compare-and-swap
А так - да, все так, к сожалению.
Я покурил. Никакого бреда там не написано.
>Да и вообще конкуретный доступ к мутабельной памяти
Ну так сборка мусора нужна в первую очередь для персистентных структур - которые, как ты понимаешь, с рц становятся чуть менее персистентными.
В чем неэффективность? И какая альтернатива RC в системах реального времени?
>В чем неэффективность?
Да хотя бы в этом:
>И какая альтернатива RC в системах реального времени?
Внезапно, real time gc.
> Да хотя бы в этом:
Ебанутый бред. Обход целого списка в памяти GC быстрее пары лишних сторов?
>Внезапно, real time gc.
Невозможно сделать время выполнения GC предсказуемым.
>>Обход целого списка в памяти GC быстрее пары лишних сторов?
Как бы да. GC случается относительно редко, лишние сторы же сыпятся постоянно, поэтому их будет не пара, а тысячи. Плюс эти сторы могут быть в достаточно сильно отстоящие друг от друга регионы памяти. Последствия думаю понятны.
Трассирующий GC может вызвать единовременный фриз во время исполния, RC же просто нерфит скорость исполнения на постоянной основе. Плюс при достаточном размере хипа современные инкрементальные трассирующие GC вполне могут обходиться без Stop-The-World и полного цикла сборки.
Анон, для твоего уровня погружения в тему ты делаешь слишком много крикливых безапеляционных заявлений.
>И какая альтернатива RC в системах реального времени?
Не использовать динамическую память вообще.
>В общем, вполне может оказаться, что от современного сложного трассирующего сборщика мусора меньше накладных расходов
К такому сборщику обычно в нагрузку идет язык, где нормальным считается аллокация на каждый чих. В тех же крестах оверхед от рефкаунта не особо чуствтвуется, потому что аллокации редки - данные обычно лежат на стеке. В какой-нибудь джаве супер даже навороченный сборщик легко ляжет, от постоянных многогигабайтных аллокаций в секунду.
Майнкрафт тому пример:
https://www.reddit.com/r/programming/comments/2jsrif/optifine_dev_minecraft_18_has_so_many_performance/
Что мешает в языке со сборщиком мусора, жонглировать байтами, когда это необходимо? Во всех таких языках\платформах, есть возможность выделять плоские куски памяти и работать с ними как тебе угодно.
>Что мешает в языке со сборщиком мусора, жонглировать байтами, когда это необходимо?
Религия.
В мобильном геймдеве, например, ровно так и поступают.
>работать с ними как тебе угодно
Как угодно не получится. В managed языках ты при этом обычно сильно ограничен по функционалу: в джаве value-типов вообще нет, в шарпе структуры сильно урезаны по сравнению с классами. Еще и с off-heap указателями работать обычно довольно трудно.
>в джаве value-типов вообще нет
wrong
Примитивы есть, структур нет. Да и примитивы каличные, без боксинга с ними обобщенно работать нельзя.
value-типы есть?
Будут лет через 10.
Примитивы это не value-типы?
Примитивы - это примитивы. Ты новый примитив создать не можешь, например.
Примитивы это value-типы или нет?
Нет.
>Нет.
wrong
Они value типы, но в ограниченном контексте. Как только они появляются в контексте дженериков, они уже boxed-объекты.
Так же нет возможности создать tuple/struct, ограничен только примитивами от рантайма.
>>Примитивы это value-типы или нет?
>Нет.
>Они value типы
Другой анон мимокрокодил
>в их системе типов нет пай и сигма типов
Как вы так живёте-то
Как вы так живёте-то
Он убирает мусор? Убирает.
Weaken(ref) где нужно?
Мы говорим быдлокодер подразумеваем GC,
говорим GC подразумеваем быдлокодера.
Софт с GC подобен аристократическому балу при дворе французских королей, где гости в костюмах невероятной красоты испражняются где придётся не выходя со светского раута, а потом толпа черни выгоняет весь этот великосветский сброд, чистит говно и запускает засранцев обратно.
Паразиты блядь, сколько вам памяти не дай всё засрут, запоганят абсолютно ненужной хуйнёй. Пидоры.