а потом появился SSE

и теперь все одинаково работает)

так функции-то разные совсем

О нет только тут не начинайте )

я всегда думал, что memcpy на x86 сделана просто через какие-нибудь rep movsb, чего там мудрить-то?)

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

меня вот одно удручает в BetterC — в 2.0.79 чего-то натворили с core.stdc, и теперь половина стандартной библиотеки Си не помечена как nothrow @nogc

Репрессии?

а, ну и 2.0.79 даже с -dip1008 не позволяет выкидывать исключения

а в остальном отличный близкий к железу диалект D, запилил себе динамические массивы на стеке с подсчетом ссылок, и вообще отлично стало)

с нормальными дишными array[], конечно, не сравнятся, но уже гораздо лучше того, что есть в Си

инициализированные по умолчанию структуры тоже радуют

я даже уже жалею что потратил на него когда-то время, лучше бы чистый С юзал

плюсы - говно, чистая сяшка - дважды говно.

https://forum.dlang.org/post/p9232r$1uup$1@digitalmars.com история с pow продолжается интересно)

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

плюсы - говно, чистая сяшка - дважды говно.

А что с чистой сяшкой не так? Отлично же живет, хайлоад капы выигрывает.

А что с чистой сяшкой не так? Отлично же живет, хайлоад капы выигрывает.

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

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

Consistancy и простота

И скорость

Consistancy и простота

ты можешь на плюсах писать просто, консистентность - вещь крайне размытая

так сяшка в общем случае — подмножество с++)

И скорость

скорость одинакова, с чего бы сяшке быть быстрее?

в том смысле, что на с++ можно писать в стиле сяшки, и будет то же самое)

скорость одинакова, с чего бы сяшке быть быстрее?

Отсутствие ооп с его охуительным таблицами виртуальных функций с множественным наследованием - вот это все добротно снижает рантайм. А всякие шаблонные колдунства роняют компайл-тайм до дна.

https://forum.dlang.org/post/p9232r$1uup$1@digitalmars.com история с pow продолжается интересно)

ВО, видишь как оно пошло? :D Один истеричный пинок, пара дней работы и все готово https://github.com/dlang/dmd/pull/8071/files

более того, Уолтер говорит, что BetterC генерирует код идентичный сяшке в простейших случаях)

И вот эти 300 строчек не могли 10 лет написать, Карл

Отсутствие ооп с его охуительным таблицами виртуальных функций с множественным наследованием - вот это все добротно снижает рантайм. А всякие шаблонные колдунства роняют компайл-тайм до дна.

не пиши ооп, или пиши ооп без полиморфизма

я постоянно вижу писанину на сяшке в стиле ооп

сяшка небезопасное говно, точка

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

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

ну меня больше порадовало что уолтер переживает за industry и пометил баги, которые ему накидали там челы как критичные.

ты можешь на плюсах писать просто, консистентность - вещь крайне размытая

Ну вот тут и проблема. Иметь для продакшена кодовую базу, где часть написана в стиле С, часть нахуярена классическим ООП, где-то неистовые шаблонные колдунства, а где-то на лямбдах в функциональном стиле наебашено и все это присыплено бустом и еще сторонними библиотеками - это жеппа, которую поддерживать пиздец. А когда у тебя сишка ты пишешь как на сишке и ничего особо не зафачишь (ну если не устраивать макросные безумия).

Да и go на этом сыграл как раз себе на руку

Ну вот тут и проблема. Иметь для продакшена кодовую базу, где часть написана в стиле С, часть нахуярена классическим ООП, где-то неистовые шаблонные колдунства, а где-то на лямбдах в функциональном стиле наебашено и все это присыплено бустом и еще сторонними библиотеками - это жеппа, которую поддерживать пиздец. А когда у тебя сишка ты пишешь как на сишке и ничего особо не зафачишь (ну если не устраивать макросные безумия).

поменяй местами сяшку и плюсы, смысл не поменяется.

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

поменяй местами сяшку и плюсы, смысл не поменяется.

Поменяется, на сишке куда меньше способов отстрелить себе ноги. Да, оче небезопасная работа с указателями (valgrind чертовски хорошо на сишке работает), а в остальном - там больше ничего нет, чтобы можно было это зафачить.

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

Поменяется, на сишке куда меньше способов отстрелить себе ноги. Да, оче небезопасная работа с указателями (valgrind чертовски хорошо на сишке работает), а в остальном - там больше ничего нет, чтобы можно было это зафачить.

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

Хуевый код везде легко писать. Но представь у тебя отлично написанный код, но в миллионе разных стилей, которые разрешает С++. Чтобы найти баг в этом придется обкладываться всеми книжками Мейерса.

Хуевый код везде легко писать. Но представь у тебя отлично написанный код, но в миллионе разных стилей, которые разрешает С++. Чтобы найти баг в этом придется обкладываться всеми книжками Мейерса.

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

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

Ну по крайней мере сам язык не настолько богатый на сокровища и ловушки

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

Ну по крайней мере сам язык не настолько богатый на сокровища и ловушки

ну тогда пиши на брейнфаке там вообще никаких ловушек нет и синтаксис суперпростой.

Возможностей маловато

))

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

дишка с такими аргументами даже еще хуже плюсов получится :)

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

Что подтверждает тезис что ООП это годная и естественная концепция)

А то ходют всякие и говорят что это тупиковая ветвь эволюции

Что подтверждает тезис что ООП это годная и естественная концепция)

нормальная концепция. естественная для человека.

дишка с такими аргументами даже еще хуже плюсов получится :)

Ну всм излишняя сложность D в некоторых местах меня тоже не радует (с квалификаторами доступа просто ебанина). Но D более-менее однородный и продуманный.

Видали там уже хотят вводить модификатор @gc ? =)

Чтобы типа если @nogc: помечены пару десятков функций и одной вдруг понадобилось аллоцировать, то можно ее пометить как @gc

нормальная концепция. естественная для человека.

Для человека - да, для компьютеров - уже хуже. Вообще меня радует ООП в языках с динамической типизацией, как в питоне, в перле, прости господи js. Никакой этот мути с хитрыми схемами наследования (protected-наследование еб вашу мать, Страуструп возьми себя в руки), ограничениями доступа, const функции, статик функции. Короче классы - это ошибка. А язык мечты для меня - гошка с дженериками, компайл-тайм и рефлексией из D. И c UFCS.

а в чем гошка лучше ди (кроме большого кол-ва библ)?

Для человека - да, для компьютеров - уже хуже. Вообще меня радует ООП в языках с динамической типизацией, как в питоне, в перле, прости господи js. Никакой этот мути с хитрыми схемами наследования (protected-наследование еб вашу мать, Страуструп возьми себя в руки), ограничениями доступа, const функции, статик функции. Короче классы - это ошибка. А язык мечты для меня - гошка с дженериками, компайл-тайм и рефлексией из D. И c UFCS.

В JS не ООП, а ПОП

ПОП вообще на другом немного

а в чем гошка лучше ди (кроме большого кол-ва библ)?

ГОРУТИНЫ, ну и в целом очень ПРОДУМАННО и красиво вышло. Я не говорю, что она лучше, но просто в силу обстоятельств для создания гошки выделили огромные средства и поддержку, это тщательно спроектированный заказ со строгими правилами и ограниченими, поэтому вышло очень здорово. А D развивается стихийно и на энтузиастах - это наносит свой отпечаток.

у них прям какая то киллерфича по сравнению с файберами теми же?

У них киллерфича в том что абсоютно вся библиотека и все вызовы заточены под мультитрединг и горутины

Ничего нигде никогда не блокируется, а если горутина начинает блокировать то ее планировщик уносит на другой тред и освобождает место для других горутин

И все это интегрировано во всей экосистеме всех библиотек.

у них прям какая то киллерфича по сравнению с файберами теми же?

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

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

Ну собственно vibe-core и пытается это реализовать и кода там дохренищща )

а вот интересно - если горутина должна слушать одновременно на сокете и на канале - это работает?

ERROR: S client not available

каналы там - сделаны на мутексах и прочей синхронизации, мультиплексировать io можно только в ядре. как-то это скрещивается без дикой потери перформанса?

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

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

Ну наверное не может

Но можно же создать 2 горутины, одна занимается сокетом, вторая каналом :)

И никто никого не будет блокировать

они должны житьт в разных тредах тогда

Зачем?

Чому не может? select же.

ну есть тред внутри которого выплняются горутины. так?

Там же слушание сокета неблокирующее, как и канала тоже

ну есть тред внутри которого выплняются горутины. так?

Да

одни из них ждут ввода через ‘select'

а другие ждут ввода из каналов

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

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

И все это повторяется пару миллионов раз в секунду.

for { select { case c <- mychan: делаем штуки default: conn, err := listener.Accept() ... } }

то ест ьпостоянный полл по тысячам сокет своими средсвами? это не масштабируется

то ест ьпостоянный полл по тысячам сокет своими средсвами? это не масштабируется

Ну там не свои средства, а какая-то магия которая вообще не жрет ресурсов почти.

(для меня магия, я не знаю как оно устроено точно)

то ест ьпостоянный полл по тысячам сокет своими средсвами? это не масштабируется

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

В то время как создать миллион тредов будет убийственно для системы )

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

Ну сейчас же даже в ядре линукса какие-то инновации для poll систем вводились недавно

я например понимаю что можно сделать пайп и в него писнуть так, что-бы select/poll проснулся

кстати вот эта часть default: conn, err := listener.Accept() может висеть в другом треде наверное

https://habrahabr.ru/post/333654/

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

https://habrahabr.ru/post/308070/

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

Спасибо, посмотрю, интересно как они устроились