LINUX.ORG.RU

А нужны ли все эти ваши гринтреды, корутины, I/O асинхронщина

 , , ,


1

5

и прочие 'костыли/недотреды' на современном то железе и операционных системах в 2018+ годы?

Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого.

Зачем усложнять рантаймы и писать нечитаемою асинхронщину? Зачем пользоваться убогими Node.js, Golang и тому подобным?

Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого.

Для эффективного утилизирования «всего этого» отлично подходит пресс.

anonymous ()

А нужны ли

da

anonymous ()
Ответ на: комментарий от spec_po_kiskam

А нужны ли эти ваши убогие тролли и школота, не осилившие конкаренси?

Школота как раз этим и упарывается не понимая зачем это нужно и где следует применять.

bread ()

Про производительность такого подхода: Царю про 10к в надежде перевести дискуссию в конструктив (комментарий)

А ещё ты словишь проблем, если захочешь создавать нити для каждого соединения, потому что по умолчанию создать больше где-то тридцати тысяч не сможешь. Надо будет открутить лимиты во многих местах. Последний лимит в 125 тысяч на 16 гигов придётся откручивать в ядре Linux. Причём недостаточно будет просто число поменять в конфиге. Придётся патчить, так как лимит там достаточно захардкожен.

При этом всём современные асинхронные серверы на современном железе могут выжать порядка десятка миллионов одновременных соединений. Возможно, больше.

i-rinat ★★★★★ ()

на современном то железе

воткнуть больше памяти, ядер

«Хоп, хипстерок,...»

anonymous ()

В целом, под капотом будет то же самое, никуда не денешься. Сила современной функциональщины в абстракциях.

Вот к примеру как применять идрис

https://journals.agh.edu.pl/csci/article/download/1413/1840

Ну и в книге Бреди есть глава отдельная type safe concurent programming.

Т.е. треды нужны, никуда не денешься. Другое дело что инструменты есть гораздо более удобные и мощные чем голанг и иже с ними.

AndreyKl ★★★★★ ()

Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого.

Из-за людей которые так считают, gitlab + nextcloud + WordPress не влазят в 8 гб ОЗУ, ну ёлыпалы...

AntonyRF ★★★ ()
Ответ на: комментарий от theanonymous

А что именно тебе не понятно в golang

как раз голэнг и хайпают: «Горутины! каналы!» — это все костыли и не нужно в долгой перспективе: «Достаточно воткнуть больше памяти, ядер и пользоваться ФП для эффективного утилизирования всего этого».

mimimimi ()
Ответ на: комментарий от i-rinat

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

Это проблемы реализации. Ее можно допилить с учетом нового железа в долгосрочной перспективе.

При этом всём современные асинхронные серверы на современном железе могут выжать порядка десятка миллионов одновременных соединений.

Знаю. Но поддерживать такой код — не очень.

mimimimi ()
Ответ на: комментарий от bread

Так без этого на работу программистом в 2018 не берут.

Deleted ()
Ответ на: комментарий от mimimimi

Но поддерживать такой код — не очень.

Ну и какие проблемы у golang-а с его гороутинами в этом случае? Выделяется по гороутине на соединение и все, дальше каждая гороутина работает как обычный тред с обычными синхронными операциями внутри.

Что не так?

eao197 ★★★★★ ()
Ответ на: комментарий от theanonymous

А касаемо другой темы, но по golang — можно? Чтоб два раза не вставать.

Вот пример из тура по Go:

package main

import "fmt"

func main() {
	s := []int{2, 3, 5, 7, 11, 13}
	printSlice(s)

	// Slice the slice to give it zero length.
	s = s[:0]
	printSlice(s)

	// Extend its length.
	s = s[:4]
	printSlice(s)

	// Drop its first two values.
	s = s[2:]
	printSlice(s)
}

func printSlice(s []int) {
	fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s)
}

И его вывод:

len=6 cap=6 [2 3 5 7 11 13]
len=0 cap=6 []
len=4 cap=6 [2 3 5 7]
len=2 cap=4 [5 7]

То, что из пустого слайса можно сделать непустой, ещё куда ни шло (хотя подташнивать начинает уже в этот момент, да). Но может мне кто-нибудь объяснить, почему при урезании слайса с конца capacity не меняется, а при урезании с начала — меняется?

Deleted ()

Зачем усложнять рантаймы и писать нечитаемою асинхронщину?

Чтобы не орать потом «Почему я не делал сразу асинхронщину и что теперь делать с этим набором костылей?»

oldstable ()
Ответ на: комментарий от Deleted

Но может мне кто-нибудь объяснить, почему при урезании слайса с конца capacity не меняется, а при урезании с начала — меняется?

Так там же прямо написано:

The capacity of a slice is the number of elements in the underlying array, counting from the first element in the slice.

Puzan ★★★★★ ()
Ответ на: комментарий от anonymous

Асинхронщина это и есть набор костылей.

Я бы обобщил: любая программа — это набор костылей.

oldstable ()
Ответ на: комментарий от Puzan

Невнимателен, грешен.

Тогда другой вопрос: почему при урезании с конца можно всё вернуть взад, а с начала — нельзя?

Deleted ()
Ответ на: комментарий от Deleted

Тогда другой вопрос: почему при урезании с конца можно всё вернуть взад, а с начала — нельзя?

Потому что в структуре, описывающей слайс не хранится capacity слева (отрицательная часть).

Слайс - это структура с тремя полями - указатель на первый элемент, длина слайса и capacity. Вот из этого всё и следует.

Puzan ★★★★★ ()
Последнее исправление: Puzan (всего исправлений: 1)
Ответ на: комментарий от anonymous

Оно само по себе большой костыль. Весь вот этот сраный цикл с конечными автоматами и callback-ами. Гугли «callback hell». В былые времена писали с нормальными тредами, а потом началось...

anonymous ()

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

anonymous ()
Ответ на: комментарий от anonymous

Оно само по себе большой костыль. Весь вот этот сраный цикл с конечными автоматами и callback-ами. Гугли «callback hell».

А при наличии call/cc (который придумали полвека назад) никакого callback hell'а нет. Там, где нет call/cc, делают что-то типа async/await или промисы.

monk ★★★★★ ()
Ответ на: комментарий от mimimimi

Это проблемы реализации. Ее можно допилить с учетом нового железа в долгосрочной перспективе.

Ну и где реализация? :-)

Мне знаком этот подход — считать, что знаешь лучшее решение. Иногда ты действительно знаешь лучшее решение, но зачастую нет. Просто что-то забываешь, или в чём-то ошибаешься. В любом случае всё решает реализация идеи. Если идея была хорошая, то реализация взлетит. Если нет — ты поймёшь, где ошибался. Win-win.

i-rinat ★★★★★ ()

Так ведь корутины и нужны для того, чтобы было типа синхронно? Или не так?

rumgot ★★★★★ ()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от pylin

Во времена Ильи Муромца улицы Герцена не было. Так что, да, для Илюшеньки я с улицы Герцена.

anonymous ()
Ответ на: комментарий от i-rinat

Я к тому, что надо уже прямо сейчас, начинать писать на ВУ ФП языках (очень подходящих для многопроцессорных систем) читабельный линейный код, а не выбирать говнотехнологии 60х годов с асинхронным подходом (пусть даже и засахаренном). Все это окупится довольно скоро.

mimimimi ()
Ответ на: комментарий от anonymous

Оно само по себе большой костыль

Да это мы уже поняли. Дальше тоже можно не читать:

Вся эта сраная логика с ветвлениями и циклами. Гугли «индусский код». В былые времена писали нормальные программы на 1000 строк максимум, а потом началось...

Итог: неверно, попробуй ещё раз

anonymous ()
Ответ на: комментарий от mimimimi

читабельный

Мля, они опять выходят на связь...

anonymous ()
Ответ на: комментарий от mimimimi

У вас есть дурная привычка не отвечать на неудобные вопросы.

Посему еще:

писать на ВУ ФП языках (очень подходящих для многопроцессорных систем)

Это вы в книжках вычитали про «очень подходящих» или подсмотрели где-то на практике? Где именно?

Сможете ответить?

eao197 ★★★★★ ()
Ответ на: комментарий от mimimimi

Все это окупится довольно скоро.

Я уже 10 лет это слышу.

RedPossum ★★★★★ ()
Ответ на: комментарий от anonymous

Тогда асинхронщина представлена каким-либо принципиально новым интерфейсом, либо её вовсе нет. Очевидно же, не?

anonymous ()
Ответ на: комментарий от anonymous

А если примисов и async/await тоже нет?

Тогда как в 1С: параметр обратного вызова и всё.

monk ★★★★★ ()

нечитаемою асинхронщину?

Вангую что чел просто никогда не читал ни того ни другого сложнее хелоуворлда, потому и не знает что читаемое а что нет.

redixin ★★★★ ()
Ответ на: комментарий от anonymous

Какой «индусский код»?
Имеет место конкретная архитектурная кривизна. Эдакая попытка построить псевдомногозадачный велосипед.

anonymous ()

Раз речь зашла про ФП, то вообще-то, Haskell как раз имеет гринтреды, корутины заменяются продолжениями, обернутыми в монаду, или теми же гринтредами, и почти все IO в Haskell асинхронное из коробки.

dave ★★★★★ ()

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

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

Пользоваться nodejs и golang дело вкуса, кому-то нравится пользоваться java, C++ или даже C#, в котором теперь асинхронщина вполне себе годна, а кто-то до сих пор пользуется С и рулит блокирующим и неблокирующим вводом вручную, это лишь механизмы. А вот то, что ты, тролололо, наверняка вкурсе, но всё же, возможно не вкурсе, что mainloop, блокирущий-неблокирующий ввод, таймеры и прочее использовали люди писавшие ещё на asm в мохнатых годах, не говоря уже про С, зачем-то говоришь только о nodejs и golang, хотя там просто сахара завезли для удобства(и то только в golang, ибо программирование на Nodejs напоминает программирование на С + glib).

ixrws ★★★ ()

Нужны, если правильно сделаны. См. Erlang.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от anonymous

Вот этот main loop, с самопальным планировщиком(если он вообще есть).
Необходимость ручного сохранения состояний. Конечные автоматы, опять же.
Это же ни что иное, как попытка заменить механизмы ядра ОС своим велосипедом.
Да, при определённых условиях этот велосипед едет быстро, ибо лёгкий. Но он всё равно ущербный.

anonymous ()
Ответ на: комментарий от anonymous

Да, при определённых условиях этот велосипед едет быстро, ибо лёгкий. Но он всё равно ущербный.

Т. е. хоть какое-то понимание есть? Good

попытка заменить [универсальные] механизмы ядра ОС своим [специализированным] велосипедом

Про то, что это один из методов оптимизации рассказывать ведь не надо? Все остальные заморочки(большинство, по крайней мере) тоже оттуда родом. А решение не ущербно за отсутствием достойных альтернатив - здесь ресурсов сервера, наверное, всегда не хватать будет

anonymous ()
Ответ на: комментарий от anonymous

хоть какое-то понимание есть?

Ага. Сам проектировал и писал на си асинхронщину. И другие реализации неоднократно видел. Гемор это, лютый гемор.

А решение не ущербно за отсутствием достойных альтернатив - здесь ресурсов сервера, наверное, всегда не хватать будет

С таким стремительным ростом количества ядер, который наблюдается в последние годы, нужно бы начинать использовать другие архитектуры.
Вон, тот же Freeswitch, будучи изначально спроектированным как «heavy multi-threaded» с блокирующим I/O, довольно неплохо выстрелил, если сравнить с Asterisk-ом.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.