языки без сборки мусора

условная обработка видео — 20fps

кадры одинакового размера, зачем там постоянно выделять/освобождать ? посмотри как работают драйверы video for linux - выделяется пулл исходя из информации о размере кадра и затребованном количестве и создаются две очереди, в одной кадры на обработку в другой обработанные.

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

Я и не спорю, но всё же от алгоритма зависит и конкретной реализации сборщика, плюс на практике он не бесплатный.

Так о чем и речь, что нужно смотреть конкретно в каждом случае. А поднимать ор что дескать сборщик мусора это плохо может только не разбирающийся человек, либо сектант. Выбирать язык «лишь бы там не было сборщика мусора» это же бред полный.

Так, ты отказываешься от своих слов и признаешь что я был прав?

Java/iOS еще лучше.

Не, там программа-бинарник меняет поведение при изменении исходного кода на ходу.
https://vlang.io/img/hot.webm

для скриптоты - понятно, но как это возможно для компилируемых языков? неужели так быстро компилируется «на лету»?

Да. Не пойму, компилируется весь файл или только функции, помеченные как live. Но быстро.

Даже для C/C++ был REPL. Не говоря уже о всяких хацкеллах и млах.

хацкеллах и млах

Иншаллах!

Даже для C/C++ был REPL.

Из которого можно добавлять/изменять функции? Можно ссылку?

Cling. Насчёт добавления функций не знаю, но я не вижу проблемы.

Эм, но ведь это уже было в CL

Эм, но ведь это уже было в CL

CL не умеет маленькие бинарники делать. Только образ вместе с компилятором. Как и Smalltalk.

Самый свежачок сейчас - formality.

13. Pascal

Заставляет усомниться в адекватности этого рейтинга.

Кстати REPL как по мне не удобная идея. Лучше список watch выражений которые перевыполняются при каждом изменении кода и пересборки. Добавил три нужные вызова функций и редактирует код, смотришь результаты.

Вообще, я изначально сильно сомневался, не клоун ли автор, но вот такие штуки впечатляют: https://github.com/vlang/v/blob/master/examples/database/pg/customer.v#L35

С другой стороны, видосик выглядит фейком. Я тебе уже говорил выше как оно работало изначально, сейчас, судя по коду, концепция особенно не изменилась: https://github.com/vlang/v/blob/master/compiler/repl.v#L126

Далеко ходить не надо https://github.com/kostya/benchmarks

Это говно нихрена не бенчит - тебя поимела пропаганда. Я даже больше скажу - это говно специально подобрано таким образом, что-бы гц не обсиралось, как и не обсирались недоязычки. Тебя в двойне поимела пропаганда.

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

Тебя совсем в говне изваляла пропаганда.

или https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=f...

Это говно так же ничего не бенчит. Это мусорное говно, которое бенчит отдачу хелворда, где 99% работы делает сишный рантайм.

С другой стороны, видосик выглядит фейком.

Графику было проверять влом (нет нужных пакетов). Но https://github.com/vlang/v/blob/master/examples/hot_reload/message.v проверил. Действительно текст меняется сразу при изменении файла.

Я тебе уже говорил выше как оно работало изначально, сейчас, судя по коду, концепция особенно не изменилась:

Всё верно. Он cc запускает для компиляции. Просто всё это происходит при любом изменении файла и скомпилированное вставляется в текущий процесс.

Лучше список watch выражений которые перевыполняются при каждом изменении кода и пересборки. Добавил три нужные вызова функций и редактирует код, смотришь результаты.

REPL - инструмент. Реально помогает, если можно пересобрать код не потеряв текущее состояние (значения переменных). Тогда можно разрабатывать как в Лиспе, отлаживая по очереди функции на подготовленном примере. К слову, REPL как раз и нужен, чтобы этот пример подготовить.

Самый свежачок сейчас - formality.

Спасибо! Именно такие ответы я хотел получить. А то завели тут старую пластинку про раст

Так нужно было сразу просить срань для пердоликов, тебе бы быстро подобного накидали.

Ась? Нашлась годная замена CL?

Самый свежачок сейчас - formality.

Реализация на js использует сборку мусора.

Реализация на си тупо захватывает всю доступную память. https://github.com/moonad/Formality-C/blob/master/FM-Net/fm-net.c#L392-L394

Теория может быть и красивая, но про память и сборку мусора лучше бы он не писал, особенно 1-ым пунктом.

Ась? Нашлась годная замена CL?

Почти. Очень сырая.

Далеко ходить не надо https://github.com/kostya/benchmarks

https://github.com/kostya/benchmarks/blob/master/matmul/matmul.c
В mm_init() вызывается calloc() по количеству строк матрицы.
Ни для кого не секрет, что calloc() заполняет нулями выделенную память, что с учетом последующей поэлементной инициализации (вызов mm_init()) является диким оверхэдом.
Второй раз это стреляет при создании временной транспонированной матрицы.
И затем mm_destroy() для каждой строки матрицы.
Итог: 12-е место в тесте matmul по времени (и это с трехкратным оверхэдом по заполнению памяти и оверхэдом по построчным вызовам менеджера памяти).

Реализация

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

Теория может быть и красивая, но про память и сборку мусора лучше бы он не писал, особенно 1-ым пунктом.

Красивая теория линейных типов как раз про управление ресурсами (самым простым из которых является память), так что не удивительно, что про память и GC написано в первом же абзаце. Но за 40 лет существования теории до практики дело так и не дошло. А тут, похоже, что-то получается.

Котечка ты моя, не подкатывай к джавистам. Я и метапрог лучше всех.

Grzegorz

JVM с отключённым gc предлагали?!

Ну может он натерпелся с фризами на старой джаве или страдал от невозможности треды по процессорам раскидать в питоне...
Я, кстати, страдал когда-то от невозможности быстро освободить память в c#.

Пока язык в разработке, всем плевать на реализацию

Задокументировали первым пунктом свойства «реализации». Но при этом «реализации» с такими свойствами нет.

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

«Хорошо» когда тебя обманули?

теория линейных типов как раз про управление ресурсами (самым простым из которых является память)

Линейные типы - это частный случай управления владением (самый простой). Управление ресурсами и памятью не всегда ложиться на линейные типы.

При этом упрощение в одном аспекте логики приводит к усложнению в другом. Будешь писать логику сборки мусора на линейных типах, вместо того чтобы писать бизнес-логику. (Например, Rc/Arc в rust, при этом подсчет ссылок - это частный случай и не решение пробемы управления владением).

лол? это интерпретируемый язык, интерпретатор которого написан на интерпретируемом языке, выполняющемся в куске браузера

всё больше хэловорлдов ты хотел сказать

Итог: 12-е место в тесте matmul по времени (и это с трехкратным оверхэдом по заполнению памяти и оверхэдом по построчным вызовам менеджера памяти).

Все рассуждения неверны, но код действительно говно. Основные моменты я сообщил. Идиоты бенчан ffi к си во всякой скриптухе, собирают си четвёртым gcc, да и попросту результаты фейковые. Это очевидно.

> С++

Учите матчасть

https://www.hboehm.info/gc/

В крестах же вектор из коробки реализует удвоение длинны.

Зачем херню несёшь, клоун?

Например, сравниваем Kotlin и C++. В версии на C++ элементы в массив добавляются по одному, в версии на Kotlin заполняются с удвоением длины массива. То есть в версии для C++ вместо tape.push_back(0) должно быть tape.resize(tape.size()*2, 0);

Идём сюда, смотрим на эту бездарность: https://raw.githubusercontent.com/kostya/benchmarks/master/brainfuck2/bf.scala

Эта бездарность замеряет внутри, что неверно(что оно там замеряет - неизвестно), но так же эта бездарность захардкодила строку в код. Т.е. эта бездарность уже умножила свои потуги на ноль, т.к. в ситуации с С++ это сразу время исполнения сводит к нулю.

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

О том, что бенчмарки подложные я уже написал. О том, что измерения неверные - я уже писал(допустим, биомусор собирает си четвёртым gcc.

Я пробовал удалять эту строку и оставлять только чтение из файла, плюс замерку их убирал. Выигрывала у С++.

Я пробовал удалять эту строку и оставлять только чтение из файла, плюс замерку их убирал. Выигрывала у С++.

Тебя поимела пропаганда. Замеряется время запуска программы и только так. Данные не хардкодятся. Оно в принципе не может выиграть у С++, ведь время исполнения этой дристни у С++ равен нулю.

Если мы замеряем только run - я могу вснуть туда jit и этот огрызок пойдёт мыть полы.

Замеряется время запуска программы и только так.

Так и делал. Никто меня не имел. Хотя я и написал, что ты имеешь виду? Я делал так: time java -jar main.jar

Убрав строку, замер времени тот, и оставив только чтение из файла.

Так и делал. Никто меня не имел. Хотя я и написал, что ты имеешь виду? Я делал так: time java -jar main.jar

Какое время у тебя показывает С++-версия, как запускал? Как мне запустить это скала-говно?

Как мне запустить это скала-говно?

Стопэ, глянь на комментарий там про Kotlin речь. Откуда ты Scala вытащил? Ну во всяком случае с Kotlin тоже интересно, тоже ява-язычек. Я ставил Kotlin с помощью SDKMAN: https://kotlinlang.org/docs/tutorials/command-line.html

Какое время у тебя показывает С++-версия, как запускал?

25.xxx и 28.xxx секунд было. Брал вот эту программу и https://github.com/kostya/benchmarks/blob/master/brainfuck2/bench.b только увеличивал ее:

 Benchmark brainf*ck program
>++[<+++++++++++++>-]<[[>+>+<<-]>[<+>-]++++++++
[>++++++++<-]>.[-]<<>++++++++++[>++++++++++[>++
++++++++[>++++++++++[>++++++++++[>++++++++++[>+
+++++++++[-]<-]<-]<-]<-]<-]<-]<-]++++++++++.
   Benchmark brainf*ck program
>++[<+++++++++++++>-]<[[>+>+<<-]>[<+>-]++++++++
[>++++++++<-]>.[-]<<>++++++++++[>++++++++++[>++
++++++++[>++++++++++[>++++++++++[>++++++++++[>+
+++++++++[-]<-]<-]<-]<-]<-]<-]<-]++++++++++.
   Benchmark brainf*ck program
>++[<+++++++++++++>-]<[[>+>+<<-]>[<+>-]++++++++
[>++++++++<-]>.[-]<<>++++++++++[>++++++++++[>++
++++++++[>++++++++++[>++++++++++[>++++++++++[>+
+++++++++[-]<-]<-]<-]<-]<-]<-]<-]++++++++++.
  

25.xxx и 28.xxx секунд было. Брал вот эту программу и https://github.com/kostya/benchmarks/blob/master/brainfuck2/bench.b только увеличивал ее:

Я взял твою программу - у меня это 4-5 секунд. Обычная 1.2-1.3 секунды. Откуда ты взял 25-28 - я не знаю.

Гцц какой версии? g++ main.cpp -Ofast -march=native -fwhole-program - этого должно быть достаточно.

https://github.com/kostya/benchmarks/blob/master/brainfuck2/bench.b выполняется и у меня тоже быстро. i5 3.1ghz

Далеко ходить не надо

А ты сходи все же за нормальными бенчмарками, а не за говном из непонятного гитхаба с брейнфаком.

А что такое идентичные алгоритмы тогда?

Автор хотел сказать «реализации одного и того же алгоритма без лишнего говна».

https://github.com/kostya/benchmarks/blob/master/brainfuck2/bench.b выполняется и у меня тоже быстро. i5 3.1ghz

Ну судя по всему это 10 секунд(раз х3 30 секунд). Это как-то ненормально. Значит что-то не то. Не может так сильно различаться время полнения.