Войти
ФлеймФорумОбщее

Конец Java? (8 стр)

Страницы: 17 8 9 1012 Следующая »
#105
11:58, 28 мая 2019

Zefick
> Kotlin
> Scala
> Clojure
> Groovy
Чего жабисты не придумают, лишь бы не выкинуть JVM и говносборщик мусора.
А нормальные люди, тем временем, создают языки на основе llvm.


#106
12:07, 28 мая 2019

Zefick
> Clojure
Что пишут то? Я на прошлой работе (один европейский банк) писал на кложуре небольшие патчики к apache storm, мне как-то не зашел. Но он довольно активный, да, и имеет свои преимещуства - это видно хотя бы по тому, что это один из немногих языков, под который есть только платные средства разработки отличающиеся от блокнота.

#107
12:15, 28 мая 2019

Panzerschrek[CN]
> А нормальные люди, тем временем, создают языки на основе llvm.
  Нормальные люди давно не холиварят, а используют то, что лучше подходит под задачу. LLVM-based подходят далеко не для всего, особенно из того, за что платят деньги.

9К720
> Что пишут то?
  Какой-то стартап: https://www.takeoff.com/

#108
14:55, 28 мая 2019

Panzerschrek[CN]
Котлин и под LLVM компилит, толку то - все равно сборщик мусора, просто не такой навороченный как в jvm.

#109
15:07, 28 мая 2019

kipar
> Котлин и под LLVM компилит, толку то - все равно сборщик мусора, просто не
> такой навороченный как в jvm.
Создаёт поток, или О(1) итеративно на new?

#110
(Правка: 15:27) 15:17, 28 мая 2019

kipar
> Котлин и под LLVM компилит, толку то - все равно сборщик мусора, просто не такой навороченный как в jvm.
  Мне страшно представить какой там с LLVM можно сборщик написать если даже в Go свой космический GC из прошлого века пишут сами. Всё-таки JVM в этом плане пока что вне досягаемости кого бы то ни было. Для обычных наколенных поделух вообще нет разницы что там - GC или "автоматическая" сборка с типа "известным заранее временем освобождения ресурсов". Да и для ненаколенных тоже. Тот же Docker написан на Go. А это, на секундочку, среда виртуализации. Если набрать в гитхабе "Ethereum", то первым результатом выскочит официальная имплементация протокола на том же Go. Если даже такие штуки пишут на языках с GC, то на хрена кому-то вообще сдались кресты в 2k19-м?

#111
15:29, 28 мая 2019

1 frag / 2 deaths
поток.
https://github.com/JetBrains/kotlin-native/blob/master/runtime/sr… pp/Memory.cpp
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Pure.pdf

Zefick
> Для обычных наколенных поделух вообще нет разницы что там - GC или
> "автоматическая" сборка с типа "известным заранее временем освобождения
> ресурсов".
с одной стороны да, а с другой стороны - нет. Если пишешь на языке с гц - сразу эти мысли о "давайте не грузить гц, давайте переиспользуем объекты, а тут на каждом тике будет пять объектов создаваться и тому подобная морока". То ли дело старый добрый ручной менеджмент.
Особенно если этот гц не из jvm а что-то более убогое. Ну а jvm стартующий по пять секунд я вообще для наколенных поделок не рассматриваю.

#112
15:40, 28 мая 2019

kipar
> поток.
Жаль. Чё О(1) не сделают

#113
15:41, 28 мая 2019

kipar
> Если пишешь на языке с гц - сразу эти мысли о "давайте не грузить гц, давайте переиспользуем объекты
  Это дебильная мысль возникает только у тех, кто не знает как работает GC. Удаление мёртвых объектов для него ничего не стоит. Та же Clojure, где даже при добавлении элемента в коллекцию получается новая коллекция (естественно там в библиотеке проведена огромная работа и полностью данные никогда не копируются, но для пользователя она выглядит именно как новая) показывает, что с этим вполне можно жить и даже разрабатывать продукты для промышленности.

> Ну а jvm стартующий по пять секунд я вообще для наколенных поделок не рассматриваю.
  У тебя опять инфа из прошлого века или ты путаешь с серверными приложениями. Они могут и минуты грузиться, потому что им много что нужно сделать, что не ограничивается только работой на текущем узле. И куча там не два гигабайта, как у тебя на компе, а два терабайта.

#114
16:01, 28 мая 2019

kipar
> Если пишешь на языке с гц - сразу эти мысли о "давайте не грузить гц, давайте
> переиспользуем объекты, а тут на каждом тике будет пять объектов создаваться и
> тому подобная морока". То ли дело старый добрый ручной менеджмент
Чушь. Если у тебя объекты локальные и могут быть на стеке, то они и будут на стеке, старый добрый escape-analysis придумали лет 15 назад. А так, ты точно так же паришься с менеджером памяти. Рассматривай Гц как уже готовые хорошо оптимизированные стратегии менеджмента памяти, использующие информацию доступную только в рантайме.

Случаев когда тебе Гц не подходит ещё меньше, чем когда тебе нужно писать свой собственный менеджер памяти

#115
16:05, 28 мая 2019

Zefick
> Тот же Docker написан на Go. А это, на секундочку, среда виртуализации
Ты херню то не неси. Почитай внутреннее устройство докера, и что там именно написано на го, лол.

#116
16:07, 28 мая 2019

9К720
В Boehm GC нет никакого анализа. В моно тоже. И в руби нет.
От того что он где-то есть мне не легче, у тех языков другие фатальные дефекты.

> Рассматривай Гц как уже готовые хорошо оптимизированные стратегии менеджмента
> памяти
на практике это некие костыльные стратегии, которые не используют ту информацию которая есть у меня как у автора.

#117
(Правка: 16:21) 16:18, 28 мая 2019

kipar
> которые не используют ту информацию которая есть у меня как у автора.
Да, конечно. Бесспорно, знание прикладной области может сильно влиять на информацию о порядке размещения объектов в памяти. Но это бывает не то чтобы очень часто. Скорее очень нечастно.
Если в твоем случае это так - значит тебе GC не подходит.  Что ты там пишешь? Оптимизации коллекций в ядре линукса, или системы реального времени для 2кб плиса?

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

#118
16:42, 28 мая 2019

9К720
Если создавать объекты\массивы\строки каждый кадр, после какого-то порога гц начинает периодически останавливать мир. Если б там была отдельная куча для молодого поколения - возможно этого эффекта бы не было, но ее нет.
А так надо следить чтобы выделение не выходило за этот порог, что приучает обходиться без аллокаций. При том что я точно знаю когда эти объекты можно удалять, мне проще было бы без циклических связей обойтись чем страдать с этой экономией аллокаций.

#119
16:46, 28 мая 2019

kipar

Юните шталь?
Страницы: 17 8 9 1012 Следующая »
ФлеймФорумОбщее