ну так со мной согласились в итоге все

тебя прежде всего назвали школьником

и прежде всего, соглались на абстрактный случай

который в реальности не возможен

Антон другой выше написал нормально

тебя прежде всего назвали школьником

ну, это мнение человека, который меня видит в первый раз, я его мимо ушей пропустил)

Антон другой выше написал нормально

он все правильно написал

ну, это мнение человека, который меня видит в первый раз, я его мимо ушей пропустил)

ну я троллю, конечно

если в сях добавить кучу проверок и gc - по скорости они опустятся до уровня джавы

это, по сути, и будет джава

в каком-то виде

нет

у сей не будет jit'a

с профайлом

ну, нет, потому что это не VM будет

не будет рантайм оптимизаций

у сей не будет jit'a

clang

никогда от слова вообще

не будет рантайм оптимизаций

constexpr, например - не рантайм-оптимизация? это толсто, конечно, но все же

щас бы придумывать, что нужно напихать в си-плас-плас чтобы получить джаву!)

и потом, что такое, в твоем понимании, рантайм-оптимизация?

это генерация более эффективного ассемблера

то есть то, с чем и компилятор может справиться ничуть не хуже при должном уровне развития

а что такое эффективный?

и потом, что такое, в твоем понимании, рантайм-оптимизация?

спеклятивная* рантайм оптимизация. которую нельзя в общем случае сделать

а что такое эффективный?

лучше всего использующий возможности конкретной архитектуры

а что такое лучше использовать? цпу, память, throughtout, latency ...

под этим много чего можно понимать

под этим много чего можно понимать

все верно, но кто сказал, что JVM это понимает лучше, чем gcc/clang? я вот не думаю, что это так

JVM - слишком общий продукт, его задача - это много платформ поддерживать, а не оптимизировать свежий набор SSE инструкций и cache usage на новых интелах

то есть они, конечно, до этого дорастают потом, но сначала эти фишки появляются в компиляторах

хмм. даже не знаю уж что и вкинуть, чтоб срач поднять

llvm vs jvm

llvm vs jvm

вот типа того, да

llvm vs jvm

я не компетентен в этом

я не компетентен в этом

как будто это кого-то останавливало в этом или другом чате

люди втирают про с++ или джаву, при этом толком не зная эти платформы

?

люди втирают про с++ или джаву, при этом толком не зная эти платформы

jit тормозит! gc тормозит! ааа!

Автомобиль тормозит!?

???

Не тормозит

Го тоже тормозит

Всё тормозит, кроме испорченных тормозов

компьютеры тормозят

все говно

Да

☹️

мы все умрем

Про io/nio Есть ли изкоробочный способ получить файл как стрим||итерабл<Byte> таким образом, чтобы он НЕ подгружался весь в оперативку (это важно, т.к. файлы >> озу). Понятное дело, что можно написать буферное чтение руками, но велосипед же

чиго? Ну FileInputStream не подгружается весь в оперативку

ну, там можно либо получить при помощи toByteArray массив размером 20GB (нет, очевидно, сайз в инты не влезет) либо пользовать read(byte[]), читай про велосипед выше

А чего ты хочешь с ним делать? Ну оберни в какойнить Data/Object InputStream чтобы читать что-то конкретное

Но как бы стрим||итерабл<Byte> ты получил

шта? Мы на одном языке говорим?

Не факт

Ты можешь читать из FileInputStream побайтово, что ещё нужно?

Ты можешь читать из FileInputStream побайтово, что ещё нужно?

способ из коробки обернуть это в стрим

Ну вы уточняйте какой стрим) он и сам стрим))

Stream<Byte>

Iterable<Byte>

или или

ERROR: S client not available

Ну наверное стандартной функции такой нет, но писать-то там нечего

ну я о том же

если нет, оставлю свой костыль, если есть - соответсвенно возьму из коробки

Ты можешь читать из FileInputStream побайтово, что ещё нужно?

стоит упомянуть, что читать по одному байту дорого(долго)?

а то мало ли

эт факт

но товарищ видимо не ищет легких путей

хотя если буфернуть то в целом не так уж и дорого, да и IntStream есть

но товарищ видимо не ищет легких путей

Товарищ как раз легкие пути и ищет. А если буфернуть, то, конечно, дешевле, меня просто "побайтово" смутило

Нуу эээ ты же всеравно хочешь получить их побайтово)

Да шож такое :D Побайтовая итерация != Не буферизованное чтение)

Ну ты заварачиваешь FileStream в BufferedSream получаешь буферезированное чтение, это на логику мало влияет вообще

А тут спарк обсуждают?

https://telegram.me/scala_ru

@fomkin дык спарк нынче не чисто скальный)

мб кто сталкивался с проблемой, вот в идее я пользуюсь всегда одним и тем же apache-commons StringUtils, но когда пишу код и через alt+enter выбираю импорт из предложенных, в списке он далеко не всегда идёт первым. можно сделать чтобы идея запоминала что импортировать или хотя бы руками забить?

А уж сколько раз оно апаче.и18н.Ексепшн импортировало вместо нормального...

мб кто сталкивался с проблемой, вот в идее я пользуюсь всегда одним и тем же apache-commons StringUtils, но когда пишу код и через alt+enter выбираю импорт из предложенных, в списке он далеко не всегда идёт первым. можно сделать чтобы идея запоминала что импортировать или хотя бы руками забить?

разве что радикально - выбрать лишний -> стрелку вправо -> exclude from auto-import

спс, я даже не знал что туда можно тыкнуть

конечно 10 левых StringUtils прятать не очень круто

https://telegram.me/scala_ru

Пасибо

о_О а программерские подкасты слушают для увеличения скила?

заслушал крайний «разбор»?

С Сергеем?

@guga4ka свежий же вышел

и без Сергея

воу-воу, мой rss что ли сломался

хз, у нас рсс работает

иначе бы выкладка в FB и твитор тоже смломалась бы

действительно вышел, пойду скачаю

правильно, а то я поглядел по статистике, что ты не скачал

правильно, а то я поглядел по статистике, что ты не скачал

Виктор, что, действительно, в скалу ударишься?)