The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сравнение производительности сетевого драйвера в вариантах на 10 языках программирования

12.09.2019 10:47

Группа исследователей из немецких университетов опубликовала результаты эксперимента, в ходе которого на разных языках программирования было разработано 10 вариантов типового драйвера для 10-гигабитных сетевых карт Intel Ixgbe (X5xx). Драйвер работает в пространстве пользователя и реализован на языках C, Rust, Go, C#, Java, OCaml, Haskell, Swift, JavaScript и Python. При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка. По функциональности все варианты идентичны и состоят примерно из 1000 строк кода. Наработки проекта распространяются под лицензией BSD.

Вариант драйвера на языке Rust оказался очень близок по производительности к эталонному драйверу на языке Си. При нагрузке с единовременной отправкой блоков по 32 пакета Rust-драйвер немного отставал, но в тестах с более чем 32 пакетами в блоке по скорости практически не отличался от драйвера на Си и демонстрировал производительность на уровне обработки 28 млн пакетов в секунду на сервере с CPU Xeon E3-1230 v2 3.3 GHz.

Следующую нишу по производительности заняли драйверы на языках Go и С#, которые показали достаточно близкие результаты (драйвер на Go выигрывал в тестах с блоками, включающими до 16 пакетов, и стал немного проигрывать в тестах с более чем 16 пакетами в блоке). При 256 пакетах в блоке пиковая производительность драйвера на C# составила примерно 28 млн пакетов в секунду, а драйвера на Go примерно 25 млн пакетов в секунду.

Далее с достаточно близкими результатами следовали драйверы на Java, OCaml и Haskell, которые уже заметно отставали от ранее рассмотренных вариантов и не смогли преодолеть планку в 12 млн пакетов в секунду. Ещё большее отставание показали драйверы на Swift и JavaScript, которые смогли обработать потоки на уровне 5 млн пакетов в секунду.

Замкнул рейтинг драйвер на языке Python, который смог обработать всего 0.14 млн пакетов в секунду. Реализация на Python была использована для оценки скорости работы интерпретаторов без JIT и без специфичных оптимизаций (код выполнялся с использованием CPython 3.7 и не был совместим с PyPy, но отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз).

Дополнительно были проведены тесты на время задержки, которые показывали эффективность буферизации и влияние сборщика мусора. При тестировании измерялась задержка после перенаправления каждого пакета драйвером по сравнению с точно известным временем отправки. Лидерами по-прежнему стали драйверы на Си и Rust, результаты которых были практически неотличимы для потока в 1 млн пакетов в секунду (примерно 20 µs). Хорошо проявил себя драйвер на языке Go, который лишь немного отстал от лидеров и также держался на уровне 20 µs. Драйвер на C# показал задержки примерно в 50 µs. Самые большие задержки показали драйверы на JavaScript и Java (задержки более 300 µs).

Исследование проведено с целью оценки возможности разработки драйверов и компонентов операционной системы на языках более высокого уровня, чем Си. В настоящее время 39 из 40 проблем при работе с памятью в Linux приходятся на драйверы, поэтому вопросы применения более безопасного языка и выноса драйверов из ядра в пространство пользователя остаются актуальными и производители уже активно экспериментируют в этом направлении (например, Google разработал TCP-стек для ОС Fuchsia на языке Go, компания CloudFlare создала реализацию протокола QUIC на языке Rust, компания Apple перенесла TCP-стек на мобильных устройствах в пространство пользователя).

В ходе проведённой работы сделан вывод, что язык Rust является лучшим кандидатом для разработки драйверов. Предоставляемые в Rust возможности позволяют избавиться от проблем, возникающих из-за низкоуровневой работы с памятью, ценой снижения производительности примерно на 2%-10% по сравнению с драйверами на языке Си. Языки Go и C# также признаны пригодными для создания системных компонентов, в ситуациях когда приемлемы задержки на уровне долей миллисекунд, вызванные применением сборщика мусора.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Фреймворк для написания защищённых драйверов для ядра Linux на языке Rust
  3. OpenNews: Оценка способности сетевого стека Linux обрабатывать миллион пакетов в секунду
  4. OpenNews: Эксперимент по настройке Linux для блокирования 10 млн пакетов в секунду
  5. OpenNews: CloudFlare применил NetMap для повышения скорости обработки пакетов в Linux
  6. OpenNews: Intel представил сокращённый вариант сетевого стека для Linux
Лицензия: CC-BY
Тип: Тема для размышления
Ключевые слова: driver, benchmark, rust, golang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (299) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, заминированный тапок (?), 11:23, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    о, ну так в конечном счёте всё будет переписано на C# ? (и раст тоже)
     
     
  • 2.2, заминированный тапок (?), 11:25, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    как там был один из доводов (в прошлой статье про написание драйверов в Linux на Rust): "...для команд у которых нет достотачных ресурсов для тестирования кода..." или как-то так

    так от C# эффективные менеджеры вообще в экстазе будут

     
     
  • 3.4, Аноним (4), 11:29, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > для команд у которых нет достотачных ресурсов

    При наличии рынка труда проблема достаточных ресурсов не существует.

     
     
  • 4.46, anonymous (??), 12:18, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +11 +/
    А деньги на найм этих людей для тебя уже не ресурс?
     
  • 4.72, rshadow (ok), 13:20, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То есть переводя на человеческий: при наличии спроса, предложения всегда будут?
    Или даже проще: если все хотят бентли, то конечно все их получат. Да?
    </sarcasm>
     
     
  • 5.83, Попугай Кеша (?), 13:38, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, но игрушечные
     
  • 4.101, Аноним (101), 14:53, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какого именно рынка труда, уточни.

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

     
  • 4.276, Anti pythorust (?), 15:28, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > (код выполнялся с использованием CPython 3.7 и не был совместим с PyPy, но отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз).

    это как там получается 0 на 10 надо умножить?

     
  • 3.5, заминированный тапок (?), 11:30, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    *точнее не драйверов, а модулей ядра*
     
     
  • 4.100, Аноним (100), 14:51, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Рад, что СИ - лидер. Нужность раста по-прежнему остаётся крайне туманной.

     
     
  • 5.118, заминированный тапок (?), 16:37, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +13 +/
    это то да, но ты на опенете такое громко не кричи, а то и тебя перепишут на расте
     
     
  • 6.207, Адекват (ok), 06:54, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ваша фраза, сэр, заставила вспомнить сериал, который я смотрел в глубоком детстве еще на черно-белом ламповом телевизоре, он назывался "капитан пауэр и солдаты будущего". Там людей в прямом смысле в цифровой код переводили. Вот и сейчас с развитием всякого рода нейроных сетей нашу личность можно воплоить в цифре (очень-очень приблизительно), и да, ради эффективности можно воплотить и расте, но лучше на СИ :)
     
     
  • 7.214, Коньвпальто (?), 08:13, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему же, я вот этот топик прочитал и процентов 15 отписавшихся спокойно могу, как кодеров, одной цифрой оцифровать :) без потери их качеств и вы эту цифру знаете. Кстати, спасибо за название, одно время пытался вспомнить как же он назывался.... По 2*2 вроде шел когда-то, пойду поищу посмотреть..
     
  • 5.129, Anon_Erohin (?), 17:51, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Да, да, давайте лучше продолжать писать дырявые программы из-за стек оверфлоу, буфер овверан и так далее, да и еще вместе мемори ликами... А потом еще команды нанимать чтобы такой код вычистить.
    Если писать сейчас начинать - то только на Rust, этот тест тому доказательство.

    Вы с С возитесь как те луддиты в конце 19 века, бросьте труп, надо уже понимать что времена те прошли.

     
     
  • 6.196, Аноним (196), 23:05, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если писать сейчас начинать - то только на Rust

    Что, когда мозилловцы наиграются с растом, переписывать на что-то другое?

     
     
  • 7.259, JL2001 (ok), 21:07, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Если писать сейчас начинать - то только на Rust
    > Что, когда мозилловцы наиграются с растом, переписывать на что-то другое?

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

     
  • 6.210, Адекват (ok), 07:15, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы с С возитесь как те луддиты в конце 19 века, бросьте
    > труп, надо уже понимать что времена те прошли.

    А что, сделать СИ удобным и безопасным нельзя ?
    Может просто написать rust.h и делать #include <rust.h> и в СИ все будет так же хорошо, удобно и надежно как в rust но без rust ?

     
  • 6.226, заминированный тапок (?), 10:40, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    то фактически все ядра известных ОС (не свитяа Redox, конечно же гг) - один болшой memleak ? мда, что называется, "этому миру нужен супергерой". вроде такого смузи-ыксперта вроде тебя
     
  • 5.185, Аноним (185), 21:52, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Нужность раста по-прежнему остаётся крайне туманной.

    О, свидетели сегфолта подъехали

     
     
  • 6.227, заминированный тапок (?), 10:42, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    так и вижу Rаспятие на крыше их общины
     
  • 2.28, Аноним (28), 11:56, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    С# принудительно за гранты продвигаемый язык. В техническом плане нет никакого смысла его использовать.
     
     
  • 3.74, Аномномномнимус (?), 13:26, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сначала похороните Java и всякое бейсико-паскалевское, по сравнению с ними даже C# великолепен
     
     
  • 4.84, Аноним (28), 13:47, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Это цитата из рекламного буклетика от MS? Очень похоже.
     
     
  • 5.122, neAnonim (?), 17:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет. Мы студенты и это цитата из спец гайда.
     
     
  • 6.143, Аноним (28), 18:25, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это понятно. Далеко не всякий студент способен на самостоятельное мышление.
     
  • 3.151, Gemorroj (ok), 19:04, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    что конкретно не так с C#? религиозные штуки? с эстетической/технической точки зрения он вполне ок.
     
     
  • 4.174, Аноним (28), 20:49, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    С технической и экономической точки зрения. Когда ты создаешь решения на продуктах с открытым исходном кодом. Плюс переносимость конечно и мобильные девайсы. Сегодня госы, банки и крупный бизнес топит за такие решения, а они не строятся на продуктах от MS.
     
     
  • 5.178, конь в пальто (?), 21:00, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вообще-то с точностью до наоборот, крупный заказчик готов платить за проприеритарщину. говорю так, потому как работал с госами и банками.
     
     
  • 6.260, JL2001 (ok), 21:26, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > вообще-то с точностью до наоборот, крупный заказчик готов платить за проприеритарщину.
    > говорю так, потому как работал с госами и банками.

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

    (а тендеры это полный мрак)

     
  • 5.186, Илья (??), 21:57, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > на продуктах с открытым исходном кодом.

    .net core открыт, я ж недавно с гитхаба кидал исходник ГЦ сюда

    > Плюс переносимость и мобильные девайсы.

    Xamarin native

     
  • 5.225, заминированный тапок (?), 10:33, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты не поверишь, но даже разработчики Unity и Unreal Engine 4 (в котором система сборки подвязана на Mono) с тобой категорически не согласятся. не считая кучи Xamarino-водов и dotNET-товодов
     
  • 4.202, SRM (?), 02:22, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там определенно что-то не так с думалкой на основании того что в его умозаключении нет логики, как у некоторых отметившихся , с шарпом все в порядке, язык хороший.
     
  • 3.209, Anonymoustus (ok), 07:07, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > С# принудительно за гранты продвигаемый язык. В техническом плане нет никакого смысла
    > его использовать.

    Пока жабья IDE запускается, кодер на Сисярпе напишет, отладит и запустит в продакшын 3,5 программы.

     
  • 3.217, VEG (ok), 09:01, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    C# на порядок лучше Java как язык, он даёт очень много инструментов для оптимизации. Поэтому и быстрее. Смиритесь. Иногда MS делает хорошие продукты.
     
     
  • 4.253, Аноним (253), 18:19, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Понимаете, ваше знание Шарпа и незнание Явы не делает первый лучше второй. Ява и Шарп, в общем-то, одинаково плохие языки. Причём, Ява раньше была лучше. А после 8-ки стала такой же плохой, как и Шарп.
     
     
  • 5.272, VEG (ok), 10:55, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я вообще C/C++-разработчик, но имел возможность попрограммировать и на C#, и на Java.

    C# — это учли ошибки Java (так как была возможность изучить её опыт), поработали над оптимизацией (те же дженерики в Java нормальные так и не завезли за столько лет), дали богатый набор инструментов для программистов, которые понимают разницу между стеком и кучей (например, stackalloc позволяет память на стеке выделять). В C# без смены языка в unsafe-блоках можно даже с C-подобными указателями работать, со всеми их плюсами в производительности и минусами в возможности случайно отстрелить себе конечности. Но если в коде вдруг есть какой-то очень чувствительный к производительности фрагмент — всегда есть возможность оптимизировать его, оставаясь в рамках C#, а не переписывая код на C/C++ и вызывая его из основной программы. Хотя, смешивать C/C++ и C# в одной программе тоже очень удобно, если нужно — MS тут тоже постаралась на славу, добавив расширения в C++ для прозрачной работы с объектами из мира .NET.

    А вообще, больше всего в Java меня раздражало банальное отсутствие нормальных signed/unsigned интов на выбор, это же кошмар, они своего среднего разработчика совсем за идиота что-ли держат, который не сможет разобраться с знаковыми и беззнаковыми интами? =)

     
  • 4.261, JL2001 (ok), 21:30, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > C# на порядок лучше Java как язык, он даёт очень много инструментов
    > для оптимизации. Поэтому и быстрее. Смиритесь. Иногда MS делает хорошие продукты.

    это что за инструменты оптимизации такие волшебные? можно компилятору/jit-у что-то подсказать?

     
     
  • 5.265, Аноним (265), 00:54, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Например, value-типы, unsafe с указателями и другой низкоуровщиной, P/Invoke для вызова функций в нативных библиотеках без промежуточных обёрток а-ля JNI.
     

     ....большая нить свёрнута, показать (37)

  • 1.3, iPony129412 (?), 11:27, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    Эксперты Opennet наверно опечалены, что паскаля нет 😃
     
     
  • 2.6, Аноним (6), 11:30, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Bash.
     
     
  • 3.164, Antonynus (?), 20:02, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    вместо него петон
     
  • 2.7, Аноним (4), 11:30, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Да не-е-ет. Дельфи же. Паскаль - это то, от чего их универские преподы пёрлись.
     
     
  • 3.66, Аноним (66), 12:57, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так он и создавался как язык для обучения программированию
     
     
  • 4.75, Аномномномнимус (?), 13:27, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Создавался-создавался, да не высоздался. Есть Python для обучения
     
     
  • 5.169, Led (ok), 20:38, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Обучение программированию, а не мастурбации.
     
  • 2.13, Catwoolfii (ok), 11:37, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Плюсов тоже нет...
     
     
  • 3.48, Аноним (48), 12:25, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    да и кроме C одни минусы...
     
  • 2.62, Alen (??), 12:52, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +11 +/
    К сожалению нет реализации на ассемблере
     
     
  • 3.216, Аноним (216), 08:53, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для какого именно процессора вас интересует ассемблер?
     
     
  • 4.223, Аноним (223), 10:00, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    из новости CPU Xeon E3-1230 v2 3.3 GHz
     
  • 4.224, Alen (??), 10:03, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Для какого именно процессора вас интересует ассемблер?

    Решил блеснуть эрудицией? Тогда тебе должно быть извесно, что проц выбирается под задачу. В статье у парней была задача СРАВНИТЬ производительность программ. Соответственно главное не то, на каком, а то, чтоб на нем запустились все написанные варианты.

    P.S Ну и удачи вам конечно в добывании железа в которое можно вставить сетевую карту описанную в статье, с архитектурой отличной от x86 или AMD64

     
     
  • 5.228, InuYasha (?), 11:34, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А в ARM-машинах разве нет PCI-express?
     
     
  • 6.248, Alen (??), 15:00, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я не сказал, что нет, но добыть такое железо - интересный квест  :)
    А запускать тесты в эмуляторе - не будут показательны в плане сравнения
     
  • 2.124, pda (?), 17:15, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Куда больше прикалывает, что кого-то от паскаля столь припекает, что над ним продолжают глумиться лет двадцать спустя, как утихли холивары про него.
     
     
  • 3.161, soarin (ok), 19:47, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > от паскаля столь припекает, что над ним продолжают глумиться лет двадцать спустя, как утихли холивары про него.

    ну да, ну да... https://www.opennet.ru/openforum/vsluhforumID3/118392.html#16

     
  • 2.166, Аноним (166), 20:06, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Go есть.
     

  • 1.8, Аноним (28), 11:32, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Какая-то ангажированная муть.
    C# не может быть настолько быстрее Java, Swift, OCaml, по той простой причине, что он не быстрее.
     
     
  • 2.21, Аноним (21), 11:51, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В неокрепших умах, наверное, C# все же не быстрее Java и пр.
     
     
  • 3.32, Аноним (28), 12:03, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не быстрее. Смысл его использования вообще стремится к нулю. Только постоянно вливаемое бабло в его пиар создает видимость его востребованности.
     
     
  • 4.78, Аномномномнимус (?), 13:28, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты сейчас полностью описал историю приобретения популярности у Java
     
     
  • 5.81, Аноним (28), 13:36, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Java не нуждается в популяризации, она прочно удерживает определенные ниши. Это ее недокопию пытаются везде втюхивать, ибо за так нафиг никому не нужна.
     
     
  • 6.142, Аномномномнимус (?), 18:24, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Лол. А как по твоему это безобразие получило популярность в "определённых нишах"? Долго пиарили, втюхивали всем подряд и ездили по ушам, всё по вышеуказанной методике. Чуда не случилось
     
     
  • 7.157, Аноним (28), 19:36, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кому что впаривали Бизнес посчитал деньги и принял на вооружение По сути тоже ... текст свёрнут, показать
     
     
  • 8.188, Илья (??), 22:08, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    rider одинакого запускается как на linux, так и на macos исполняемая среда ест... текст свёрнут, показать
     
     
  • 9.263, JL2001 (ok), 21:43, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сколько лет этому одинаково вот прям щас - возможно... текст свёрнут, показать
     
  • 8.222, Аномномномнимус (?), 09:29, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Бизнес развесил уши и в 2002-2003 особо деффективные манагеры, в основном банков... текст свёрнут, показать
     
  • 7.262, JL2001 (ok), 21:40, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Лол. А как по твоему это безобразие получило популярность в "определённых нишах"?
    > Долго пиарили, втюхивали всем подряд и ездили по ушам, всё по
    > вышеуказанной методике.

    кросплатформенность, неплохой сам язык, легко учить, легко писать, при этом достаточно быстрый, дофига всяких нужных энтерпрайзу либ, отличная IDE (у c# была сильно хуже)
    я не видел особой рекламы и втюхивания, выбор был java/c# и как только слышали "высоконагруженный отказоустойчивый сервер на винде" - выбирали жаву и невинду

     
  • 5.86, Аноним (28), 14:00, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Популярность Java приобрело как решение удешевляющее разработку ПО. Единственное, на начальном этапе у нее была очень унылая производительность.
     
     
  • 6.119, заминированный тапок (?), 16:44, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    на начальном этапе... а на следующем этапе осталась такой же
    просто железо доросло до ей потребностей

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

     
     
  • 7.168, Аноним (28), 20:23, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    JIT появился не сразу. Так же на протяжении всего времени вносились оптимизации.

    По второму пункту - да, это вносит некоторый оверхед, но не критично.

     
  • 7.197, Аноним (196), 23:09, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > динамическая природа примитивных типов и полное остуствие статики

    Что под этим подразумевается?

     
     
  • 8.292, Аноним (292), 22:20, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Под этим подразумвается, что https openjdk java net projects valhalla всё ещё... текст свёрнут, показать
     
     
  • 9.299, Аноним (265), 03:06, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И каким образом аллокации в куче относятся к динамическая природа примитивных т... текст свёрнут, показать
     
  • 6.170, Led (ok), 20:40, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > на начальном этапе у нее была очень унылая производительность.

    И этот "начальный этап" продолжается и прогрессирует.

     
  • 2.35, leap42 (ok), 12:07, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.htm

    M$ подкупила Debian через своих наймитов RH (IBM)? А может просто шапочка из фольги обзор закрывает?)

     
     
  • 3.47, Аноним (28), 12:21, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тест-то сами смотрели? Где преимущество в скорости у C#?

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

    Также производительность зависит от сборщика мусора. Под JVM их есть несколько штук.

    Поэтому не следует очаровываться насчет C#. По сравнению с JVM он обладает только известными недостатками. Кто его использует сам на себя накладывает ограничения.

     
     
  • 4.67, Аноним (67), 12:59, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По сравнению с JVM он обладает ещё и известными (не вам) преимуществами. Например, большим количеством низкоуровневых обёрток. Поэтому в драйвере на C# 39 строк кода на С, а в драйвере на жавке куда больше.
     
     
  • 5.77, Аноним (28), 13:28, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это частный случай, не меняющий общего тренда. При необходимости можно скомпилять нативно либу и дергать, что собственно и разумней всего сделать если вы хотите высокую производительность без оговорок.
     
     
  • 6.145, Аноним (21), 18:37, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    При необходимости можно и на ассемблере написать. Здесь же  рассматривается другой случай, а именно тот, которым является заголовок статьи. Читаем внимательно и без "необходимости".
     
     
  • 7.159, Аноним (28), 19:39, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Без необходимости можно написать на чем-то другом. Осваивать бесперспективный язык ради написания драйвера, как-то глупо что ли.
     
  • 5.200, Аноним (196), 23:45, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > преимуществами. Например, большим количеством низкоуровневых обёрток.

    А ещё дженериками без type erasure, value-типами, перегрузкой операторов (не всем нравится, но лично я предпочитаю читать/писать 'a + b * c' вместо чего-то вроде 'a.add(b.mul(c))', и, чем сложнее формула, тем трэшовее вариант с "обычными" методами), паттерн матчингом, именованными и опциональными параметрами методов, async-await и другими ништяками, появление которых в Java находится, в лучшем случае, на стадии планов и обсуждений. Дотнет можно ругать за некоторую завязанность на MS вообще и винду в частности, по части языковых фич он давно обошёл жабу.

     
  • 3.167, Аноним (167), 20:08, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, в этих бенчах отражено ожидаемое поведение. Если запускать программу очень много раз на 5 секунд и каждый раз очищать файловый кеш между запусками.
     
  • 3.219, Аноним (265), 09:24, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Открываем тест regex-redux с самой большой разницей по времени выполнения и ви... текст свёрнут, показать
     
  • 2.38, Fracta1L (ok), 12:10, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Люблю запах пригоревших догм по утрам
     
     
  • 3.55, Аноним (28), 12:31, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Смотрите с пригоранием поосторожней там, так можно и воспламенится. К ожогам прилагайте рекламные буклеты от MS.
     
  • 2.88, Аноним (88), 14:07, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В Java по любому использовали какой-то легаси stop-the-world GC иначе я не могу объяснить такой слив С-диез не только по throughput, но и по латенси.
     
     
  • 3.97, Аноним (28), 14:32, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет никакого разумного объяснения такого прорыва C# и Go. Тоже подозрения, что тупо тормоза GC или условия тестирования кривые.
     
     
  • 4.99, red75prim (?), 14:43, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Value types в Java есть? Нет. Вот и в исследовании предполагают, что из-за этого.
     
     
  • 5.135, Аноним (28), 18:07, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже реализовано, но не протолкнули в мейнстрим.
    https://medium.com/@ramtop/a-taste-of-value-types-1a8a136fcfe2
     
     
  • 6.189, Илья (??), 22:14, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Кто медиум читает - тот себе зла желает
     
  • 3.136, turbo2001 (ok), 18:09, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже с Epsilon тормозит: https://github.com/ixy-languages/ixy-languages/blob/master/Java-garbage-collec

     
  • 3.149, Dee (??), 18:55, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У них там pdf-ка с разъяснениями есть. В C# есть unsafe блоки, указатели, value типы, можно почти полностью избежать GC. А в Java не выходит избежать, все время аллокации, потому на сборку мусора больше времени уходит.
     
     
  • 4.237, логика (?), 13:16, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    тогда это тест только тех, у кого "не выходит избежать"
     
  • 4.284, Vkni (ok), 18:34, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть техника работы со своими memory pool - выделяете массив, а дальше работаете с ним.

    На Ocaml'е народ из Jane Street занимается автоматическими спекуляциями примерно в этой технике - вполне нормально получается. Я не очень понимаю, почему они пишут low latence программы не на C, но тем не менее.

     
  • 2.107, Аноним (107), 15:21, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > C# не может быть настолько быстрее Java

    Хорошая мантра. Повторяй неустанно.

     
     
  • 3.138, Аноним (28), 18:16, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем повторять. Видел своими глазами как банк переехал C# на Java, весь процессинг был полностью переписан. Сервера перешли на Linux. После чего пазл сложился и наконец-таки все стало работать как следует, стабильно и с достаточной производительностью.

    Такое зрелище будет помощнее любой мантры.

     
     
  • 4.183, funny.falcon (?), 21:43, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > весь процессинг был полностью переписан.

    Думаю, основная причина все-таки в этом. И особо не важно было, что «на Java».

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

    Но убедить руководство переписать с “C# на C#” практически невозможно. А вот перейти на «более стабильную и проверенную технологию» шанс есть.

    Ну и «сервера перешли на Linux» намекает, что это был ещё .Net Framework на Windows. В бумаге же наверняка фигурирует .Net Core, который совершенствуется на глазах и показывает себя молодцом.

     
  • 2.120, фывфывфыв (?), 16:53, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    C# будет быстрее Java в сетевом стеке как минимум потому, что там есть unsigned и на 8-битно число не нужно заводить 16-битное, на 16-битное, 32-битное и т.д. по списку.
     
  • 2.130, КО (?), 17:54, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну если авторы умели писать быстрые программы на C# и не умели на java, то вполне
     

     ....большая нить свёрнута, показать (42)

  • 1.9, Нанобот (ok), 11:33, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +36 +/
    нужно добавить 1С! ...просто чтобы питон не был замыкающим
     
     
  • 2.18, anonymous (??), 11:48, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Но для этого им (немцам) пришлось бы выучить русский язык, а это, кмк, уже слишком :-)
     
     
  • 3.22, ryoken (ok), 11:52, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ходят мифы, что в 1С таки есть англ.яз :D. Но российским 1с-писакам он неизвестен :D.
    Чёт они про жопоскрипт забыли. Ну и ассемблера нету, для полноты веселья :D.
     
     
  • 4.110, MD (?), 15:43, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не миф, наверное. Лет 15 назад для 1С 8 сам писал модуль связи с БД. Визуал бейсик.
     
  • 4.221, 111c (?), 09:27, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    есть то он есть, но переводили имена функций и объектов там "промтом" и буквально, так что ни один здравомыслящий англоговорящий не поймет, или будет ловить лулзы с этих "названий"
     
     
  • 5.308, MD (?), 11:39, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я писал на чистом бейсике.
     
  • 2.76, letsmac (ok), 13:27, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1C как бы не тюринг полный язык.
     
     
  • 3.147, Нанобот (ok), 18:50, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    пруф есть?
     
     
  • 4.236, Аноним (236), 13:14, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чёт сомнительно, потому что даже странный css никогда не предназначенный для программирования является Тьюринг-полным.
    Да что там говорить по css, даже в игре Factorio фанаты делали клон i8080.
     

  • 1.10, Аноним (4), 11:34, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Только C. Недавно свои архивы просматривал. Извлек программу - вьювер снимков для одного из первых отечественных томографов, написанную в 1995 году на языке C для MS-DOS. Запустил в 10-ке. Работает! И даже позволяет картинки захватывать в буфер обмена.
     
     
  • 2.26, proninyaroslav (ok), 11:55, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Может ещё C умеет платформо-зависимые компоненты писать переносимыми? В основном не язык определяет долговечность проекта, а голова и руки программиста.
     
     
  • 3.60, Аноним (60), 12:49, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Видимо на винде было написано. Но скорее всего с прямой работой с WinAPI, вот и совместимо.
     
     
  • 4.109, AnonPlus (?), 15:34, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    16-разрядная DOS-программа? С 64-битными виндами уже несовместимо, там эмулятор WOW16 выпилили давным-давно.

    А в 32=битных запуститсч, чего б нет.

     
  • 2.234, Аноним (-), 12:29, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Программа, написанная на Си под DOS, и работает копирование картинки в буфер обмена Windows 10? Если честно, то верится с трудом (точнее - не верится).
    Может вы имеете ввиду просто скриншот экрана, где помимо прочего есть так же и окно с вашей чудо-программой, которую вы каким-то образом запустили в Win10 (что тоже странно, т.к. ЕМНИП оттуда выпилили режим совместимости с DOS) с заголовком, рамкой и т.д. ?
    Не могли бы вы больше технических подробностей привести?
     
  • 2.293, Аноним (293), 00:34, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Звездобол, откуда в 10-ке поддержка DOS'а?!
     

  • 1.11, Аноним (11), 11:36, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А как же brainfuck?
     
     
  • 2.171, Led (ok), 20:43, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > А как же brainfuck?

    При чём тут твоя жена?

     
  • 2.315, Aninomuz (?), 20:04, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    [-3] + 11 = 14 школоты
    Остальные в курсе.
     

  • 1.12, Аноним (12), 11:36, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +18 +/
    сюда, для полной картины, еще бы статистику по потреблению памяти
     
     
  • 2.43, Аноним (43), 12:13, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Еще время разработки и зп программиста. Для написания драйвера на С привлеки гуру, который на С лабает 20 лет. Фрика на расте, который в немецкий университетах из сабжа был один. И первокурсник который скачал экзампл драйвера на Го и поправил пару переменных.
     

  • 1.14, vitalif (ok), 11:39, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, я стесняюсь спросить - а КАК они написали драйвер сетевой карты на всех языках, кроме C, Rust и Go? На питоне например? Это как вообще?

    Где код посмотреть?

     
     
  • 2.23, аноним3 (?), 11:53, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    написали внешний подгружаемый модуль, работающий примерно как обычная программа в пространстве пользователя. там жек написано
     
     
  • 3.50, ыы (?), 12:27, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > внешний подгружаемый модуль

    написанный на чем?

     
     
  • 4.144, аноним3 (?), 18:32, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я тоже с небольшим оптимизмом отношусь к драйверам на интерпретируемых языках. но они писали на всем)) там же описано. а о внешних подгружаемых модулях полагаю все слышали. еще со времен elf такие существовали. просто опять раст впихали.... ну не знают как и где его пропиарить.
     
  • 2.65, Аноним (65), 12:55, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Где код посмотреть?

    https://github.com/ixy-languages

    Например
    https://github.com/ixy-languages/ixy.py
    https://github.com/ixy-languages/ixy.js

     
     
  • 3.89, vitalif (ok), 14:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А, спасибо, не осознал что отдельные репозитории

    Через mmap и memoryview общаются...

    Офигеть, открытие - до этого я в юзерспейсе видел только Intel DPDK, а он работает через vfio-pci / uio_pci_generic, т.е. через специальный драйвер ядра. А тут вроде напрямую

     
     
  • 4.113, Аноним (113), 16:05, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Главное — никакой низкоуровневой работы с памятью!
     

  • 1.15, freehck (ok), 11:41, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность при использовании OCaml и Haskell?
     
     
  • 2.300, Vkni (ok), 03:36, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность
    > при использовании OCaml и Haskell?

    Смотря как писать, думаю. Вообще, там есть копирование массивов, кмк, излишнее - см.
    https://github.com/ixy-languages/ixy.ml/blob/master/lib/ixy.ml#L580

    https://github.com/ixy-languages/ixy.ml/blob/master/lib/iXGBE.ml#L247 и т.д. немного не идиоматично. По мне лучше бы

      | RDT i when i < 64 -> 0x01018 + (i * 0x40)
      | RDT i ->             0x0D018 + ((i - 64) * 0x40)

    С одной стороны, это идиоматический код, а с другой - там же всё равно DMA, и надо писать аккуратно. С третьей - зачем эмулировать язык C на Ocaml/Haskell? Возможно срезы (Slice), будь они реализованы в камле, помогли бы избавиться от копирования массивов.

    ----------------------------
    По Haskell - ну беглый взгляд говорит, что почему-то не везде newtype стоят, можно директивы INLINE расставить, опять-таки, копирование буфера.

     
     
  • 3.303, freehck (ok), 10:36, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Хотелось бы более детального сравнения с ML. Насколько сильно проседает производительность
    >> при использовании OCaml и Haskell?
    > Смотря как писать, думаю.

    Я думаю, что писать надо, как криворукая обезьяна. То бишь как все.
    Ну, вероятно, копирование буферов там и правда зря. А вот на идиоматиччность наплевать -- никто на неё смотреть не будет.

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

     
     
  • 4.311, Vkni (ok), 16:01, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Я думаю, что писать надо, как криворукая обезьяна. То бишь как все.

    Тогда, в теории, нужен Rust. Но он слишком наворочен. И, конечно, на С удобнее писать - всё-таки С прямо предназначен для таких штук.

    > Если Вы ещё поиграетесь с этим куском кода

    Увы, нет времени.

     

  • 1.16, AlexTedx (?), 11:43, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Rust one love
     
  • 1.17, Аноним (28), 11:43, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто проплатил исследователей, тот и в топе.
    Единственное нельзя было сделать победителем Go или C#, это бы не зашло.
    Где С++?
     
     
  • 2.20, anonymous (??), 11:51, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Там есть ссылки на код: https://github.com/ixy-languages/ixy-languages

    Если на каком-то языке сделано неправильно, то есть смысл предложить PR. Ну или хотя бы поделиться соображениями тут в комментариях.

     
     
  • 3.53, Аноним (53), 12:28, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз

    А что тут предлагать? По моему очевидно какая цена этому «исследованию».

     
  • 3.156, Аноним (167), 19:34, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если на каком-то языке сделано неправильно, то есть смысл предложить PR.

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

     
     
  • 4.163, anonymous (??), 20:01, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    То есть по существу сказать нечего? :)
     
     
  • 5.215, Коньвпальто (?), 08:25, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По существу авторы теста сами отписались, добавить тут абсолютно нечего. Просто одного наличия как минимум двух вариантов и отсутствие асемблера и еще, как минимум, плюсов делает это произведение как минимум похожим скорей на измышления неокрепшего кодера над выбором самого офигенного языка программирования в мире, дабы точно не пролететь с карьерой в мире информационных технологий. Ну пусть ковыряется, жалко чтоль, однозначно плюс к за труд, но с выводами лучше было вот так вот, в открытый мир, пока не лезть ;) ну или хотябы убрать пару вариантов, чтобы не выглядеть клоуном.
     
  • 2.172, Led (ok), 20:45, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Где С++?

    Не провоцируй: честный ответ на опеннете забанят.

     
  • 2.211, Адекват (ok), 07:25, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Где С++?

    Пока все еще компилируется.


     

  • 1.19, th3m3 (ok), 11:50, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Rust - рулит, что и требовалось доказать.
     
     
  • 2.25, Аноним (25), 11:53, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это си рулит. Сорцы открой своего хруста.
     
     
  • 3.39, Zzzzz (?), 12:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Открыл.

    Rust 97.5% Python 0.6% JavaScript 0.4% C++ 0.3% Makefile 0.3% Yacc 0.2% Other 0.7%

     
     
  • 4.41, Аноним (25), 12:12, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Молодец, теперь посмотри как это сделано.
     
     
  • 5.92, Zzzzz (?), 14:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Посмотрел. Все на Rust, иногда дергаются библиотеки типа libc, но дурашка других в линюхах-то нет.
     
     
  • 6.206, Аноним (25), 05:11, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    То есть, если я буду дёргать из js библиотечный код, то можно сказать, что у меня всё на js?
     

  • 1.24, Аноним (25), 11:53, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Драйвер на руст - это unsafe вызовы libc. Короче это - драйвер на си. Растоадепты, как обычно, всё украли и выдали за своё.
     
     
  • 2.106, burjui (ok), 15:18, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Позорище, даже в сорцы не глядел, а такие же безмозглые хейтеры плюсики ставят, ... текст свёрнут, показать
     

  • 1.30, Аноним (30), 11:58, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А можно больше аргументации в пользу раст? - из перевода неясно, почему же такой вывод. Мне интересен раст, но вот именно в драйверах критична скорость, нет смысла переходить с С.
     
     
  • 2.36, Аноним (43), 12:09, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Памятебезопасность. Если у тебя неограниченное количество программистов с опытом на С в железках, тебе не надо.
     
     
     
    Часть нити удалена модератором

  • 4.82, red75prim (?), 13:37, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я вот удивляюсь, зачем в офисах С программистов всякие перила на лестницах, двери в лифтах понатыканы? Где-то даже таблички "мокрый пол" ставят. Внимательно смотри куда идёшь и всё будет в порядке. Unsafe означает: "Наткнулся на перила, подумал и решил, что стоит перепрыгнуть".
     

  • 1.31, Кодер (?), 12:02, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вот ведь в "Одноклассниках" люди мучаются с явой, и не знают, какая она медленная для сетевых задач..
    Исходнички бы посмотреть, как эти тестеры с сетью работали...
     
     
  • 2.34, Аноним (25), 12:05, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну открой да посмотри, исходники есть для всех тестов.
     
     
  • 3.90, Аноним (88), 14:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В исходниках не написано с какими параметрами запускали виртуальную машину.
     
     
  • 4.150, Нанобот (ok), 18:57, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    о да, любимая отмазка свидетелей джавы: джава тормозит не из-за кривизны рук разработчиков, а из-за неправильных параметров запуска ВМ
     
  • 4.160, Аноним (167), 19:44, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Внезапно, так и есть. Авторы Java-версии открыто признают, что не заморачиваются и аллоцируют по объекту на пакет ("we still allocate around 20 bytes on average per forwarded packet"). Т.е. вместо самой программы они бенчмаркают сборщик мусора. А ещё они зачем-то используют Unsafe и volatile-поля, тем самым не давая JVM выполнять большинство оптимизации.
     
     
  • 5.266, Аноним (266), 02:17, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Самый интересный комментарий
     
  • 2.312, Wilem (?), 18:54, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Большинство жаверов кстати действительно не знают, какая она медленная.
     

  • 1.33, Аноним (33), 12:03, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    На эрланге есть?
     
     
  • 2.133, Аноним (107), 18:04, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возьми сишный драйвер, завяжи обмен с устройством на stdin/stdout, прикрути к порту evm и померяй.
    Звучит глупо? Да, потому что эрланг не для этого.
     
     
  • 3.176, Аноним (176), 20:56, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А драйвер на джаваскрипте это не глупо? К тому же я слышал что эрланг используют там где нужно low latency.
     
     
  • 4.239, Аноним (239), 14:05, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не смеши мои памперсы. EVM в усмерть ужирает память и особенно CPU на задаче чутьболее сложной и выходящей из Си рантайма. Так что так только звонки форвардить...
     
  • 4.256, Аноним (107), 19:33, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насчёт low latency не скажу, есть среди его характеристик некая "soft real-time", так это просто возможность сообщить об ошибке, если воркер не вернул результат запроса в течение заданного таймаута.
    Главная фишка Эрланга, как принято считать - в неубиваемости. Ошибки и непредвиденные ситуации возникнут по-любому, а значит давайте не избегать ошибок, а быть к ним готовыми. Отсюда парадигма "Let it crash" - "Пусть грохнется".
     

  • 1.37, mick (??), 12:10, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ерундой занимаются, а ничего что есть специализированый язык Vala для создания кода с безопасной работой с памятью, и компилируемый/интерпретируемый в чистый C, почему то не включили в обзор, случайность ? не думаю ...
     
     
  • 2.93, red75prim (?), 14:14, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А они точно про него слышали? Ищем "LANG_NAME programming language" в гугле. Количество результатов: Vala - 3,740, Ada - 107,000, C - 4,880,000, C# - 721,000, D - 557,000, Nim - 8,990, Rust - 201,000.
     
     
  • 3.301, ф (?), 08:07, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот D интересно увидеть в подобном сравнении.
     

  • 1.40, exSun (ok), 12:11, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну наконец-то https://imgur.com/NFinaiK
     
     
  • 2.44, Аноним (43), 12:15, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зато переносимость.
     

  • 1.49, Ilya Indigo (ok), 12:26, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Где C++ в тестах?
     
     
  • 2.240, Аноним (239), 14:06, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почти все противники С++ в разработке железа и оборудования. Не видать вам классов в драйверах как своих ушей =)
     
     
  • 3.247, Ilya Indigo (ok), 14:18, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я сам противник плюсов в драйверах и низкоуровневых библиотеках, но если эти "утырки", додумались запихнуть в тест решётку, жабу и даже пихон с JS, то отсутствие плюсов можно объяснить не иначе что они добавили их, но они уделали ржавого по всем пунктам, и их пришлось удалить из графика.
     

  • 1.51, Аноним (51), 12:27, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Блин. На JavaScript нельзя писать драйвера. Обидно :(
     
  • 1.54, bvs23bkv33 (?), 12:29, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > язык Rust является лучшим кандидатом для разработки драйверов

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

     
     
  • 2.230, Аноним (223), 11:48, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ох уж эти мифические нормальные си-программисты, которые никогда не ошибаются. Пока твой нормальный си-программист будет ошибки отлавливать в своем драйвере, растовый нормальный программист напишет десяток работоспособных приблуд с минимумом ошибок.
     

  • 1.56, Аноним (56), 12:34, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Замкнул рейтинг драйвер на языке Python, который смог обработать всего 0.14 млн пакетов в секунду.

    GIL всех схоронил

     
     
  • 2.63, Аноним (53), 12:53, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, почитай новость, они _специально_ сделали драйвер на питоне самым медленным.
     
     
  • 3.79, rshadow (ok), 13:31, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    По всей видимости они просто ниасилили написать на питоне. Но ведь это же такой простой язык на котором напишет и макака...
     
     
  • 4.108, Аноним (108), 15:22, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Недавно делал программу на питоне с хитрым перемножением-сложением матриц. Работает, но медлено. Переписал с использованием фич питона, с использованием list-ов,  yielld-ов и zap-ов. Не помогло. Переписал, заменив всё вызовами numpy. Ускорилось на 3 порядка.

    Вывод: оптимизации в питоне — вещь неочевидная.

     
     
  • 5.115, Crazy Alex (ok), 16:16, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вывод - использовать нативный код, что и было сделано с numpy
     
  • 5.141, rshadow (ok), 18:23, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Про то и речь, что написали вычислительное ядро на Си. И обернули питоном.
     
     
  • 6.162, nobody (??), 19:58, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    numpy использует библиотеки blas / openblas , в большой части написанные на фортране (например https://github.com/xianyi/OpenBLAS/wiki/Installation-Guide)
     
     
  • 7.264, Ушастый (?), 22:10, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не порите чушь, ей больно. Исторически BLAS действительно был написан на фортране, но сейчас от фортрана там остался только API (которым и не пользуется никто, все давно переехали на сишное API, CBLAS). Тот же OpenBLAS написан на сях с ассемблерными вставками, SSE и AVX для выжимания каждой капли производительности из железа.
     

  • 1.57, анонимумуму (?), 12:37, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка.
    > Реализация на Python была использована для оценки скорости работы интерпретаторов без JIT и без специфичных оптимизаций (код выполнялся с использованием CPython 3.7 и не был совместим с PyPy, но отмечается, что оптимизация структур хранения данных могла бы повысить производительность примерно в 10 раз).

    Мне одному кажутся эти два абзаца противоречащими друг другу?

     
     
  • 2.59, анонимумуму (?), 12:39, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А, ну понятно.

    > Performance is not the primary goal of this (Pytohn - прим. меня) version of our driver, it is the only implementation presented here that is not explicitly optimized for performance. It is meant as a simple prototyping environment for PCIe drivers and as an educational tool

     
     
  • 3.80, rshadow (ok), 13:34, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    То есть, если использовать еще один вариант питона, и подключить нормальные Си библиотеки, то он тоже сможет потягаться.
     
     
  • 4.181, Dnina (ok), 21:24, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Получается, что питонистам нужно знать си, чтобы писать на нём библиотеки для питона, если нет нужного функционала?
     
     
  • 5.212, Коньвпальто (?), 08:03, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Получается, что питонистам как я и яваскриптистам с явистами, в целом вообще незачем писать дрова для сетевых карт. Это все равно что шуруповертом гвозди забивать. Ну да, возможно, в принципе и, наверное, весело.
     
  • 3.105, Аноним (105), 15:14, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тестирование производительность, но этот вариант мы делаем без прицела на производительность. Не то что бы я за дрова на питоне, но это какой-то бред.
     
     
  • 4.158, a3k (?), 19:37, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так ни у кого не было сомнений, что чисто интерпретируемый язык будет работать медленно.
     
     
  • 5.213, Коньвпальто (?), 08:05, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут не всем это очевидно, это очевидно.
     

  • 1.58, anonismus (?), 12:38, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > almost matches the speed of the C implementation but with the added features of Go (~10% performance loss, depending on batch sizes and CPU speed)

    Как я и говорил, у Go оверхед в 10-15%, если писать оптимально.

     
     
  • 2.180, qwerty123 (??), 21:16, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/

    >Как я и говорил, у Go оверхед в 10-15%, если писать оптимально.

    А если писать на С, то вообще нет.

     
     
  • 3.231, Аноним (223), 11:50, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...но вместо оверхеда появляется букет ошибок, некоторые из которых находятся и фиксятся через десятилетия.
     
  • 3.233, Ordu (ok), 12:17, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть там оверхед https github com ixy-languages ixy-languages blob master Rus... текст свёрнут, показать
     

  • 1.61, Leo90 (?), 12:51, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    minix3 уже все сделал.
     
     
  • 2.241, Аноним (239), 14:08, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А не Rustовый Redux все уже сделал
     

  • 1.64, anonismus (?), 12:53, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Предоставляемые в Rust возможности позволяют избавиться от проблем, возникающих из-за низкоуровневой работы с памятью,

    Через использование 49 unsafe блоков с низкоуровневой работой с памятью? Классно избавились, зачёт.

     
     
  • 2.71, Аноним (43), 13:17, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Раст более безопасен. Но не полностью) Читай впитывай https://news.ycombinator.com/item?id=16962551
     
  • 2.87, Аноним (87), 14:01, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    unsafe используется для взаимодействия безопасного кода rust с "внешним миром", здесь - API ядра Linux.
    Для желающих разобраться с unsafe есть https://doc.rust-lang.org/nomicon/index.html
     
  • 2.95, kiwinix (?), 14:20, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дело в том, что когда ты используешь unsafe ты знаешь что на самом то деле оно безопасно..

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

    Поэтому да, так безопасно

     
     
  • 3.102, Александр (??), 15:06, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Дело в том, что когда ты используешь Си ты знаешь что на самом то деле оно безопасно..
    Типа ты понимаешь что творишь.
    Это как указатель что "я знаю что тут возможно выйти за границы буфера, но этого по моему индексу никогда не случится"

    Поэтому да, так безопасно

     
     
  • 4.104, red75prim (?), 15:13, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дело в том, что когда ты пишешь каждую строчку на Си ты знаешь что на самом то деле оно безопасно..

    Это как указатель "Я - супермен, я - делаю в 500 раз меньше ошибок, чем всякие там прочие".

    Поэтому да, так безопасно

     
     
  • 5.116, ixrws (??), 16:24, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот это очень странно слышать от вроде как специалистов Понятно, когда речь идё... текст свёрнут, показать
     
     
  • 6.139, red75prim (?), 18:21, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Программисты режут пальцы в основном юзерам, это не так чувствуется и ощущение полноты контроля и эффективности инструмента есть.
     
  • 6.152, Dee (??), 19:07, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да замучались просто CVE латать. Уж сколько пишут-пишут, исправляют-исправляют, даже самые специалисты, а все равно дырка за дыркой обнаруживается, и в большинстве случаев - именно некорректная работа с памятью. Вот и решили что-то кардинально поправить, сколько можно дырками дырки латать.
     
     
  • 7.190, Андрей (??), 22:19, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так ведь же без хлеба останутся.
     
     
  • 8.242, Аноним (239), 14:10, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не посмотри на синтаксис и сложность Rust там еще и на икру можно ... текст свёрнут, показать
     
  • 6.192, Илья (??), 22:35, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > голосуют за безопасные инструменты жертвуя эффективностью

    Ясен день, деньги же считаем и данные обрабатываем.

     
     
  • 7.243, Аноним (239), 14:10, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Жаль что не все деньги сосчитаны и не все обработаны,
    но у конкурентов будет лучше не преживайте
     
  • 6.194, Ordu (ok), 22:47, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Эта позиция, мол если взять достаточно квалифицированных C программистов, то не будет проблем с памятью -- это очень старая позиция, и она в общем разрушена. Особо упёртые продолжают стоять на руинах и по принципу "ссы в глаза -- божья роса" талдычить одно и то же, мол ищите специалистов.

    Если ты не веришь, покажи мне какую-нибудь из своих программок на C, размером от 10k строк, я потрачу выходные и найду тебе там проблемы с памятью или UB. Ну, это на тот случай, если ты думаешь что ты являешься примером C программиста, который не совершает ошибок, то я покажу тебе, что ты ошибаешься как минимум в двух случаях: тогда, когда пишешь код на C, и тогда, когда оцениваешь свои способности.

     
  • 6.232, Аноним (223), 11:54, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ведь всегда, с начала времён люди старались делать удобные, эффективные инструменты. Все остальные параметры шли после этих двух основных

    Ну да, все удобные и, главное, эффективные инструменты уже изобрели в каменном веке. Прогресс остановился, ведь ничего не изменяется, правда? Как вы умудрились с помощью палки-копалки и скребка написать коммент на опеннете?

     
     
  • 7.310, freehck (ok), 12:19, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ведь всегда, с начала времён люди старались делать удобные, эффективные инструменты. Все остальные параметры шли после этих двух основных
    > Ну да, все удобные и, главное, эффективные инструменты уже изобрели в каменном
    > веке. Прогресс остановился, ведь ничего не изменяется, правда? Как вы умудрились
    > с помощью палки-копалки и скребка написать коммент на опеннете?

    Очень просто. Он запустил Emacs и включил M-x butterfly-mode.

     
  • 6.309, freehck (ok), 12:16, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Но когда специалисты голосуют за безопасные инструменты жертвуя эффективностью и что ещё хуже -
    > удобством инструментов - это что-то совершенно за гранью и возникает вопрос в адекватности специалистов
    > то есть специалисты ли они вообще?

    Не, не возникает такого вопроса. Потому что есть простое объяснение: не существует такого количества специалистов, чтобы удовлетворить всесь спрос рынка IT.

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

    Так что не сбрендили мы, всё закономерно.

    PS. А ещё, давайте будем честными хотя бы перед собой: даже специалисты ошибаются.

     

  • 1.68, Мгер (?), 13:02, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    почему с++ нет?
     
     
  • 2.69, Аноним (43), 13:14, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С++ это не нужная надстройка. Тот же раст только с другим синтаксисом. Заодно посмотри в ядре сколько строк на С++  удивись.
     
     
  • 3.70, Мгер (?), 13:17, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > С++ это не нужная надстройка. Тот же раст только с другим синтаксисом.
    > Заодно посмотри в ядре сколько строк на С++  удивись.

    любой язык надстройка над ассемблером. так мне интересно кто лучше раст или с++

     
     
  • 4.173, Аноним (173), 20:48, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Над машинным кодом, а не асмом.
     
  • 4.244, Аноним (239), 14:13, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты программируешь на С++ и зарабатываешь на этом, то лучше конечно С++ для тебя.

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

     
     
  • 5.282, Аноним (282), 16:16, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только когда в Rust сделают нормальное наследование, только тогда он сможет заявлять о себе как о замене C++. А так ни разу не замена.
     
     
  • 6.291, Forth (ok), 20:55, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На кой оно вам сдалось? Привести пример кода можете, где прям без наследования ну никак нельзя?
     
  • 6.313, Wilem (?), 18:59, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем тебе наследование? Это мертворожденная фича, которой практически никто уже не пользуется ни в каких языках. Даже для UI. Трейты рулят. Композиция.
     

  • 1.85, Аноним (85), 13:52, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Радует участие OCaml.
     
     
  • 2.125, neAnonim (?), 17:17, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Университет же, единственное место где его возможно встретить
     
     
  • 3.278, Аноним (282), 16:04, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть мультиклиент различных P2P-сетей на нём http://mldonkey.sourceforge.net/
     
  • 3.296, Vkni (ok), 00:53, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не единственное - Facebook/Jane Street и другие по-мелочи.
     

  • 1.91, Аноним (91), 14:11, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тест по пороизводителность...
    Но, где тест по нагрузке на процессор и тест по потреблению памяти?
     
     
  • 2.132, Аноним (132), 18:02, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Можно предположить они съели все ресурсы от 3 Ггц проца.
     

  • 1.94, svsd_val (ok), 14:14, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они не думают что 2-10% это тоже много, если 1 драйвер - это не страшно а теперь представляем ОС состоящую только из подобных драйверов и все с такими "просадками" производительности ... в итоге получим черепаху которая "нормально" будет работать разве что на дорогих компах ...
     
     
  • 2.96, kiwinix (?), 14:22, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Люблю Раст, но плюсую что просадки производительности 2% для драйвера это многовато..
     
     
  • 3.314, Wilem (?), 19:03, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Все эти исходники могут сильно различаться по степени оптимизированности. Ну и плюс это сравнение не языков, а компиляторов и рантаймов. Которые ещё разных версий бывают. Раст должен работать без оверхеда над си, если где-то проседает значит либо код неоптимальный либо в компиляторе есть что улучшить.
     
  • 2.98, НяшМяш (ok), 14:42, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нельзя забывать что ОС - это куча других разных вещей. Взять тот же Clear Linux - при тех же самых исходниках умудряется иногда производительность выжимать в несколько раз больше. Если ОС сама по себе не будет давать большого оверхеда, то драйвер медленнее линуксического на 2-10% не будет такой большой проблемой.
     
     
  • 3.103, Аноним84701 (ok), 15:07, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оно не будет проблемой, потому что можно вместо гаданий на опеннетной гуще погля... текст свёрнут, показать
     
     
  • 4.112, Андрей (??), 16:03, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-

    Т.е. экономические затраты датацентра (на электричество) при переходе на такой вот драйвер вырастут.

     
     
  • 5.114, Аноним84701 (ok), 16:09, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > >  Our Rust driver executes 63% more instructions per packet but is only 4% slower than a reference C implemen-
    > Т.е. экономические затраты датацентра (на электричество) при переходе на такой вот драйвер вырастут.

    Проценты лучше смотреть вот эти:
    >> But it manages to do so with only 6% (11%) more cycles per packet for batch size 32 (batch size 8).

     
     
  • 6.274, Онаним (?), 11:01, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То есть целых 10% производительности надо отдать за возможность хипстерков писать на моднявом язычке? С учётом того, что стоимость разработки на C/хрусте выйдет примерно одинаковой, а толковых программистов на первом больше - не, спасибо.
     
     
  • 7.286, red75prim (?), 19:06, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Когда-то давно хипстеры Керниган и Ричи переписывали UNIX с ассемблера на наколенную поделку, которая позже стала языком C. Наверно тоже сколько-то процентов производительности потеряли. Оптимизатора в компиляторе С тогда особо не было.
     
     
  • 8.287, red75prim (?), 19:14, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Впрочем, из-за чего там эти 10 в статье особо не разбирались, а предположили, ч... текст свёрнут, показать
     
  • 8.304, Онаним (?), 10:46, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё один, не осиливший разницу между транслятором ассемблера и реальным ЯВУ У ... текст свёрнут, показать
     
     
  • 9.305, Онаним (?), 10:47, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    разницы с сями, естественно - просто ещё одна потуга на предмет альтернативно... текст свёрнут, показать
     
  • 2.134, Аноним (134), 18:04, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    помнятся мне эти "нормально", там дорогой компа даже не спасает из-за wait for response.
    Менеджеры и так софт в говно превратили ради быстрой разработки, и продажи. Теперь за саму ОСь взялись.
     
  • 2.153, Dee (??), 19:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    0.98*a + 0.98*b + 0.98*c + 0.98*d = 0.98*(a+b+c+d)
    Если каждый компонент просядет на пару процентов, общая скорость тоже лишь на пару процентов должна.
     
     
  • 3.165, anonymous (??), 20:05, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Скорее: 0.98 * 0.98 * 0.98 * 0.98 ~= 0.92 (если эти модули используются последовательно)
     
     
  • 4.208, funny.falcon (?), 07:05, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее: 0.98 * 0.98 * 0.98 * 0.98 ~= 0.92 (если эти
    > модули используются последовательно)

    Ещё правильнее: (1 + 1 + 1 + 1)/(1/0.98 + 1/0.98 + 1/0.98 + 1/0.98) = 4/(4/0.98) = 0.98

     
  • 2.238, Аноним (223), 13:53, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера на C стали переписывать. Причем тогда у них были более весомые аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые С-компиляторы наверняка генерировали не самый оптимальный код.
     
     
  • 3.290, svsd_val (ok), 20:20, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
    > на C стали переписывать. Причем тогда у них были более весомые
    > аргументы - все программисты вокруг были опытные матерые ассемблерщики, а первые
    > С-компиляторы наверняка генерировали не самый оптимальный код.

    Вы исходный код ядра давно видели ? Все более менее значимые участки на ассемблерных вставках..

     
  • 3.306, Онаним (?), 10:48, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Наверное так же плакали и сетовали некоторые очкарики когда юникс с ассемблера
    > на C стали переписывать. Причем тогда у них были более весомые

    Осиль уже разницу между транслятором мнемоник машкода и таки ЯВУ, потом бредь.

     
  • 2.257, мяя (?), 19:52, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И как часто эти драйвера вызываются У тебя из основного Драйвер контроллера н... текст свёрнут, показать
     
     
  • 3.275, Онаним (?), 11:02, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для каждой машины, которая отдаёт тебе статический например видеоконтентик, который ты смотришь в том самом браузере, этот самый драйвер чуть ли не основа основ.
     
  • 3.289, svsd_val (ok), 20:18, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > чем на этих драйверах. Когда та же лиса или хром в
    > фоне ощутимо жрут ЦП на всяком мусоре.
    > Обычно производительность во многом зависит от архитектуры драйвера, даже если там числодробилки
    > надо их с умом использовать и бывает так что умный код
    > на высокоуровневом языке оказывается производительнее кода байтоёба, банально байтоёб
    > забил на асинхронность и синхронно долбит вызовы просирая кучу времени на
    > эту синхронность. Так что сравнивая языки надо учитывать ещё и лёгкость
    > написания умного кода. Когда язык требует большой осторожности то неминуемо он
    > сожрёт время на это, когда как это время можно было потратить
    > на более продуманный код.

    И так начнём, представьте что Вы используете видео драйвер который написан на этом деле со своими просадками в производительности и отзывчивости, используется он как ни странно 99% рабочего времени пользователя... Конечно если Вы не юзаете сервер без видео вывода. Получаем что производительность и отзывчивость системы в целом да и в мультимедиа упадёт не на 10%. Так как системе и приложению ещё нужно использовать винт, сеть, звук, устройства ввода, каждый драйвер со случайной просадкой производительности и отзывчивости... Будете играть и со скоростью эмуляторов плоек и задержками на каждом вводе ...

    А вот про правильный код, тут вопрос открыт, у всех он свой... у проприетарщиков работает на костылях - правильный код.

     

  • 1.111, Андрей (??), 16:00, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > При написании кода основное внимание уделялось достижению максимально возможной производительности с учётом особенностей каждого языка.

    У авторов действительно есть хотя бы несколько лет профессионального использования каждого из этих языков. Профессионального в смысле при написании высокопроизводитнльного софта (Google, Netflix,..).

     
     
  • 2.205, Anonn (?), 04:38, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Было бы гораздо интереснее, если бы был объявлен открытый конкурс на более эффективную реализацию для каждого из языков. Я думаю, что результаты были бы достаточно другими. Те же сорцы на го — там есть что оптимизировать…
     

  • 1.121, реверсер (?), 16:56, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ассемблера не ?!?
    а было бы смешно увидеть графиках даже асм который бы сливал русту)))
    намекая на явно заказные тесты от мозиллы
     
     
  • 2.131, Аноним (132), 18:02, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ассемблер далеко не всегда быстрее.
     
     
  • 3.148, аноним3 (?), 18:51, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    в большинстве прямые инструкции будут куда быстрее того же си-шного кода. единственный вариант, что драйвер на сях или любом языке будет собран с особым упором на поддержку всех инструкций процессора, а ассемблерный код будет пользоваться основным множеством инструкций имеющихся во всех процах(моделях). но даже так при сборке такого драйвера будет несколько лишних инструкций из за особенностей языка. но интерпретируемые языки? и специально ограниченные самой медленной конфигурацией? правда попахивает заказом))
     
  • 3.195, Аноним (-), 23:02, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ассемблер далеко не всегда быстрее.

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

     

  • 1.123, forum reader (?), 17:12, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Оригинальный способ проводить сравнение компиляторов с интерпретаторами.
     
  • 1.126, Аноним (126), 17:20, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    на Lua было бы быстрее
     
     
  • 2.184, Аноним (184), 21:52, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если сравнивать с питоном и js
     
     
  • 3.245, Аноним (239), 14:15, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнивали Lua на какие-то сотые проценты лучше Python,
    с JavaScript в 9 - 15 раз быстрее ...
     
     
  • 4.279, Аноним (282), 16:06, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С JS корректно сравнивать LuaJIT.
     

  • 1.127, Griggorii (?), 17:32, 12/09/2019 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –7 +/
     
  • 1.137, Аноним (137), 18:15, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не понимаю, как свифт может работать со скоростью жс? Он же компилируемый. И эппл его продвигал для приложений и прочего. Получается, что они должны быть +- как на электроне?
     
     
  • 2.154, Dee (??), 19:13, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Они там в pdf-ке с анализом пишут:

    Swift increments a reference counter for each object passed into a function and decreases it when leaving the function. This is done for every single packet as they are wrapped in Swift-native wrappers for bounds checks. There is no good way to disable this behavior for the wrapper objects while maintaining an idiomatic API for applications using the driver. A total of 76% of the CPU time is spent incrementing and decrementing reference counters. This is the only language runtime evaluated here that incurs a large cost even for objects that are never free’d.

    76 процентов, Карл!

    Тормоз этот ваш свифт.

     
     
  • 3.179, Dnina (ok), 21:13, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то полная жесть. Точно не помню, но по-моему видел намёки на то, что чуть ли не бэкенд писать на нём можно. Но кому оно надо в таком виде.
    Интересно, Objective-C не имеет такого косяка? Если нет, то переход на более медленный язык выглядит так себе. Разве что для смузихлёбов.
     
  • 3.191, Optional (?), 22:25, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в swift есть struct и class, struct - это тип-значение, а class - это ссылочный тип, возможно они классы использовали вместо структур?
    и вроде если структуры использовать, должно быть быстрее?
    а с другой стороны, может сама реализация ARC нелучшая, с какими-то недостатками?
     
  • 3.254, Ананд (?), 19:14, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://github.com/ixy-languages/ixy.swift/tree/master/ixy/Sources/ixy/Common

    Они сделали все как class. Если поменять на struct летать будет.

    Class: reference counting + lock for multithreading.
    Struct: no reference counting, no safe multithreading(should be immutable)

     

  • 1.140, grsec (ok), 18:23, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Пистон провалился, я не удивлен. Этот монстр скоро вообще забудет, что такое скорость о обрастет жиром.
     
     
  • 2.175, Led (ok), 20:55, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Зато он гламурный, а ты просто завидуешь.
     
     
  • 3.201, аноним3 (?), 00:50, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –7 +/
    народ в угаре от этого теста и не может остановиться. ржет и падает. у нас не 1 апреля случаем? вроде нет. тогда тут либо тестеры дауны, либо они недоученные прогеры. и то и то не очень солидно)) и правда почему плюсы не использовали? полагаю было бы один в один с Си.
     
     
  • 4.203, Наноним (?), 03:57, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    "ржём, падаем, в угаре, 1 апреля, дауны, недоученные"

    Всё, что нужно знать об уровне дискуссий фанатов "языка, доступного каждому".

     
     
  • 5.250, аноним3 (?), 17:02, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    знаешь если питон применять с умом он очень даже хороший язык. ну если пихать его  туда где солнце не светит , то да)) ресурсоемкими задачами должны заниматься компилируемые языки. и если тестеры даже этого не понимали, то извини кроме как недоучек их не назвать.
     
     
  • 6.251, red75prim (?), 17:34, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > этого не понимали, то извини кроме как недоучек их не назвать.

    Питон там как представитель интерпретируемых языков без JIT. Поэтому они ни PyPy не использовали, ни оптимизацией особо не занимались - и так ясно, что на этой задаче он сольёт.

     
  • 6.297, Vkni (ok), 02:46, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > знаешь если питон применять с умом он очень даже хороший язык. ну если пихать его  туда где солнце не светит

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

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

     
  • 2.298, Vkni (ok), 02:49, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это язык для прототипирования нетребовательных к производительности интерпретатора программ (всё скоростное должно быть вынесено в С или другие языки).

    И если не заниматься закручиванием гвоздей отвёрткой, то всё будет нормально.

     

  • 1.155, Аноним (-), 19:30, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Годный убедительный тест.
    Но однозначно не хватает FPC. Есть подозрения, что, внезапно, он асимптотически сходился бы с кодом на Раст.
     
     
  • 2.187, Retrosharer (?), 22:03, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, было бы не плохо в такой тест включить Free Pascal, который развивается семимильными шагами. Что удивительно.

    Не пришлось бы отсылать к вопросу скорости Паскаля на ресурсы вроде такого: https://www.quora.com/Is-Pascal-faster-than-C?share=1
    Было бы более объективно.

     
  • 2.198, Ordu (ok), 23:21, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Напиши. 1000 строк кода при возможности подглядывать в C'шный код -- это при худшем раскладе займёт выходные за месяц. Если писать вечерами и на выходных, можно управится за неделю.
     

  • 1.182, Аноним (182), 21:30, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Бедный питон :)

    И да - не хватает варианта C++

     
  • 1.193, all_glory_to_the_hypnotoad (ok), 22:39, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Дополнительно были проведены тесты на время задержки, которые показывали эффективность буферизации и влияние сборщика мусора.

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

     
  • 1.199, vitalif (ok), 23:44, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Блин, не могу, придётся потестить

    virtio оно говорите поддерживает...

     
  • 1.218, Аноним (218), 09:18, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Why C and not a more reasonable language?

    It's the lowest common denominator that everyone should be able to understand -- this is for educational purposes only. I've taken care to keep the code simple and understandable.

    When should I use this?
    To understand how a NIC works and to understand how a framework like DPDK or Snabb works.


    Отсюда вопрос - а зачем они сравнивали на скорость нечто, что создавалась как учебное пособие? Т.е. я так понимаю, что это для всех языков примерно такой подход.

     
  • 1.229, InuYasha (?), 11:42, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всех с Днём Программиста! (^_^)/
     
  • 1.249, Анатоним (?), 15:29, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Python красава. Даже на это го@#о голову не поднял, посмотреть че там его за хвост тягают. Это не царское дело.
     
  • 1.252, Аноним (252), 17:58, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На JavaScript?!.
    Мсье знает толк...
     
  • 1.255, Аноним qwerty_qwerty1 (?), 19:31, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да блин, Rust, GO вся проблема в руках!!!
    В результате что на Rust что GO будут использовать unsafe и получится таже фигня.
        
     
  • 1.258, JL2001 (ok), 21:04, 13/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я бы хотел такой же драйвер на Dlang увидеть в вариантах без GC и с ним
     
     
  • 2.267, аноним3 (?), 03:51, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    те же плюсы получатся))насколько помню даже один из разработчиков плюсов у них язык развивает. так что думаю получится тоже самое в чуть более удобной обертке. и то хорошо. а скорость по идее не должна уступать С. хотя ничего не скажу , я его только мельком глянул.
     
     
  • 3.269, JL2001 (ok), 10:12, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > те же плюсы получатся))насколько помню даже один из разработчиков плюсов у них
    > язык развивает. так что думаю получится тоже самое в чуть более
    > удобной обертке. и то хорошо. а скорость по идее не должна
    > уступать С. хотя ничего не скажу , я его только мельком
    > глянул.

    вот тут внезапно c# и java оказались сильно разными, а c и rust сильно одинаковыми
    хотелось бы результатов тестов

     

  • 1.270, Онаним (?), 10:50, 14/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Попытку захайпать хруст как язык в т.ч. для низкоуровневых приложений оценил, но спасибо, нет. Костыль на костыле и костылём погоняет.
     
     
  • 2.273, Онаним (?), 10:59, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я уж молчу про то, что код на сях в оx*иллиард раз читабельнее и очевиднее. Пока что потуги придумать что-то лучше сишного синтаксиса около которого вертятся всегда востребованные C,C,Java,PHP,etc. успехом не увенчиваются, увы.
     

  • 1.277, Аноним (282), 15:56, 14/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    C++ в тестах отсутствует. Нечестно, всё-таки, широко известный ЯП.
    Удивило оставание OCaml, который в машинные коды, от Java, которая в JIT и в виртуальной машине.
     
     
  • 2.280, all_glory_to_the_hypnotoad (ok), 16:06, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    OCaml показал себя лучше явы: пропускная способность на уровне, а задержки значительно меньше.
     
     
  • 3.281, Аноним (282), 16:11, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По первому графику совпадение тоько при 64-х пакетах, в других точках отставание.
     
     
  • 4.288, all_glory_to_the_hypnotoad (ok), 19:17, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Разница незначительная.
     
  • 2.285, Vkni (ok), 18:38, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я подозреваю, что Ocaml можно сильно разогнать, убрав аллокации - народ в Jane Street пишет low latency код на Ocaml для спекуляций. Но это не идиоматично.

    Второй момент: JIT - это же и есть машинные коды. Just-In-Time compile. То есть, на hot path и Ocaml, и Java скомпилированы одинаково.

     
  • 2.294, аноним3 (?), 00:40, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    его к сожалению мало кто хорошо знает)) хотя пишут много кто, но он разросся в такого монстра, что страшно. чистый Си выглядит куда проще)) хотя у плюсов есть плюсы))) ахаха хорошо загнул.
     

  • 1.283, Murz (ok), 18:30, 14/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где мои любимые php и vba?
     
     
  • 2.295, аноним3 (?), 00:42, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ты их через браузер погонишь? хотя погоди, запросы будут через внутренний сервак отправляться? помилуй железо оно и так страдает))
     
     
  • 3.302, q (??), 08:33, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    питон через солнце запускали что-ли?
     
     
  • 4.307, Онаним (?), 10:52, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > питон через солнце запускали что-ли?

    Через ж*... да, через солнце.
    Не, кроме шуток, его вроде компилировали, если я их текст правильно понял.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру