Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Опубликованы тесты простейших приложений на различных языках..."	+/–
Сообщение от opennews (??), 08-Дек-19, 09:25
Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, опубликовал видео под названием «Зачем писать на ассемблере?». В видео приводятся результаты тестирования при помощи  утилит perf и strace простейшего приложения (вывод 'hello'), написанного на 13 языках программирования... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51992
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 08-Дек-19, 09:25	+21 +/–
А теперь пусть напишет на асемблере бизнес логику
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #12, #204, #378

2. Сообщение от Ананимас009 (?), 08-Дек-19, 09:34	+/–
Почему нет lua¿
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #33, #353, #379

3. Сообщение от Аноним (3), 08-Дек-19, 09:34	+28 +/–
А причем здесь "бизнес логика"? Многие вещи в линукс реализованы на python, например - это в 144 более затратно, чем на C. А потом возникают удивленные возгласы типа - "как это легковесный дистрибутив требует Х Ггц проц и YГб ОЗУ?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8, #31, #290, #360, #407

4. Сообщение от qqqqqq (?), 08-Дек-19, 09:35	+8 +/–
Технически, это камень в сторону компиляторов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #408

5. Сообщение от qqqqqq (?), 08-Дек-19, 09:38	+/–
Потому что у lua слишком много версий и трансляторов и весь этот зоопарк вроде как кем-то поддерживаются. А ещё это в первую очередь, имхо, встроенный скриптовый язык, а уже потом что-то самостоятельное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #79, #111

6. Сообщение от Аноним (6), 08-Дек-19, 09:41	+13 +/–
И снова нет Pascal.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #24

7. Сообщение от Нанобот (ok), 08-Дек-19, 09:43	+7 +/–
Наглядно демонстрирует раздутость современного ПО
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #112

8. Сообщение от Илья (??), 08-Дек-19, 09:44	–3 +/–
> реализованы на python Так не требуют производительности же. Ну например dnf.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #54, #240, #374

9. Сообщение от Wfhm (?), 08-Дек-19, 09:44	+/–
Руби как всегда.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Anonymoustus (ok), 08-Дек-19, 09:47	+/–
Восхитительно! :-) Удивляет Игогошечка. Всё остальное не удивляет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #76

11. Сообщение от Аноним (11), 08-Дек-19, 09:52	+2 +/–
> результаты бенчмарка > 23-минутное видео Мда.
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Anonymoustus (ok), 08-Дек-19, 09:57	+3 +/–
Для бизнес-логики 60 лет назад придумали КОБОЛ. А то, что _ты_ называешь бизнес-логикой, это паразитирование на обществе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

13. Сообщение от Anonymoustus (ok), 08-Дек-19, 09:58	+1 +/–
Да, недоработочка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #85

14. Сообщение от анонимчик (?), 08-Дек-19, 10:08	–4 +/–
rust уделал плюсы по полной, учитывая нафаршированность языка - вывод очевиден
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #314

15. Сообщение от Аноним (15), 08-Дек-19, 10:10	+22 +/–
Это не тестирование, это троллинг недалекого человека.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #260

16. Сообщение от йййй (ok), 08-Дек-19, 10:10	+/–
Ага, как-же новый системный язык Раст то ей слил по числу инструкций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #341

17. Сообщение от Анони (?), 08-Дек-19, 10:25	–6 +/–
Как сказал когда-то мой препод: "писать на ассемблере под Линукс - это самоубийство".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64, #72, #222

18. Сообщение от Аноним (18), 08-Дек-19, 10:26	+14 +/–
Как же бесят все эти бенчмарки на хелловорлдах. Только вводят в заблуждение новичков, которые стоят сейчас перед выбором и черпают информацию у таких вот фанатиков.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #21

19. Сообщение от Аноним (19), 08-Дек-19, 10:31	+6 +/–
А Go уделал Раст. А плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreams
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #22, #28, #49

20. Сообщение от Аноним (95), 08-Дек-19, 10:35	+/–
Каких фанатиков? Это же просто шутка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #218

21. Сообщение от Кирилл (??), 08-Дек-19, 10:39	+3 +/–
А потом бывшие новички, не попавшие в заблуждение, начинают писать многопоточчный код на джаве, дающий 300% оверхеда на порождение этого самого множества потоков. Т.е. на 6-8 ядерниках оно в принипе выиграет, но отзывчивость...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26, #69

22. Сообщение от йййй (ok), 08-Дек-19, 10:43	+1 +/–
У раста еще и выполняемый образ под 6 Mb, против 1 Mb у Go и 12 Kb у C/C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #68, #331

23. Сообщение от Аноним (23), 08-Дек-19, 10:45	+2 +/–
> простейшего приложения (вывод 'hello') Я не пишу такие простейшие приложения, кому они нужны? Если же писать что-то более полезное, чем «привет мир», то результаты будут, скажем, другое
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #30, #63

24. Сообщение от Retrosharer (?), 08-Дек-19, 10:50	+5 +/–
Думаю, на уровне С++. А Java впечатляет 👍
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #25, #41, #86

25. Сообщение от йййй (ok), 08-Дек-19, 10:55	+2 +/–
Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. Это было ожидаемо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #42, #381

26. Сообщение от Илья (??), 08-Дек-19, 10:59	–1 +/–
Вы не знали, что во названных в статье языках можно реализовать любые многопоточные модели?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #108

27. Сообщение от Иваня (?), 08-Дек-19, 11:01	–1 +/–
Отлично, спасибо за информацию. Это мотивирует изучать Assembler
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #106

28. Сообщение от анонимчик (?), 08-Дек-19, 11:02	+/–
только по количеству инструкций, но не по производительности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #32

29. Сообщение от Алексей Михайлович (?), 08-Дек-19, 11:04	–5 +/–
Так в том и дело, что особой разницы не будет. Жаба, как и гадюка, будут всасывать у всех остальных; разница между нормальными языками будет минимальной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #36, #230

30. Сообщение от анонимчик (?), 08-Дек-19, 11:05	+/–
какие? большая программа состоит из тривиальных блоков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

31. Сообщение от Аноним (31), 08-Дек-19, 11:13	–2 +/–
>например - это в 144 более затратно, чем на C. Питон - язык-связка. Все критичные к производительности части можно либо вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #34, #391

32. Сообщение от йййй (ok), 08-Дек-19, 11:15	+1 +/–
Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #52, #97, #307

33. Сообщение от Аноним (31), 08-Дек-19, 11:17	+25 +/–
перевёрнутые знаки в начале ставятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

34. Сообщение от Анонисмус (?), 08-Дек-19, 11:17	+13 +/–
Язык-связка - это bash:c его помощью можно связать несвязанные между собой по функционалу утилиты доступные в *nix. А в python большинство этого функционала доступно из коробки в виде стандартной библиотеки, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #77, #105

35. Сообщение от Аноним (31), 08-Дек-19, 11:24	–1 +/–
1. Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве. Даже открывать не буду: автор явно нас не уважает. 2. Сравнение некорректно. На С++ можно писать в стиле C. И е
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38, #58

36. Сообщение от Аноним (95), 08-Дек-19, 11:26	–5 +/–
Конец списка переместится в начало достаточно быстро, просто потому что ты не сможешь оптимизировать ассемблер на лету в зависимости от данных, как это делает жит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #39, #189

37. Сообщение от ф (?), 08-Дек-19, 11:26	+4 +/–
ну вот! a говорили, что лапша на баше тормозит загрузку - а оказывается в первой четверке по скорости ;)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #45, #103

38. Сообщение от Аноним (95), 08-Дек-19, 11:28	+2 +/–
Более того, на си можно писать в стиле ассемблера. Уже по результатам си возникают некоторые вопросы, как-то очевидно шуточное сравнение выходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #40, #232

39. Сообщение от Алексей Михайлович (?), 08-Дек-19, 11:31	+3 +/–
> Конец списка переместится в начало достаточно быстро, просто потому что ты не > сможешь оптимизировать ассемблер на лету в зависимости от данных, как это > делает жит. То есть, ты обожрался диссоциативов и теперь утверждаешь, что жаба обгонит ассемблер и нормальные нативно компилируемые языки? Можно пруфца, что ваше тормозное гуано для копипастеров так может?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #47, #48

40. Сообщение от йййй (ok), 08-Дек-19, 11:33	+3 +/–
Здесь используются рекомендованные языком техники, так что с этим все нормально. То что стримы в C++ тормозные и так все знают. Так-то можно и из PHP С-шный модуль дергать. А вот языки со своими виртуальными машинами действительно могут показать некорректные результаты. Так что тест правда скорей шуточный. Им только растоманов троллить :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #56

41. Сообщение от proninyaroslav (ok), 08-Дек-19, 11:35	+1 +/–
Надо учитывать запуск JVM. Тоже самое можно было бы сказать и про шарп (которого тут нет). При запущенном результат был бы куда лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #46, #346

42. Сообщение от Алексей Михайлович (?), 08-Дек-19, 11:35	+9 +/–
> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. А она вообще может показать хороший результат? Сколько я ни пытался использовать жабософт, положительных эмоций от него не испытывал ни разу. Тормозит и жрёт всю память, что видит. Нет, не так: ТОРМОЗИТ ДАЖЕ НА РОВНОМ МЕСТЕ и жрёт всё, до чего может только дотянуться. И ещё прогрева какого-то требует, как жигуль в морозы. Если это — новые и современные технологии, то мой член — первый заместитель Папы Римского.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #60, #171, #206, #228, #264

43. Сообщение от Аноним (45), 08-Дек-19, 11:44	+1 +/–
>реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, предлагающей в том числе реализации протоколов TLS 1.2 и SSH2 Интересно, как образец, чтобы сделать подобное для микроконтроллеров RV32, RV64, где ограничено количество ПЗУ и ОЗУ.
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от Антон (??), 08-Дек-19, 11:47	+/–
там видать парсинг скрипт "echo hello" и вызов echo
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #215

45. Сообщение от Аноним (45), 08-Дек-19, 11:47	–1 +/–
Знатно Поттеринга протроллил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

46. Сообщение от Аноним (46), 08-Дек-19, 11:47	–5 +/–
А накуя поделка от Майкрософт? От Майкрософт нам ничего не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #162, #238

47. Сообщение от Аноним (95), 08-Дек-19, 11:53	–1 +/–
Изи, надо только взять substratevm и выкинуть гц. Но, как и везде, "есть нюанс".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

48. Сообщение от A.Stahl (ok), 08-Дек-19, 11:56	+1 +/–
Он про JIT говорит. JIT хорошая штука, которая позволяет генерировать эффективный код, а не ограничиваться кодом "который везде будет работать". Посмотри на гентушников собирающих софт под конкретную машину и радующихся своим нескольким дополнительным процентам производительности. Мелочь, а приятно. И иногда эта мелочь отделяет количественное изменеие от качественного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #62, #70, #118

49. Сообщение от Аноним (54), 08-Дек-19, 11:57	+4 +/–
> плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreams Тогда не было бы отличий от реализаций на C.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

50. Сообщение от Аноним (54), 08-Дек-19, 11:57	–1 +/–
вывсеврети джава нитармазит!!11
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от Илья (??), 08-Дек-19, 12:03	+2 +/–
Почему он свой скрипт писал на баше, а не на ассемблере?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

52. Сообщение от Аноним (54), 08-Дек-19, 12:09	–3 +/–
> Rust - убийцу C 21 века Не C, а C++. Второй уже, кстати, убийца, после D. Может быть, у третьего и получится. > с Go - убийцей PHP 21 века Какой ещё PHP в XXI веке? Python, Java.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #55, #161

53. Сообщение от mrprint (?), 08-Дек-19, 12:10	+/–
Всё неймётся ассемблерщикам https://github.com/mrprint/HelloTiny
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #89

54. Сообщение от Аноним (54), 08-Дек-19, 12:11	+7 +/–
> не требуют производительности же. Ну например dnf. Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #99, #164

55. Сообщение от йййй (ok), 08-Дек-19, 12:11	–4 +/–
На C++ никто не предлагает писать операционки, а на раст не только предлагают, так еще и писать пытаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #61, #67, #265, #385

56. Сообщение от Аноним (31), 08-Дек-19, 12:15	+5 +/–
В том то и дело, что стримы в  C++ не тормозные. Нужно просто отключить синхронизацию с выводом в stdio. https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #65

57. Сообщение от Аноним (57), 08-Дек-19, 12:17	+/–
>Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing для каллибриОС штоли
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #200

58. Сообщение от Аноним (54), 08-Дек-19, 12:19	+/–
> Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве. Это чтобы заодно подсунуть бинарники в расчёте, что их кто-нибудь да запустит…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

59. Сообщение от Анонисмус (?), 08-Дек-19, 12:20	+6 +/–
Если бы он писал на ассемблере, то ты бы не досмотрел видео до конца.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #323

60. Сообщение от Аноним (60), 08-Дек-19, 12:21	+/–
Плохому танцору Ява мешает. Кошка бросила котят - это Ява виноват. Использую продукцию джетбрейнс - не тормозит. Использую онлайн-банк, о котором доподлинно известно, что он на Ява ЕЕ - не тормозит. Ява - это не КГИ, который запускается с нуля на каждый ХТТП-реквест. Ява для долгоиграющих приложений. Если конкретно у тебя все тормозит, пиши мне на почту, хочу купить твой комп, - я коллекционирую железо 80-90 годов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #81, #115, #181

61. Сообщение от Анонисмус (?), 08-Дек-19, 12:23	+4 +/–
Дело в том, что даже сами авторы языка С++ не советуют на нём писать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

62. Сообщение от Z (??), 08-Дек-19, 12:23	+/–
Ага JIT за те мс которые есть у него делает оптимизации лучше чем статический компилятор, ну да, верьте, верьте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #104, #120

63. Сообщение от ыы (?), 08-Дек-19, 12:25	+/–
Ждем ваш тест
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

64. Сообщение от Ordu (ok), 08-Дек-19, 12:26	+6 +/–
Что он имел в виду? Под linux писать на асме гораздо приятнее чем под DOS или под Windows.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #92, #107

65. Сообщение от йййй (ok), 08-Дек-19, 12:26	–1 +/–
Спасибо, буду знать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

66. Сообщение от Аноним (66), 08-Дек-19, 12:28	+5 +/–
Perl молодец, собственно, как и ожидалось.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #202

67. Сообщение от Аноним (54), 08-Дек-19, 12:28	+3 +/–
Конечно, нет и никогда не было ни BeOS, ни Haiku, ни Symbian…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #71

68. Сообщение от Forth (ok), 08-Дек-19, 12:32	+/–
Интересно как это получилось, у меня ни в какую не вышло собрать также, даже с дефолтными опциями компиляторов. На C вышел бинарник 8 кб, на расте (дебажный билд, по дефолту) 2,5мб. Как он получил 6мб? Я уж молчу про прочие характеристики типа числа системных вызовов. У меня для C вышло 24, у него 54. o_O P.S Троллинг, не иначе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #80

69. Сообщение от Crazy Alex (ok), 08-Дек-19, 12:33	+3 +/–
И в какой-то момент они узнают, что поток порождается один раз, а потом ему только задания подкидывают. А так же 100500 других приёмов. И что? Впрочем, с тех пор, как джава оказалась в андроиде, я сам на неё чертыхаюсь. Хотя она была и есть на своём месте в больших сложных приложениях, в которых проблема - сделать, чтобы они просто работали, а скорость - ну это уже как выйдет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #214, #247

70. Сообщение от Crazy Alex (ok), 08-Дек-19, 12:35	+/–
JIT довольно дорог сам по себе и выгоден далеко не во всех ситуациях. Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #134

71. Сообщение от йййй (ok), 08-Дек-19, 12:37	–1 +/–
О, кстати да, про Symbian забыл. Хотя там использовалась очень кастрированная версия C++ без исключений, со своими строками. Для лучшего управления ресурсами. Про остальные не в курсе, не сталкивался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #243

72. Сообщение от Forth (ok), 08-Дек-19, 12:55	+8 +/–
Возможно. На ассемблере под Linux не писал, а вот под FreeBSD было дело. Версия кажется была 4.11, точно не помню. Я тогда студентом был, а первые появившиеся бесплатные хостинги позволяли либо php4 (как-то выглядело непривлекательно :/ ) либо CGI. А мы с одногруппником хотели чат сбацать, тогда это было в тренде, свой чатик. Он на html лепил это всё, а мне досталась серверная часть. Я, преодолевая отвращение, слепил на php, оно тормозило безбожно и периодически вместо фрейма с чатом вылезала врезка от хостера, что мол ресурсы превышены :)) Не помню как я пришел в этому решению, студент все-таки, времени полно. Я сделал бинарник для CGI на ассемблере. Есстественно он был статический, какие нафиг libc. Три-четыре нужных системных вызова, типа read,write и shared memory вызовов попросту подсмотрел в исходниках libc как оно вызывается, какая конвенция и все такое. Работало не то слово - летало. Все CGI бинарники писали в общую память, при обновлении страницы попросту выдавался хвост этого кольцевого буфера с текстом чата. Смутно припоминаю размер ELF результирующий был меньше килобайта и без ld.so запускался, так что куда уж быстрее-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #83, #100

73. Сообщение от Аноним (73), 08-Дек-19, 13:01	+/–
Попробовал самостоятельно провести тест, исплользуя Си (puts) и tcc. Получил 24 taskclock.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74, #142

74. Сообщение от Аноним (73), 08-Дек-19, 13:02	+/–
gentoo ~/code/perfomance # tcc hello_puts.c -o hello_puts gentoo ~/code/perfomance # strace -fc ./hello_puts hello % time     seconds  usecs/call     calls    errors syscall ------ ----------- ----------- --------- --------- ----------------   0.00    0.000000           0         1           read   0.00    0.000000           0         1           write   0.00    0.000000           0         2           close   0.00    0.000000           0         3           fstat   0.00    0.000000           0         5           mmap   0.00    0.000000           0         3           mprotect   0.00    0.000000           0         1           munmap   0.00    0.000000           0         3           brk   0.00    0.000000           0         1         1 access   0.00    0.000000           0         1           execve   0.00    0.000000           0         1           arch_prctl   0.00    0.000000           0         2           openat ------ ----------- ----------- --------- --------- ---------------- 100.00    0.000000                    24         1 total
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #417

75. Сообщение от Аноним (102), 08-Дек-19, 13:17	+1 +/–
Делал как-то текстовый парсер на асме и для сравнения тот же парсер сделал на C++ (на самом деле все было наоборот). Код на асме работал в три раза быстрее и при этом 75% времени по strace занимали операции чтения файлов. Самым близким по производительности для моей задачи была реализация xpath из lxml для питона написанная на cython очень близка к коду на C++. А например grep очень сильно отстал. Не претендую на точность и оптимальность алгоритмов поэтому такой новости как сабже и не публиковал.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #82, #203

76. Сообщение от конь в пальто (?), 08-Дек-19, 13:18	–3 +/–
игогошечка как и баш - годится только для мелких скриптецов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #383

77. Сообщение от Фигноним (?), 08-Дек-19, 13:20	+/–
Ну так запускай, кто тебе мешает-то? Что надо тебе так критично - перепиши. Человек написал на питоне - значит ему было так удобно и с руки. Пользоваться никто не заставляет, это опенсорс. Открыл редактор и гого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #78

78. Сообщение от Фигноним (?), 08-Дек-19, 13:22	+/–
Не туда ответил, ну ладно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

79. Сообщение от Ананимас009 (?), 08-Дек-19, 13:26	+1 +/–
У луа все три версии, прям как у пихона, если у последнего не больше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

80. Сообщение от burjui (ok), 08-Дек-19, 13:28	+/–
Да уж, загадка века. $ cat x.rs fn main() {     println!("hello"); } $ rustc x.rs $ ls -lh x -rwxr-xr-x 1 burjui users 2.5M Dec  8 12:22 x $ strip x $ ls -lh x -rwxr-xr-x 1 burjui users 207K Dec  8 12:22 x Ой, а что это? Оказывается, в бинаре 90% занимает отладочная и прочая служебная информация, не влияющая на работу программы (кроме как на стектрейсы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #95, #384

81. Сообщение от Ананимас009 (?), 08-Дек-19, 13:28	–1 +/–
На нетбуке, где geany летает, нетбинс адово тормозит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #88

82. Сообщение от Аноним (95), 08-Дек-19, 13:29	+/–
>xpath из lxml для питона написанная на cython очень близка к коду на C++ libxml2 на си написан, не порите чушь - ей больно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #93

83. Сообщение от Ананимас009 (?), 08-Дек-19, 13:33	+/–
Во времена четверочки делал перл скрипт, который изображал из себя хттп сервер. Т. к. памяти на эти ваши апачи с похапе не хватало. 128м было на железке и ей нужна была память для более важных вещей, чем мониторинг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #91, #96

84. Сообщение от Грусть (?), 08-Дек-19, 13:34	+1 +/–
https://github.com/ip1981/gcd
Ответить | Правка | Наверх | Cообщить модератору

85. Сообщение от Аноним (85), 08-Дек-19, 13:36	+9 +/–
fpc-3.0.0: syscalls - 12... Вот так вот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #102, #123

86. Сообщение от Аноним (85), 08-Дек-19, 13:38	+/–
А ты не думай, а проверь... fpc-3: всего 12 сисколов, между асмом и си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

87. Сообщение от ыы (?), 08-Дек-19, 13:38	+4 +/–
Таки да, ассемблер - отличный инструмент для написания хэлловорлдов
Ответить | Правка | Наверх | Cообщить модератору

88. Сообщение от Аноним (88), 08-Дек-19, 13:42	+4 +/–
Пишу промышленные банковские приложения на нетбуке. Звонить 333-333-333, спросить Толю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

89. Сообщение от Аноним (102), 08-Дек-19, 13:50	+/–
Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib набор простых библиотек типа печать строк, чисел. Да и видосы от автора тоже могу порекомендовать хорошие видосы https://www.youtube.com/watch?v=TuNiVG2hYuU&list=PLd-kTafWJC...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #114

90. Сообщение от Аноним (90), 08-Дек-19, 13:51	+10 +/–
Как этот чел может спать спокойно, осознавая, что все инструменты, которыми он пользовался при записи видео, написаны не на ассемблере?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #94, #126

91. Сообщение от Forth (ok), 08-Дек-19, 13:54	+2 +/–
Тогда модно было lighttpd, когда апача было чересчур. На фоне этого безобразия с апачем для статики и nginx как раз поднялся. Конечно, спрос есть есть и предложение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #229

92. Сообщение от Ананимас009 (?), 08-Дек-19, 14:00	+/–
> Что он имел в виду? Под linux писать на асме гораздо приятнее > чем под DOS или под Windows. ¿А что не так с MS/PC/DR DOS? Ровно два прерывания: одно для вывода текста, второе для завершения процесса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #116, #172

93. Сообщение от Аноним (102), 08-Дек-19, 14:04	+/–
Начнем с того что lxml это биндинг для libxml2 и libslt https://lxml.de Заканчивая тем что даже на сайте libxml2 написано применять lxml http://xmlsoft.org/python.html для питона. Note that some of the Python purist dislike the default set of Python bindings, rather than complaining I suggest they have a look at lxml the more pythonic bindings for libxml2 and libxslt and check the mailing-list. И в конце концов lxml каким-то мистическим образом работал быстрее применяя cython и выше названные библиотеки. Вполне вероятно в природе есть более производительные решения я в целом и не настаивал на истину в последней инстанции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #101

94. Сообщение от Аноним (102), 08-Дек-19, 14:05	–6 +/–
Ты еще скажи что они не из машинного кода состоят)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #98

95. Сообщение от Аноним (95), 08-Дек-19, 14:11	+/–
Я ни на что не намекаю, но govno@pc /tmp $ rustc x.rs govno@pc /tmp $ ls -lAh x -rwxr-xr-x 1 govno govno 276K Dec  8 13:59 x govno@pc /tmp $ strip x govno@pc /tmp $ ls -lAh x -rwxr-xr-x 1 govno govno 199K Dec  8 14:00 x Как ни пытался я так и не смог собрать бинарник больше этого. Может у вас там ночнушки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #154, #394

96. Сообщение от Аноним (102), 08-Дек-19, 14:12	+1 +/–
У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/ Ещё в природе существует https://github.com/nemasu/asmttpd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #110, #133, #248

97. Сообщение от Аноним84701 (ok), 08-Дек-19, 14:15	+/–
> Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века. Кто эти вы и зачем эти "вы" лезут сюда с  "выводами" о ЯП после сравнения теплых хелловордов и мягких, дефолтных опций и рантаймов конкретной реализации конкретного компиялтора (или интерпретатора)? o_O
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

98. Сообщение от Аноним (90), 08-Дек-19, 14:17	+3 +/–
Что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

99. Сообщение от kai3341 (ok), 08-Дек-19, 14:22	+3 +/–
> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum? А что именно там тормозит не подскажете? Где узкое место? apt, apt-get, aptitude, dpkg тормозят ещё больше, кстати. Потому, что давайте информацию о пакетах положим файлами на ФС! А потом будем вычитывать эти файлы в память! Больше чтений диска, это же быстро происходит! sqlite не нужен, это сложно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #113, #130, #136, #166, #207

100. Сообщение от Аноним (102), 08-Дек-19, 14:23	+3 +/–
Сейчас и форумы на асме делают https://asm32.info/fossil/repo/asmbb/index
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

101. Сообщение от Аноним (95), 08-Дек-19, 14:24	+/–
Всё ещё не понятно, при чём тут питон и плюсы, если сравнение было с сишечкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

102. Сообщение от Аноним (102), 08-Дек-19, 14:28	+1 +/–
Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает производителям железа продавать новое железо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #156, #380

103. Сообщение от Аноним (102), 08-Дек-19, 14:40	–4 +/–
Системд на С так что Поттеринг все правильно сделал. Слава Леониду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #135

104. Сообщение от Аноним (104), 08-Дек-19, 14:43	–4 +/–
Существуют опции gcc -fprofile-generate -fprofile-use, что позволяют оптимизировать с учётом той же информации, что имеет JIT. В таком случае никаких даже теоретических преимуществ у JIT не остаётся. Но по личным наблюдениям могу сказать, что может быть как двукратный прирост(php), так и нулевой(zlib).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #414

105. Сообщение от Аноним (105), 08-Дек-19, 14:47	–2 +/–
Только он write only с максимальным ганфутингом. Уж лучше пыхтон, чем такая связка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #117, #132

106. Сообщение от Аноним (104), 08-Дек-19, 14:53	+3 +/–
Справедливости ради на Сишечке можно добиться приблизительно тех же результатов. Но от main придётся отказаться. Как и от большинства функций стандартной библиотеки и некоторых функций компилятора. Конечно, сейчас не так много архитектур процессоров как во времена появления Си, но переписывания кода с x86-64 на ARM по прежнему не приносит радости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #231, #416

107. Сообщение от Анони (?), 08-Дек-19, 14:53	+1 +/–
> Что он имел в виду? Ух как заминусовали то... А то, что прикладное ПО под линукс предпочтительно должно быть мультиархетиктурным, наверно, забыли. Под вынь, конечно же, которая до недавнего времени только x86, ясен пень легче, тем более ДОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #125

108. Сообщение от qetuo (?), 08-Дек-19, 14:53	+1 +/–
Удачи тебе на гошке реализовывать неродные для нее модели. У нее интероп с сишкой сделан настолько хорошо, что если вставлять sleep(1) в каждый вызов к сишному коду, то получится лишь ненамного хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

109. Сообщение от Аноним (105), 08-Дек-19, 14:55	+1 +/–
Почему нет примера на Форте? Это дискриминация.
Ответить | Правка | Наверх | Cообщить модератору

110. Сообщение от Ананимас009 (?), 08-Дек-19, 14:58	+/–
Тот перл скрипт был и сервером и полезной нагрузкой. И занимал копейки памяти. 8ачем сейчас так извращаться - для меня загадка. Уж лучше написать модуль для нжинкс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

111. Сообщение от Аноним (111), 08-Дек-19, 14:59	+/–
У Lua есть официальный стендэлон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

112. Сообщение от Аноним (111), 08-Дек-19, 15:01	–1 +/–
Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда на асме ничего не пишется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #124, #169, #382

113. Сообщение от dd (??), 08-Дек-19, 15:01	–7 +/–
sqlite это шаг к реестру винды,  no way
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #122, #191, #428

114. Сообщение от Аноним (166), 08-Дек-19, 15:10	+/–
> Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib > набор простых библиотек типа печать строк, чисел. Ты лучше расскажи, почему иссую не закрыл. Там даже по-русски объяснили, почему либа полурабочая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #119

115. Сообщение от Аноним (115), 08-Дек-19, 15:18	–4 +/–
Я согласен с тем мистером. Ява действительно тормозит. И всегда будет тормозить. Лучше уж пайтон использовать, или нод, или любой другой аналог, заточенный под конкретные нужды. Всегда есть выбор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #140

116. Сообщение от Ordu (ok), 08-Дек-19, 15:21	+1 +/–
>> Что он имел в виду? Под linux писать на асме гораздо приятнее >> чем под DOS или под Windows. >  ¿А что не так с MS/PC/DR DOS? > Ровно два прерывания: одно для вывода текста, второе для завершения процесса. Не, так оно только в первой половине учебника ассемблера для дос. Дальше выясняется, что всё гораздо-гораздо интереснее, и в учебнике не написано как работать с мышью, со звуком так вообще надо с железом общаться напрямую, причём с разными звуковухами по разному, работа с видеокартой -- это отдельная песня, и про неё написаны отдельные книги, и много других очень увлекательных вещей можно узнать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #244

117. Сообщение от Анонисмус (?), 08-Дек-19, 15:21	+1 +/–
Write-only - это скорее Perl, в котором, по словам его создателя, можно одну и ту же задачу выполнить несколькими способами. Это значит, что читать такой код будет нелегко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #179, #274

118. Сообщение от Аноним (95), 08-Дек-19, 15:26	+/–
Там не мелочь, производительность может и на порядки отличаться в результате работы pgo. Это без модификации исходников, да. Ручками тоже можно сделать необычные оптимизации, но они будут не универсальны, профиты жита с аот именно в оптимизации под данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

119. Сообщение от Аноним (102), 08-Дек-19, 15:30	+/–
Я не автор, но от себя скажу что ваши syscall это вкусовщина, а int 0x80 работает и на 32 и на 64 битных системах. Да и тем более исходники открыты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #144, #233

120. Сообщение от Аноним (95), 08-Дек-19, 15:33	+/–
Никто не заставляет оптимизировать "вотпрямщас" (хотя есть и такая возможность и в рантайме есть _намного_ больше вариантов), никто не заставляет оптимизировать в 1 проход, никто не заставляет оптимизировать только под 1 вариант входных данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

121. Сообщение от Аноним (121), 08-Дек-19, 15:34	+/–
а джава молодец, уцепился таки зубами за последний вагон уходящего поезда
Ответить | Правка | Наверх | Cообщить модератору

122. Сообщение от kai3341 (ok), 08-Дек-19, 15:36	+/–
>  sqlite это шаг к реестру винды,  no way То есть вы настаиваете на том, что идейность важнее здравого смысла? Кстати, где вы реестр нашли? Хм. Похоже, идейность уже заменила вам здравый смысл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #137

123. Сообщение от Retrosharer (?), 08-Дек-19, 15:39	+1 +/–
Вот это поворот!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

124. Сообщение от Аноним (124), 08-Дек-19, 15:42	+5 +/–
Си позволяет делать прямые ассемблерные вставки для радикального увеличения скорости конкретных фрагментов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #242

125. Сообщение от Ordu (ok), 08-Дек-19, 15:44	–1 +/–
>> Что он имел в виду? > Ух как заминусовали то... А то, что прикладное ПО под линукс предпочтительно > должно быть мультиархетиктурным, наверно, забыли. Ой, ну это же совершенно отдельный вопрос. Это сильно зависит от того, что ты пишешь и зачем ты это пишешь. Кому предпочтительна мультиархитектурность? Мне? Зачем? У меня есть amd64 и arm64, и как-то так выходит, что если я чего-то пишу, то только для одной из этих платформ. Какая мне разница, будет ли такая писанина мультиархитектурной? > Под вынь, конечно же, которая до недавнего времени только x86, ясен пень > легче, тем более ДОС. ДОС сложнее, поверь мне. Там костыли на костылях, костылями погоняют. Если глянуть на историю DOS и программ под него, там можно увидеть, что официальной документации на DOS программистам как правило не хватало, поэтому они лезли в кишки доса и биоса, и поэтому очень быстро DOS'у, для того, чтобы развиваясь не ломать совместимость с существующим софтом, пришлось отказаться от внутренних архитектурных изменений, поэтому всё что появлялось нового реализовывалось в виде наслоений на старое. То же самое с bios'ом. То же самое с самой архитектурой x86. И поэтому программирование под DOS -- это всегда увлекательный квест. Я очень люблю его, и люблю я его именно за те анальные боли, которые он причиняет. Хотя надо признаться, уже лет десять не страдал подобным. Венда чем-то лучше DOS, но там нет никакого кайфа писать на асме, ты всё равно точно так же будешь дёргать функции из всяких там kernel32.dll, user32.dll, и десятка других, потому что иначе никак. Ну и нафиг это надо? В лине же, ты берёшь список констант для сисколлов, и по большому счёту это и всё. Да, если ты хочешь общаться с X11, неплохо было бы взять xlib или xcb, чтобы не реализовывать X-протокол самостоятельно, но даже это не очень обязательно: не так уж сложно реализовать те кусочки протокола, которые тебе нужны. Почему в лине плохо писать на ассемблере -- это потому, что никто не пишет. Поэтому всё очень плохо с утилитами заточенными под написание программ на ассемблере. Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно. Может его можно заточить под это -- в конце-концов его можно расширять скриптами, -- но я не уверен с каким результатом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #246

126. Сообщение от VEG (ok), 08-Дек-19, 15:48	–2 +/–
Не увидел чтобы автор видео агитировал за написание всего кода на асме. Просто на практике показал что все удобства даются не бесплатно. Обещал ещё показать в следующих частях какие-то преимущества. Скорее всего покажет что компилеры способны генерировать оптимальный код только в простейших случаях, а толково применять SSE/AVX вообще толком не могут, и ручная оптимизация тут рулит на всю катушку. Полагаю, что основной посыл будет использовать асм там где это имеет смысл. Его и используют. Для оптимизации кодеков, например. Надо же чтобы кто-то это рассказал подрастающему поколению, вот автор видео и старается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #129, #131, #153, #234

127. Сообщение от Аноним (127), 08-Дек-19, 15:50	–2 +/–
Ассемблер рулез
Ответить | Правка | Наверх | Cообщить модератору

128. Сообщение от Сергей (??), 08-Дек-19, 15:52	+4 +/–
Интересно, что perl чуть-чуть проиграл bash, с другой стороны все эти тесты говорят об одном - о нагромождение ненужных прослоек в фреймворках. Вспоминаю молодость, студент, была дадена ес-1840, в качестве задания писал программу на паскале, потом профилирование и переписывание кусков кода с него на ассемблер, благо там это легко было сделать, когда первый раз сделал слегка удивился...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #205, #332

129. Сообщение от Аноним (90), 08-Дек-19, 16:00	+3 +/–
> Компилеры способны генерировать оптимальный код только в простейших случаях Лол что? Это человек способен генерировать оптимальный код на ассемблере только в простейших случаях. Для большого куска кода у человека от писанины на ассемблере крыша поедет, а о том, чтобы превзойти по оптимальности код компилятора даже речи идти не будет. Современные компиляторы далеко ушли по сравнению с 80-ми, а вы похоже там и остались. Сейчас оптимизация кода производится на многих уровнях, особенно хорошо разработаны оптимизации AST-дерева, которое человек в принципе в голове удержать целиком не способен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #199, #217

130. Сообщение от Ноним (?), 08-Дек-19, 16:04	+3 +/–
Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #139, #160

131. Сообщение от Forth (ok), 08-Дек-19, 16:06	+3 +/–
Тут бы лучше взять пример какой-нибудь прикладной задачи, причем не обязательно с плавающей точкой и векторными операциями. Полно алгоритмов, где важны DMIPS-ы. Тот же поиск короткого пути в графе или например всякие алгоритмы на строках, типа наибольшей общей подпоследовательности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #254

132. Сообщение от Ноним (?), 08-Дек-19, 16:10	–3 +/–
Уж лучше сразу на плюсах писать чем на динамически типизированном мусоре
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #138

133. Сообщение от Аноним84701 (ok), 08-Дек-19, 16:14	+1 +/–
> Ещё в природе существует https://github.com/nemasu/asmttpd Это про который в опеннетной новости писали > Интересно, что несмотря на то, что код написан на ассемблере, проведённые (https://news.ycombinator.com/item?id=9571827) пользователями тесты производительности показывают > существенное отставание по скорости обработки запросов от современных http-серверов, написанных на языке Си. (а еще сам автор собирался делать: https://github.com/nemasu/asmttpd/issues/9 My current plan for handling 10k+ connections, will edit as it's improved. Comments are welcome :) Idea: Don't block on anything until it's ready. When waiting for I/O, accept more connections. +Asynchronous I/O. +Non-blocking sockets. +Multi-threaded. +Self contained threads.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #151

134. Сообщение от Annoynymous (ok), 08-Дек-19, 16:18	+2 +/–
> Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными. Где, собственно, Java и применяется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #415

135. Сообщение от Аноним84701 (ok), 08-Дек-19, 16:19	+2 +/–
> Системд на С Как и (ba/da/z/k/c/ok/mk)sh. Впрочем, как и куча реализаций брейнфака (но там и на асме реализации есть). Ждем переписывания на BF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #150

136. Сообщение от Аноним (54), 08-Дек-19, 16:20	+1 +/–
> apt, apt-get, aptitude, dpkg тормозят ещё больше ЛПиП Показывай time на аналогичных командах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #188

137. Сообщение от Аноним (54), 08-Дек-19, 16:22	+2 +/–
Где ты нашёл здравый смысл? sqlite тормозит сильнее, чем xapian.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #157

138. Сообщение от Аноним (54), 08-Дек-19, 16:24	+3 +/–
Ну зачем сразу из крайности в крайность?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #424

139. Сообщение от Аноним84701 (ok), 08-Дек-19, 16:27	+3 +/–
> Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая? Админы нелокалхоста не слышали об ACID? o_O Или же для них реализовать трансакцию/atomic commit на любой ФС  - "как два пальца"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #227, #387

140. Сообщение от Аноним (88), 08-Дек-19, 16:37	+3 +/–
Когда говорим про долгоиграющие приложения, то Ява существенно быстрее ноды. А нода быстрее пихона. (Уже запущенная Ява тормознее с++ всего в полтора раза.) Более того, в Яве тру многопоточность, а в пихоне и ноде ее нет. Далее, в пихоне нет нормальной jit, а в ноде и Яве есть. Единственное, когда Ява тормознее - запуск. Поэтому одноразовые скрипты (написал, запустил и удалил) лучше писать на ноде или пихоне.  А серьезные долгоиграющие приложения - на Яве. Особенно если важна скорость отклика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #158, #159

141. Сообщение от nc (ok), 08-Дек-19, 16:39	+3 +/–
Это все говорит не о том что надо писать на Ассемблере, а о том, что подходы к компиляции и особенно к "линковке" в языках программирования ужасно устарели. Если на ассемблере программа занимает 9 инструкций, то и на высокоуровневом ЯП она должна занимать 9 инструкций, не больше. А почему занимает больше? А потому что процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #146

142. Сообщение от Аноним (54), 08-Дек-19, 16:43	+2 +/–
Попробуй слинковать статически. Лучше с musl. У меня получилось 5 для hello_c_stdio и 4 для hello_c_syscall.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #334

144. Сообщение от Аноним (166), 08-Дек-19, 16:46	+1 +/–
> Я не автор, но от себя скажу что ваши syscall это вкусовщина, > а int 0x80 работает и на 32 и на 64 битных > системах. Да и тем более исходники открыты. Да, исходники открыты. Вот возьми их и почитай, посмотри, с какими ограничениями он работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #149

146. Сообщение от Аноним (54), 08-Дек-19, 16:49	+/–
> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет Почему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за 20 лет мало что изменилось, но это не значит, что подход устарел).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #185

147. Сообщение от Адекват (ok), 08-Дек-19, 16:51	+/–
Не хочу показаться занудным, но в случае с ассемблером он сначала просто запустил бинарик, а потом второй раз через strace. Во время второго запуска программа считывалась из памяти а не с винта. В случае с СИ он сразу запускал бинарик через strace, то есть были доп затраты на чтение с винта. Как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #155

149. Сообщение от Аноним (151), 08-Дек-19, 17:12	+/–
С незначительными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #163

150. Сообщение от Аноним (151), 08-Дек-19, 17:13	–2 +/–
Ну и спрашивать зачем все по десять раз интерпретировать, когда можно сразу написать на C хотя системд и интерпретирует свои юнит файлы, зато он делает это с уважением и с благословения Лёни Поттеринга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #250

151. Сообщение от Аноним (151), 08-Дек-19, 17:17	+1 +/–
Может asmhttpd не на производительность заточен, а на потребление памяти. Вон в rwasa бенчмарке от производителя тоже написано что при определенных видах запросов nginx его обгонят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #423

153. Сообщение от Аноним (31), 08-Дек-19, 17:28	+/–
>а толково применять SSE/AVX вообще толком не могут OpenCL-компиляторы -- могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #420

154. Сообщение от burjui (ok), 08-Дек-19, 17:33	+/–
Нет: $ rustup toolchain list stable-x86_64-unknown-linux-gnu (default) $ rustc --version rustc 1.39.0 (4560ea788 2019-11-04)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #174

155. Сообщение от Аноним (151), 08-Дек-19, 17:34	+/–
Количество вызовов от этого не меняется в среднем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

156. Сообщение от Аноним (156), 08-Дек-19, 17:39	–1 +/–
паскаль никогда не был тормозом. проблема его в том что синтаксис слишком замудренный, долго писать, тяжело читать исходники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #168

157. Сообщение от kai3341 (ok), 08-Дек-19, 17:42	–4 +/–
>  Где ты нашёл здравый смысл? sqlite тормозит сильнее, чем xapian. А чтобы поиск не тормозил, мы в дополнение к базе пакетов на диске добавим xapian! Это же так здорово, когда для выполнения одной и той же задачи используются сразу 2 вещи одновременно! И работающий всё время сервис -- это же так круто! Ведь пользователь занимается поиском пакетов всё свободное время!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #190

158. Сообщение от Аноним (158), 08-Дек-19, 17:44	+/–
Ява, как и Нода, как и Питон всего лишь инструменты. Меня всегда поражали умники, которые сравнивают ЯП и приходят к тому, что один хуже другого, потому что [подставить своё]... Естественно у одного ЯП это удобнее и лучше, а другое нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

159. Сообщение от Аноним (158), 08-Дек-19, 17:46	+/–
Это я в общем о тенденции, а не о конкретно вашем комментарии. Он, в отличие от распространённой тенденции на опеннете, адекватный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

160. Сообщение от kai3341 (ok), 08-Дек-19, 17:47	–1 +/–
>  Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая? Произвольный доступ к диску уже приблизился по скорости к последовательному? Индексы на ФС уже завезли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #167, #273

161. Сообщение от имя_ (?), 08-Дек-19, 17:47	+/–
> Какой ещё PHP в XXI веке? Python, Java. с каждым новым релизом пхп и так движется в сторону питона и явы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

162. Сообщение от Аноним (158), 08-Дек-19, 17:47	+/–
Не говори за всех. Если тебе не нужно - это не означает, что никому не нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

163. Сообщение от Аноним (166), 08-Дек-19, 17:48	+1 +/–
> С незначительными. Ну так то да. Всего-то наполовину меньше. Действительных разрядов в адресе. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #313

164. Сообщение от Анонисмус (?), 08-Дек-19, 17:55	+5 +/–
Можно использовать microdnf, который python-free: https://github.com/rpm-software-management/microdnf Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #182, #376

165. Сообщение от Аноним (165), 08-Дек-19, 18:08	+2 +/–
Я просто шокирован как он быстро пишет код в real-time и по памяти может воспроизвести код (пусть и простейший) нескольких языков.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #256

166. Сообщение от Аноним (166), 08-Дек-19, 18:08	+1 +/–
>> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum? > А что именно там тормозит не подскажете? Где узкое место? Про эти не скажу, а вот в ROSA Fresh тормозил rpm5 из-за беспорядочно вызываемого fdatasync(). Процессорные ядра почти свободны, а система стоит колом, пользоваться невозможно, пришлось исправлять. Забавно, что сами разработчики не замечали (на виртуалке не проявляется).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #389

167. Сообщение от Аноним (54), 08-Дек-19, 18:15	+/–
> Произвольный доступ к диску уже приблизился по скорости к последовательному? Да, уже лет много как придумали SSD. > Индексы на ФС уже завезли? Apt использует xapian для индексов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #173

168. Сообщение от Аноним (166), 08-Дек-19, 18:17	+7 +/–
> паскаль никогда не был тормозом. проблема его в том что синтаксис слишком > замудренный, долго писать, тяжело читать исходники. Пришлось мне когда-то делать проектик на Pascal, который на практике я не использовал. Реализовал всё в срок, сначала написал и отладил на плюсах, потом день читал PDF от Free Pascal и день переводил исходник. Непривычно, не более. Считаю, что язык был закопан исключительно по политическим мотивам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #170, #355

169. Сообщение от Аноним (166), 08-Дек-19, 18:24	+/–
> Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда > на асме ничего не пишется. Наглядно демонстрирует, что новость можно комментировать не читая и не заходя на сайт автора rwasa is our full-featured, high performance, scalable web server designed to compete with the likes of nginx. It has been built from the ground-up with no externel library dependencies entirely in x86_64 assembly language, and is the result of many years' experience with high volume web environments. In addition to all of the common things you'd expect a modern web server to do, we also include assembly language function hooks ready-made to facilitate Rapid Web Application Server (in Assembler) development. https://2ton.com.au/rwasa/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #208, #344

170. Сообщение от Anonymoustus (ok), 08-Дек-19, 18:29	+7 +/–
> Считаю, что язык был закопан исключительно по политическим мотивам. Скорее — по быдлокодерским. В отрочестве будущих обезьян часто обучают Паскалю, из-за чего они его начинают люто ненавидеть. Это иррациональное, на уровне условного рефлекса. При такой ненависти к Паскалю _эти же_ люди роняют сопли вожделения в адрес жлобоскрипта и пихтона. Лечить только биореактором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #175

171. Сообщение от Anonymoustus (ok), 08-Дек-19, 18:34	–1 +/–
>> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. > А она вообще может показать хороший результат? Сколько я ни пытался использовать > жабософт, положительных эмоций от него не испытывал ни разу. Тормозит и > жрёт всю память, что видит. Нет, не так: ТОРМОЗИТ ДАЖЕ НА > РОВНОМ МЕСТЕ и жрёт всё, до чего может только дотянуться. И > ещё прогрева какого-то требует, как жигуль в морозы. Если это — > новые и современные технологии, то мой член — первый заместитель Папы > Римского. У Жаббы ощутимо тормозит прежде всего ГУЙ, да и то не всегда. А если консольное и «после разогрева», как тут уже заметили, то Жаба не хуже Сишечки, ЦПП и других «быстрых» ЯП. Попробуй написать на Жаббе простое консольное приложение, которое принимает от пользователя какие-то числа и считает их по каким-то твоим формулам — сам всё увидишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #393

172. Сообщение от Аноним (166), 08-Дек-19, 18:34	–2 +/–
>> Что он имел в виду? Под linux писать на асме гораздо приятнее >> чем под DOS или под Windows. >  ¿А что не так с MS/PC/DR DOS? > Ровно два прерывания: одно для вывода текста, второе для завершения процесса. У x86 (16-ти разрядный набор команд) нет плоской модели памяти, приходится заморачиваться с сегментами, а регистры "общего назначения" заметно специализированы. Если бы всё было так же просто как в 32-х и 64-х режимах, в то время больше бы писали на ассемблере, поскольку тогда компиляторы заметно отставали по скорости сгенерированного кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #245

173. Сообщение от kai3341 (ok), 08-Дек-19, 18:36	+/–
>> Произвольный доступ к диску уже приблизился по скорости к последовательному? > Да, уже лет много как придумали SSD. Как говорил Чапаев, есть один нюанс. С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт? >> Индексы на ФС уже завезли? > Apt использует xapian для индексов. Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #335

174. Сообщение от Аноним (95), 08-Дек-19, 18:38	+/–
$ rustc --version rustc 1.39.0 Это что же получается, раст продуцирует рандомный код? Хотелось бы иметь хоть какую-то воспроизводимость, а то так на одной машине код будет выполняться за минуту, а на другой за тысячу. Хотя... llvm у меня в расте 9.0.0 - может, это как-то связано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #195

175. Сообщение от Аноним (166), 08-Дек-19, 18:39	+/–
Вот этих упомянутых умело сыграли политики. Как раз в такую среду легко заходит аргумент "профессор не шарит!", с которым они прыгали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #183

176. Сообщение от Главный Ананим (ok), 08-Дек-19, 18:42	+/–
Почему у Си-плюсов на порядок больше инструкций чем у чистого Си? А как же оптимизирующие компиляйторы, которые якобы компилируют код Си и Си++ выполняющий одни и те же действия в одни и те последовательности инструкций? Кто то нам врёт, только вот кто?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #180, #187, #194, #213

177. Сообщение от Аноним (177), 08-Дек-19, 18:46	+1 +/–
Delphi Pascal forever!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #184

178. Сообщение от svsd_val (ok), 08-Дек-19, 18:49	+/–
Не вижу ничего особого в этих тестах, да это только холодный запуск и выход... Да для каждого языка эти процессы уникальные, хотелось бы видеть расчёт производительности непосредственно... правда тогда эти расхождения не будут столь существенными. Ассемблер это конечно хорошо и Я сам часто им пользовался в ускорении математических операций, но что то тяжёлое делать на нём я бы всё же не стал, имхо поддерживать это будет очень и очень сложно, да и выстрелить себе в ногу в разы легче чем в том же си... Теперь подумаем по поводу разумного соотнесения плюшек и производительности. На ассемблере программист должен сам за всё отвечать за каждый пук... Другие языки же решают свои задачи и предоставляют те или иные плюшки чем облегчают работу программисту и уменьшают количество возможных ошибок. имхо, нужно было бы проверить на циклах, математики к (примеру умножение двух матриц) и работы со строками... тогда можно увидеть более интересную картинку, многие языки будут в этом тесте вести себя одинаково.
Ответить | Правка | Наверх | Cообщить модератору

179. Сообщение от Q2W (?), 08-Дек-19, 18:57	+3 +/–
Perl write only только у тех, кто специально или от непрофессионализма пишет write only код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

180. Сообщение от svsd_val (ok), 08-Дек-19, 18:58	+1 +/–
Потому что набор вызовов на холодном старте у всех свой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

181. Сообщение от Алексей Михайлович (?), 08-Дек-19, 18:59	–1 +/–
> Плохому танцору Ява мешает. Кошка бросила котят - это Ява виноват. А и я не пишу на этом фекалоиде, у меня хватает ума выбирать инструменты получше. > Использую продукцию джетбрейнс - не тормозит. На хэллоуворлдах что угодно не тормозит. Ты попробуй нормальный проект в ней открыть, а лучше — поразрабатывать. Тогда-то и поймёшь, что твои студенческие поделки в тысячу строк — херня. > Использую онлайн-банк, о котором доподлинно известно, что он на Ява ЕЕ - не тормозит. А теперь прикинь хотя бы приблизительно, сколько бабла банк потратил на оборудование, которое это тянет, и сколько ещё по дороге распилили. И вообще, зачем взяли именно самое неадекватное по потреблению ресурсов решение. > Ява - это не КГИ, который запускается с нуля на каждый ХТТП-реквест. > Ява для долгоиграющих приложений. Жаба для того, чтобы показывать её как пример максимально отвратительной реализации как ЯП, так и рантайма, VM и всего остального, что к ней относится. > Если конкретно у тебя все тормозит, пиши мне на почту, хочу купить > твой комп, - я коллекционирую железо 80-90 годов. У меня свеженький десктоп и околотоповый ноут 2013 года. Летает всё, кроме этой вашей жабы. Даже всякое безобразие на пыхтоне нормально крутится, ибо не сжирает под себя всю доступную память, залезая своими грязными ручищами в мой девственно чистый своп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #201

182. Сообщение от Илья (??), 08-Дек-19, 18:59	+/–
> Можно использовать microdnf, который python-free: > https://github.com/rpm-software-management/microdnf > Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни. Спасибо, на меня просмотр работы обновления dnf очень положительно влияет. Прихожу домой с работы, sudo dnf upgrade и сижу зачем-то смотрю, как он работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #193

183. Сообщение от Anonymoustus (ok), 08-Дек-19, 19:00	+/–
> Вот этих упомянутых умело сыграли политики. Как раз в такую среду легко > заходит аргумент "профессор не шарит!", с которым они прыгали. На Лурке про это есть: lurkmore.to/Pascal#.D0.93.D0.BB.D1.83.D0.B1.D0.B8.D0.BD.D0.BD.D1.8B.D0.B5_.D0.BF.D1.80.D0.B8.D1.87.D0.B8.D0.BD.D1.8B_.D0.BD.D0.B5.D0.BD.D0.B0.D0.B2.D0.B8.D1.81.D1.82.D0.B8_.D0.BA_Delphi.2FPascal «Человеческий фактор».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #278

184. Сообщение от svsd_val (ok), 08-Дек-19, 19:00	+2 +/–
Хорошие языки, ничего против не имею, кстати интересно было бы увидеть и их тесты
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #192, #310

185. Сообщение от Аноним (166), 08-Дек-19, 19:07	+1 +/–
>> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет > Почему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за > 20 лет мало что изменилось, но это не значит, что подход > устарел). Напомните, пожалуйста, на какой странице там LTO описано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #340

186. Сообщение от Аноним (186), 08-Дек-19, 19:10	+1 +/–
Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #197, #289

187. Сообщение от Аноним (166), 08-Дек-19, 19:10	+/–
> Почему у Си-плюсов на порядок больше инструкций чем у чистого Си? Из-за использования потоков ввода-вывода. Иначе говоря, дело в реализации стандартной библиотеки, а не в языке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

188. Сообщение от Dnf (?), 08-Дек-19, 19:11	–1 +/–
Нет смысла сравнивать dnf и apt.  У них возможности разные, кстати, некоторые из которых, замедляет его, но и предоставляют дополнительные плюшки, которые отсутствуют во всей плеяде apt-*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #388

189. Сообщение от Алексей Михайлович (?), 08-Дек-19, 19:12	–2 +/–
> Конец списка переместится в начало достаточно быстро, просто потому что ты не > сможешь оптимизировать ассемблер на лету в зависимости от данных, как это > делает жит. А делает он это бесплатно, посредством привлечения чёрной магии. Пока твой JIT только-только сообразит, как перепилить программу под меняющиеся данные на входе, программа на нормальном языке уже выдаст результат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

190. Сообщение от имя (ok), 08-Дек-19, 19:17	+1 +/–
> И работающий всё время сервис -- это же так круто! Xapian — библиотека, а не сервис. Вас, видимо, очень больно покусали фанатики Elasticsearch.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #386

191. Сообщение от имя (ok), 08-Дек-19, 19:21	+/–
> sqlite это шаг к реестру винды,  no way Я вам реестров принёс: http://mirror.centos.org/centos-7/7/os/x86_64/repodata/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

192. Сообщение от Аноним (192), 08-Дек-19, 19:40	+2 +/–
Выше есть Паскаль обогнал всех кто не ассемблер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

193. Сообщение от Анонисмус (?), 08-Дек-19, 19:50	+1 +/–
Не факт, что в этом виноват именно dnf, а не скорость Вашего интернет-соединения или ширина канала зеркала откуда обновляетесь. Ещё не факт, что у Вас не установлено кучу пакетов, о назначении которых Вы даже не догадываетесь. Есть возможность выкачивать только дельты пакетов: https://stackoverflow.com/questions/30553951/how-to-enable-d...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #198

194. Сообщение от Моржовый (?), 08-Дек-19, 19:54	+/–
Потому что у них разные стандартные загрузчики (stub'ы), у плюсов стандартная библиотека толще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

195. Сообщение от имя (ok), 08-Дек-19, 19:55	+/–
> Хотелось бы иметь хоть какую-то воспроизводимость Говорят, что они к этому весьма близки: https://github.com/rust-lang/rust/issues/34902#issuecomment-...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

196. Сообщение от Моржовый (?), 08-Дек-19, 19:58	–2 +/–
Вот аналог программы на ассемблере, написанный на C: /* *!gcc -e_Main -nostdlib -o "%<" % -lmsvcrt -lkernel32 && "%<" */ #include <stdlib.h> #include <stdio.h> #include <windows.h> void Main() {     char s[] = "hello\n";     const unsigned sSize = sizeof(s)/sizeof(s[0]) - 1;     /*fwrite(s, sSize, 1, stdout);*/     DWORD outCnt;     WriteConsole(         GetStdHandle(STD_OUTPUT_HANDLE),     //handle to a console screen buffer         s,     //pointer to buffer to write from         sSize,     //number of characters to write         &outCnt,     //pointer to number of characters written         NULL     //reserved    );     /*WriteFile(         GetStdHandle(STD_OUTPUT_HANDLE),    // handle to file to write to         s,    // pointer to data to write to file         sSize,    // number of bytes to write         &outCnt,    // pointer to number of bytes written         NULL     // pointer to structure needed for overlapped I/O    );*/ } И, внезапно, окажется что это то же самое что и асм, только приятней и проще.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #211, #219, #282, #291

197. Сообщение от СеменСеменыч777 (?), 08-Дек-19, 20:09	+1 +/–
> Еще один хипстор опубликовал видосик. И как я его в Links посмотрю? на хоткей вешаем связку youtube-dl | awk '... извлечь имя_видеофайла ...' mpv имя_видеофайла echo 1-Удалить видео echo 2-Еще раз посмотреть видео echo 3-Выход accept
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

198. Сообщение от Аноним (198), 08-Дек-19, 20:18	–1 +/–
Я так понимаю, тот единственный (на данный момент) человек, который плюсанул этот коммент - это тот единственный человек, который считает нормой необходимость устанавливать отдельный пакет и править конфиги, чтобы получить функционалность, которая должна быть из коробки и включена по дефолту (а она отсутствует, потому что "they have problems with certain things").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #223

199. Сообщение от Анонисмус (?), 08-Дек-19, 20:31	+1 +/–
Вот куда ушли современные компиляторы и технологии: How new-lines affect the Linux kernel performance. https://nadav.amit.zone/linux/2018/10/10/newline.html Думаю, заголовок статьи говорит сам за себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #210, #221

200. Сообщение от Аноним (198), 08-Дек-19, 20:34	+/–
А что, нельзя прилинковать её к сишной программе и дёргать из сишного кода?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

201. Сообщение от Аноним (88), 08-Дек-19, 20:35	+1 +/–
> прикинь хотя бы приблизительно, сколько бабла банк потратил на оборудование А прикинь, сколько он бы потратил на программистов, пиши и сопровождай они бизнес логику на ассемблере/с/спп? Тем более, что в Яве тормозит только гуйная подсистема. И то не настолько, чтобы это было заметно. Скажем, к отзывчивости гтк-приложений у меня больше претензий, чем к идее, хотя они написаны на си. Допустим, gedit напрочь зависает при попытке открыть текстовый файл с единственной, но очень длиной строкой. Понятно, что это не из-за си, а из-за гедита, но зато демонстрирует, что гуй тормозит в первую очередь из-за конечного приложения или гуйной подсистемы. В случае с Явой тормозит свинг. А веб-приложения от свинга не зависят, поэтому твой аргумент про то, что (лично) у тебя тормозит гуй, идёт мимо (банковской) кассы. > Жаба для того, чтобы показывать её как пример максимально отвратительной реализации как ЯП, так и рантайма, VM и всего остального, что к ней относится. Конкретики не хватает. Звучит громко, но не убедительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #410

202. Сообщение от nuclight (??), 08-Дек-19, 20:38	+/–
Удивительно, как Питон почти на порядок просел относительно него.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #251, #422

203. Сообщение от Аноним (198), 08-Дек-19, 20:39	+/–
"Once upon a time my boss asked me to study if we should use C++ or Erlang for a specialist XML parser to be used in a product (for reasons of speed not energy). My recommendations was an FPGA We built an FPGA. Relative speed of C++/Erlang was irrelevant compared to FPGA." https://twitter.com/joeerl/status/1115990630793207808
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #216, #287, #315

204. Сообщение от колба (?), 08-Дек-19, 20:41	+/–
весь трюк в том что хитрый ассемблер протащил свой рантайм в фирмварь железки и этот рантайм уже запущен на момент старта теста в то время как всем остальным его придётся сначала запустить..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #392

205. Сообщение от Аноним (198), 08-Дек-19, 20:41	+2 +/–
> ес-1840 *пустил скупую мужскую слезу*
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #235

206. Сообщение от колба (?), 08-Дек-19, 20:44	–1 +/–
секрет в том что там где жабософт хороший и не тормозит ты его даже не заметишь, а там где джаву не к месту запихнули выходит ожидаемое неуместное говно..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #224

207. Сообщение от AleksK (ok), 08-Дек-19, 20:48	+3 +/–
Установка обновлений винды тут вообще вне конкуренции прилетела маленькая заплатка а такое ощущение что полсистемы переустанвливается. И в чем хоть проявляется тормознутость apt? Установка той же 1С на винде занимет гораздо больше времени чем установка пакетов в Ubuntu. Можно ещё быстрее? Ну возможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #280

208. Сообщение от Аноним (31), 08-Дек-19, 20:49	–1 +/–
>entirely in x86_64 assembly language удачи ему в запуске этого говна на risc-v и arm. Да даже просто на x86.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #275

209. Сообщение от Аноним (209), 08-Дек-19, 20:51	+/–
А чо девять-то? У меня восемь вышло.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #212

210. Сообщение от Аноним (95), 08-Дек-19, 20:58	+/–
Недавно видел историю где слово register (то самое против которого все топят) применённое к переменной-счётчику, ускоряло код в 9999 раз. Компиляторы такие умные сегодня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

211. Сообщение от Аноним (211), 08-Дек-19, 21:01	+8 +/–
Mscvrt, windows.h? Это ты так пошутил? Плохое место ты для этого выбрал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

212. Сообщение от Аноним (121), 08-Дек-19, 21:09	+1 +/–
ты особенный, гордись этим
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209

213. Сообщение от erthink (ok), 08-Дек-19, 21:12	+1 +/–
Потому-что в этом тесте запуск приложения на Си требует загрузки ld.so и libc.so, на для приложения на С++ дополнительно требуется libstdc++.so, а также вызова конструкторов и деструкторов для всех статических объектов (включая инфраструктуру Thread Local Storage). Если различной "магией" избавиться от вышеуказанного, то разницы с ассемблером для C, C++ и Rust не будет _совсем_.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

214. Сообщение от Vkni (ok), 08-Дек-19, 21:17	+2 +/–
> Хотя она была и есть на своём месте в больших сложных приложениях Только там сложность зачастую искусственная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

215. Сообщение от Vkni (ok), 08-Дек-19, 21:23	+1 +/–
В bash "echo" - это builtin. Выжимка strace ./hello_world.sh: stat("./hello_world.sh", {st_mode=S_IFREG|0755, st_size=30, ...}) = 0 ioctl(3, TCGETS, 0x7ffecf9069c0)        = -1 ENOTTY (Inappropriate ioctl for device) lseek(3, 0, SEEK_CUR)                   = 0 read(3, "#!/bin/bash\necho Hello World!\n", 80) = 30 lseek(3, 0, SEEK_SET)                   = 0 prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=16*1024, rlim_max=16*1024}) = 0 fcntl(255, F_GETFD)                     = -1 EBADF (Bad file descriptor) dup2(3, 255)                            = 255 close(3)                                = 0 fcntl(255, F_SETFD, FD_CLOEXEC)         = 0 fcntl(255, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE) fstat(255, {st_mode=S_IFREG|0755, st_size=30, ...}) = 0 lseek(255, 0, SEEK_CUR)                 = 0 read(255, "#!/bin/bash\necho Hello World!\n", 30) = 30 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0 write(1, "Hello World!\n", 13Hello World! )          = 13 read(255, "", 30)                       = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(0)                           = ? +++ exited with 0 +++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

216. Сообщение от Vkni (ok), 08-Дек-19, 21:26	+1 +/–
Тот же Ragel позволяет выдать код лексера, который примерно в 10 раз быстрее сгенерированного flex'ом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

217. Сообщение от VEG (ok), 08-Дек-19, 21:27	+2 +/–
Мечтать не вредно, конечно, но компилеры далеки от того, чтобы самостоятельно задействовать SSE/AVX так, как это мог бы сделать человек. Возьмём в качестве примера libjpeg-turbo. Этот проект - оптимизация обычного libjpeg. Проект проспонсирован кучей видных компаний (https://libjpeg-turbo.org/About/Sponsors), результат используется во всех браузерах и Android. А если заглянете в исходный код, чтобы посмотреть как оптимизировали, то найдёте пачки *.asm файлов (https://github.com/libjpeg-turbo/libjpeg-turbo/tree/master/s...). Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus. Но это, по сути, ассемблер с синтаксисом C. Что касается качества генерируемого кода C компилеров для обычного кода (который не оптимизируешь с использованием SSE/AVX), то он был весьма посредственного качества не только в 80-х, но и в 90-х (я провёл много времени дизассемблируя игры того времени, знаю о чём говорю). Современные компилеры - да, достаточно умны, чтобы в общем случае генерировать достаточно оптимальный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #252, #327

218. Сообщение от цука (?), 08-Дек-19, 21:28	+/–
В каком месте смеяться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

219. Сообщение от erthink (ok), 08-Дек-19, 21:30	+/–
На Windows для всех языков не будет такой большой разницы, т.е. все сильно сместится в сторону Java. Это просто последствия намеренного дизайна Windows, и уже без возможности что-либо существенно изменить. Но если же предложенное проделать в нормальных ОС, то действительно, для C, C++ и Rust с ассемблером существенных различий не будет. Точнее говоря, разница будет определяться только объемом оставленного "сервиса" (stdio, std::iostream, etc).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

220. Сообщение от Vkni (ok), 08-Дек-19, 21:38	+1 +/–
Промерял Ocaml - 59 syscalls. Программа: let _ = print_string "hello\n" Компиляция ocamlopt.opt -O3 -inline 1000 hello_ml.ml -o hello_ml
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #283

221. Сообщение от Аноним84701 (ok), 08-Дек-19, 21:44	+2 +/–
> Вот куда ушли современные компиляторы и технологии: > How new-lines affect the Linux kernel performance. > https://nadav.amit.zone/linux/2018/10/10/newline.html > Думаю, заголовок статьи говорит сам за себя. Думаю, читать все же желательно не только заголовки: > New lines in inline assembly ... > The reason turns to be the newline characters (marked as ‘\n’ above [asm volatile("1: ud2\n"]). The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. It therefore tries to estimate its size based on newline characters and statement separators (‘;’ on x86). In GCC, we can see the code that performs this estimation in the estimate_num_insns() function: ... > Solving the problem is not trivial. Ideally, GCC would have used an integrated assembler, similarly to LLVM, which would give better estimation of the generated code size of inline assembly. > Experimentally, LLVM seems to make the right inlining decisions and is not affected by new-lines or data that is set in other sections of the executable ... GCC, however, uses the GNU assembler after the code is compiled, Разъясняю для опеннетных аналитиков современного компиляторостроения: Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";". Решается проблема ручками (указание размера/оверрайд и т.д.) или же включением ассемблера непосредственно в компилятор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199 Ответы: #226

222. Сообщение от Сергей (??), 08-Дек-19, 22:03	+/–
Похоже Преподаватель был не Писателем, а Учителем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

223. Сообщение от Анонисмус (?), 08-Дек-19, 22:14	+/–
Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv, а не во всем выше перечисленном или в прослойке между компьютером и креслом. И конфигурацию железа, пожалуйста, добавьте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #336

224. Сообщение от Алексей Михайлович (?), 08-Дек-19, 22:21	+/–
> там где жабософт хороший и не тормозит ты > его даже не заметишь, а там где джаву не к месту > запихнули выходит ожидаемое неуместное говно.. Тогда возникает резонный вопрос: а нахрена её пихают туда, где она даром не нужна? Может, жабософт и правда бывает хорошим, но ни одного примера хорошей, годной программы на жабе пока ни диванные аналитики, ни реальные практики, не привели. Сидят, читают мантру «память дешёвая, процессоры тоже», и с примерами не спешат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

225. Сообщение от vaka (?), 08-Дек-19, 22:26	+/–
/usr/bin/echo - язык программирования? Внезапно ...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #294

226. Сообщение от Анонисмус (?), 08-Дек-19, 22:42	+/–
Надеюсь, что ты не много времени потратил на "онализ" статьи: https://www.opennet.ru/opennews/art.shtml?num=49412
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #239

227. Сообщение от Ноним (?), 08-Дек-19, 22:43	+/–
О том что ACID не нужен вам лучше других расскажет очередной адепт NoSQL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

228. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:03	+/–
Так она не на то создана, насколько вообще понимаю в этих колбасных обрезках.  А чтоб сановские железо+софт не провалились под напором винтела, потому как манагерам удобней стало бы писать софт дольше, но зато предсказуемей (в т.ч. за счёт распараллеливания по индус-триальным кодерам).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #236

229. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:09	+/–
Тогда boa был :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

230. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:11	–1 +/–
go-дюка? 8)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

231. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:12	–4 +/–
> Конечно, сейчас не так много архитектур процессоров как во времена появления Си Вообще-то дофига и продолжают появляться новые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

232. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:13	+1 +/–
Вспомнился c-- :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #249

233. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:15	–1 +/–
> а int 0x80 работает и на 32 и на 64 битных системах ...прям стесняюсь спросить, Вы точно про ARM, MIPS или даже e2k?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #311

234. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:18	+/–
> Скорее всего покажет что компилеры способны генерировать оптимальный > код только в простейших случаях, а толково применять SSE/AVX вообще > толком не могут, и ручная оптимизация тут рулит на всю катушку. Вы представляете себе хотя бы количество регистров в нынешних камнях (плюс-минус лапоть)?  А таблицы длительности команд под рукой держите?.. Рассказать-то рассказать, да не сказочку, а быль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #255

235. Сообщение от Michael Shigorin (ok), 08-Дек-19, 23:20	–1 +/–
+1 :-) Хотя чего там пускать -- айда опять же в Яндекс-музей, можно со своими ластами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

236. Сообщение от erthink (ok), 08-Дек-19, 23:27	+2 +/–
> Так она не на то создана, насколько вообще понимаю в этих колбасных > обрезках.  А чтоб сановские железо+софт не провалились под напором винтела, > потому как манагерам удобней стало бы писать софт дольше, но зато > предсказуемей (в т.ч. за счёт распараллеливания по индус-триальным кодерам). Да, но чуть дополню. Сановские манагеры искали "прорывные идеи" и жава с автоматическим управлением памятью подходила. Одновременно инженеры со стороны железа подтверждали, что в перспективе они смогу сделать и итеративно улучшать java-процессор. В том числе это коррелировало с идеями взять лучшее от микрокода CISC и IBM-овской z. Потом всё это начали быстро и "эффективно" реализовывать, приправляя евангелизмом и маркетингом. Но видимо сильно торопились в уходящий поезд, недоинженирили язык в купе с итоговой моделью памяти и т.д. и т.д. Что до сип под выражается в потере производительности из-за нелокальности обращений к памяти и других затрат, ради идеи абстрактно-красивой виртуальной машины...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

237. Сообщение от Аноним (237), 08-Дек-19, 23:30	–2 +/–
assembler - не язык программирования. Это транслятор кода. Вы ведь не пишете на компиляторе? Правильно говорить "язык ассемблера". Традиционная ошибка русскоговорящих.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #257, #261

238. Сообщение от Илья (??), 08-Дек-19, 23:58	+1 +/–
Вам - это вам и вашему супругу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

239. Сообщение от Аноним84701 (ok), 09-Дек-19, 00:08	+1 +/–
> Надеюсь, что ты не много времени потратил на "онализ" статьи: > https://www.opennet.ru/opennews/art.shtml?num=49412 Ну и? > GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте. Ты считаешь, что то перевод оригинала: ссылка из новости == предыдущая ссылка анонима https://nadav.amit.zone/blog/linux-inline => https://nadav.amit.zone/linux/2018/10/10/newline.html (с некоторыми домыслами, т.к. "inline" по стандарту c99 - только хинт > A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared > only once. Making a function an inline function suggests that calls to the function be as fast as possible. > The extent to which such suggestions are effective is implementation-defined. и компилятор си не может учитывать фактический размер вставок "foreign" кода: > Разъясняю для опеннетных аналитиков современного компиляторостроения: > Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";". более "убедителен" или опять "онализировал" только заголовки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226

240. Сообщение от j3t (?), 09-Дек-19, 00:17	+/–
Его усиленно на Си переписывают
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #375

241. Сообщение от cutlass (?), 09-Дек-19, 00:32	+/–
Пых неплох
Ответить | Правка | Наверх | Cообщить модератору

242. Сообщение от Урри (?), 09-Дек-19, 01:00	+2 +/–
На данном историческом этапе эта задача успешно решается интринсиками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

243. Сообщение от Урри (?), 09-Дек-19, 01:03	+/–
Исключения - один из множества механизмов С++, далеко не самый важный и большой. Называть отсутствие исключений "очень кастрированный" - это показывать свою техническую неграмотность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

244. Сообщение от Урри (?), 09-Дек-19, 01:05	–2 +/–
Для мыши есть int 33. И в учебниках это было описано еще тогда, когда вас у родителей и в планах не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #259, #413

245. Сообщение от Урри (?), 09-Дек-19, 01:11	+3 +/–
В то время на ассемблере больше и писали. Ассемблер был везде. И никаких "заморочек" с сегментами не было. Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки. Поколение вебмакак уже в элементарную математику второго класса общеобразовательной школы не может. А селекторы в 32 и 64 - не заморочки? Кто из вас сможет с ручкой в руках привести линейный адрес в физический? Кто из вас вообще в курсе, что в памяти есть специальная таблица трансляции, куда надо обратиться по специальному селектору, чтобы узнать куда и как смещать линейный адрес, какой размер страницы в памяти и присутствуют ли они вообще физически? А перед этим еще надо права доступа проверить... "Заморочки" у них, тьфу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #276

246. Сообщение от Урри (?), 09-Дек-19, 01:24	+2 +/–
Вы прочитали монолог типичного диванного враля. Начиная с того, что у него "есть amd64 и арм64" (арм-32 у него уже в прошлое ушел, хотя выпускается и продается на ура; да и какой, кстати, арм то? их довольно много и они сильно несовместимы в зависимости от производителя)% продолжая тем, что не знает об апи разных осей и заканчивая тем, что он знает также и об отладке. Ordu, признайтесь - вы ничего сложнее хелловорлда не писали. Это отлично видно по вашим комментариям. Начиная с того, что в досе был большой и стабильный список интов (типа сисколов), для которых достаточно было помнить номера (типа то, что вы в линуксе хвалите) и в какие регистры что пихать. Дополнительный софт приносил свои дополнительные номера. Были справочники, у меня был даже очень большой бумажный, где были расписаны возможные конфликты. Еще где-то на антресолях лежит. В винде сразу был отличный стабильный WinAPI, еще с 16-битной тянулся и до сих пор остается. Который тысячу лет не менялся, просто обрастая новыми функциями. То же самое, что и в линуксе. > Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно. Бездарь!!! Ты НЕ программируешь, ты просто звездишь на форуме. Все есть, и дебажная инфа (волшебные буквы -g2) и профайлинг (волшебные слова gprof, valgrind, callgrind). Я прямо сейчас дебажу с помощью F5/F6/F7 через vscode+gdb нейтивные бинари на ведроиде и винде (один код, две разные архитектуры) с полным комфортом - с колстеком, вочем, мгновенным состоянием переменных и брекпоинтами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #263

247. Сообщение от Урри (?), 09-Дек-19, 01:30	+/–
Там другая джава, ее даже джавой называть, наверное, нельзя. Хотя теперь уже и не она тоже. Напомню, что гугель (точнее ребята, которых он купил), написали свою джаву с блекджеком и мигалками; регистровую(а не стековую!!), просто бинарно совместимую с оракловой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

248. Сообщение от erthink (ok), 09-Дек-19, 01:31	+/–
> У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/ > Ещё в природе существует https://github.com/nemasu/asmttpd Не хочу обижать автора, но rwasa - это примерно смесь бутафории и паранойи в духе "назло бабушка на ассемблере пишу". В частности, все более-менее сложные функции вовсе не "handmage assembly", а допиленный результат компиляции соответствующих реализации на C (например: https://github.com/floodyberry/curve25519-donna => https://2ton.com.au/library_as_html/curve25519.inc.html).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

249. Сообщение от Урри (?), 09-Дек-19, 01:35	+3 +/–
Пошто заминусили человека, макаки? Представьте себе, был такой язык. И одно время даже достаточно распространенный. Именно С-- (минус минус).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232 Ответы: #266

250. Сообщение от Урри (?), 09-Дек-19, 01:36	+/–
Зачем, зачем... Десятое правило Гринспена жы!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

251. Сообщение от Урри (?), 09-Дек-19, 01:37	+3 +/–
Совсем не удивительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

252. Сообщение от Урри (?), 09-Дек-19, 01:48	+4 +/–
Я делал часть работы по оптимизации libjpeg-turbo. Могу объяснить в чем вы правы и в чем не правы. Если вы взглянете внимательнее на асм код, то заметите что 99% его - это векторные инструкции. Причем зачастую сам алгоритм приходилось переделывать, чтобы он хорошо векторизовался; простых циклов без внутренних зависимостей в коде очень мало. А это работа уже не компилятора, но ИИ; который в компиляторы пока еще не завезли. Вот и приходилось оплачивать работу человеков. Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п. Последний процессор, для которого человек еще хорошо справлялся, был pentium2, с его U и V каналами, которые могли работать одновременно (но не для умножения - умножение работало параллельно c с другой арифметикой только если уходило в U канал). Да и то, есличестно, занятие это было дико муторным и в основном не оправдывало вложенных усилий. Сейчас оптимизация в основном выглядит так: запускаем профайлер, ищем очень редкие узкие места и задрачиваем их в полуслепом режиме. И так для каждой(!) архитектуры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #253, #262, #285

253. Сообщение от Урри (?), 09-Дек-19, 01:49	+/–
Ох, промахнулся немного комментом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

254. Сообщение от Урри (?), 09-Дек-19, 01:51	+1 +/–
Поиск на карте (с частым построением графов), кстати, одна из тех задач, где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы в виде реализации сборки мусора не в счет, естественно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #419

255. Сообщение от Урри (?), 09-Дек-19, 01:52	+1 +/–
Таблицы, коих на самом деле уже давно нет. Так как конвеер длинный и микрооперации сильно зависят друг от друга и окружающей среды (например, предсказания переходов или кеширования памяти).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234

256. Сообщение от Урри (?), 09-Дек-19, 01:54	+1 +/–
Ты уверен что это был первый дубль и без подготовки? И без бумажки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

257. Сообщение от Урри (?), 09-Дек-19, 01:58	+1 +/–
Не занудствуй. И вообще - javac это транслятор, компилятор и/или линковщик? Особенно учитывая, что выходной байткод будет интерпретировать, транслироваться и/или компилироваться в зависимости от фазы луны и настроения jit?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

258. Сообщение от Урри (?), 09-Дек-19, 02:04	+2 +/–
Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/Text
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #292

259. Сообщение от Ordu (ok), 09-Дек-19, 02:10	+/–
> Для мыши есть int 33. И в учебниках это было описано еще > тогда, когда вас у родителей и в планах не было. Возможно в каких-то и было описано. Я не видел ни в одном, выяснял как работать с мышью дизассемблированием. Когда вас в планах родителей не было, у меня не было не то что интернета, даже и FIDO никакого не было, и поэтому знания приходилось выгрызать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #268

260. Сообщение от Аноним (260), 09-Дек-19, 02:10	+/–
Жалуешься что тебя затроллили ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

261. Сообщение от Аноним (261), 09-Дек-19, 02:12	+1 +/–
Ты же не пишешь на языке программирования, а печатаешь? Хотя возможно с таким синдромом граммар-наци у тебя и есть парочка скриптов, накарябанных на бересте...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237

262. Сообщение от Аноним (260), 09-Дек-19, 02:25	+/–
"Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п." Вот как раз всего этого компилятор "удержать в памяти" и не может, потому что этой информации у него просто нет и взять ее неоткуда. Именно этот прискорбный факт и стал основной причиной безвременной кончины интеловского итаниума.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252 Ответы: #271, #272

263. Сообщение от Ordu (ok), 09-Дек-19, 02:28	–1 +/–
> Вы прочитали монолог типичного диванного враля. > Начиная с того, что у него "есть amd64 и арм64" (арм-32 у > него уже в прошлое ушел, хотя выпускается и продается на ура; А мне какое дело до того, что он продаётся? У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался? > да и какой, кстати, арм то? их довольно много и они > сильно несовместимы в зависимости от производителя)% продолжая тем, что не знает > об апи разных осей и заканчивая тем, что он знает также > и об отладке. Какое мне дело до апи разных осей? Речь идёт о линуксе, все эти железные детали он вполне инкапсулирует, но ежели вам так важно знать, что за железка, то это raspberri pi. > Ordu, признайтесь - вы ничего сложнее хелловорлда не писали. Это отлично видно > по вашим комментариям. Ещё один диагност по юзерпикам. Вот что меня всегда забавляет в программистах, почему-то каждый программист уверен в том, что он умнее всех остальных, и что никто кроме него компилятора никогда в руках не держал. Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить. > Начиная с того, что в досе был большой и стабильный список интов > (типа сисколов), для которых достаточно было помнить номера (типа то, что > вы в линуксе хвалите) и в какие регистры что пихать. Гнусь. Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами, типа как восстановить перехваченный вектор прерывания, чтобы не поломать те программы, которые успели тоже его перехватить, пока я с ним игрался. Но вывод на экран совершенно определённо был там лишним. Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника. > Дополнительный > софт приносил свои дополнительные номера. Были справочники, у меня был даже > очень большой бумажный, где были расписаны возможные конфликты. Еще где-то на > антресолях лежит. Да-да. > В винде сразу был отличный стабильный WinAPI, еще с 16-битной тянулся и > до сих пор остается. Который тысячу лет не менялся, просто обрастая > новыми функциями. То же самое, что и в линуксе. Стабильный -- это да, но вот насчёт отличного я бы поспорил. >> Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно. > Бездарь!!! Ты НЕ программируешь, ты просто звездишь на форуме. Я приму твоё мнение к сведению. Оно очень важно для меня. > Все есть, и дебажная инфа (волшебные буквы -g2) и профайлинг (волшебные слова > gprof, valgrind, callgrind). Ты вообще читаешь, что я пишу или нет? Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку. Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало? > Я прямо сейчас дебажу с помощью F5/F6/F7 через vscode+gdb нейтивные бинари на > ведроиде и винде (один код, две разные архитектуры) с полным комфортом > - с колстеком, вочем, мгновенным состоянием переменных и брекпоинтами. vscode слишком сложно для меня, я его только на скриншотах разглядывал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #269, #356

264. Сообщение от Chaky (?), 09-Дек-19, 02:52	+/–
Java на сегодня единственный язык для живучих больших проектов, для которых живучесть и надежность важнее скорости разработки и скорости приложения. Её нишу возможно займёт кристалл, но пока это лишь мечты(....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

265. Сообщение от Аноним (265), 09-Дек-19, 02:57	+/–
https://www.top500.org/ Где?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

266. Сообщение от aaaaaaaaaaaaaaa (?), 09-Дек-19, 03:12	+1 +/–
он не просто был https://www.cs.tufts.edu/~nr/c--/ он и сейчас есть, например в КолбриОСь используется и развивается http://kolibri-n.org/inf/hll/hll#cmm
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #270

267. Сообщение от Аноним (267), 09-Дек-19, 03:16	+2 +/–
А может проблема не в языках и компиляторах, а в том, что x86 просто неадекватна для реализации высокоуровневых ЯП?  В 70-х Xerox Alto с тактовой частотой 5,88 МГц и 128-256 Кбайт памяти поддерживал весьма продвинутую мультимедийную ОС с оконным интерфейсом и интерактивной средой разработки, которая была написана на объектно-ориентированном языке с поздним связыванием и динамической типизацией (Smalltalk, кто не слишком представляет, что это за язык, представьте себе ОС полностью на Ruby).  Здесь можно почитать, как это все разрабатывалось (и про аппаратную архитектуру): http://worrydream.com/EarlyHistoryOfSmalltalk/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #293, #324, #345

268. Сообщение от Урри (?), 09-Дек-19, 03:48	+/–
У меня тоже ни интернета, ни фидо не было. Но мне, видимо, повезло - я жил не в ебенях и походы по вычислительным лабораториям местных институтов зачастую приносили хорошие плоды в виде файлов документации (а иногда и распечаток).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259

269. Сообщение от Урри (?), 09-Дек-19, 04:11	+2 +/–
Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при этом неся чушь - я бы спокойно прошел мимо. А так вы каждым предложением подчеркиваете что диванный эксперт без опыта, но зато гонору как у гейтса. поотвечаю как и вы, по пунктам: > У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался? ... Какое мне дело до апи разных осей? Мб такое, что если вы не в курсе - то нечего и лезть со своим мнением туда, где в курсе? Я вот пишу для всего этого; причем одновременно и для того, чего еще не выпустили - куча ифдефов, интринсики% совсем изредка ассемблерные вставки. И я знаю о чем говорю. > Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить. Я рад что вас эти 9 забавляют. Им это и рассказывайте. А я тут при чем? >> Начиная с того, что в досе был большой и стабильный список интов... > Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами... Во-первых, процессов и их взаимодействия в ДОСе не было. PSP - это Program Segment Prefix, а не Process. Никакой мультизадачности, никаких мьютексов с семафорами; никакой реентерантности - все ручками через локи и велосипеды. И да, я в курсе резидентных программ - разошедшаяся тулза по убиванию программ по Ctrl+Alt+Del - моя работа. Помните такую? > Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника. И вы, конечно же, реализовали свои функции для CGA, Hercules, VGA и всех их режимов? И это все отлично умещалось в сотню байтов - у нас же дискетки еще большие но маленькие, места обмаль. >> Были справочники... > Да-да. Забавно, что вы не верите в существование такого справочника. > Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку. Во-первых, не можешь. Любую математику из любого кодека в ассемблерном виде вам будет не по силам отладить ни за год, ни за пять - алгоритмы сложнее хелловорлда из асма не восстанавливаются. Любые ошибки по двойному освобождению памяти - тоже. И т.д. и т.п. Хотя в вашей малинке, где программы по 100 байт размером и ничего такого нет - может быть, может быть... > Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало? А, так вы хакир. Так бы сразу и сказали.. Ну да, аналога ollydbg (x32dbg) в лине действительно нету. Но он там и не нужен, ибо есть исходники и никто не запрещает самому собрать с отладочной информацией. А дальше gdb с фронтэндами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #277, #286, #308

270. Сообщение от Урри (?), 09-Дек-19, 04:14	+/–
Хех, я был уверен что давным-давно умер. Спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266

271. Сообщение от Урри (?), 09-Дек-19, 04:19	+/–
Ну здрасьте, приехали. Как это нет - у компилятора есть множество того, что мы не сможем сделать; например, возможность построить граф зависимостей по коду и данным; по использованию регистров и самому "попереименовывая" их разбросать в наилучшем порядке. У gcc специально для вас в асм вставках предлагается использовать не регистры, а условные обозначения с указанием что именно ваша функция (которую гцц не понимает и понимать не должен) использует, что хочет на вход и на выход; после чего гцц с учетом этой инфорации подберет конфигурацию получше, размещая промежуточные данные в одних или других регистрах. Да много чего есть, чего вам, как человеку, уже недоступно ввиду слишком низкой скорости обработки данных и ограниченности по объему их же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #303

272. Сообщение от Урри (?), 09-Дек-19, 04:22	+/–
Да, кстати. Итаниум умер не поэтому. Умер он потому, что его время новых инструкций без сохранения обратной совместимости еще не пришло. Через десять лет время пришло, но повезло в этот раз арму. Итаниум - это же современный арм, разве что с увеличенной адресной шиной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #301, #302, #304

273. Сообщение от Аноним (273), 09-Дек-19, 04:56	+/–
Поиск имени в каталоге давным давно идёт по индексу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

274. Сообщение от Аноним (273), 09-Дек-19, 04:58	+1 +/–
> по словам его создателя, можно одну и ту же задачу выполнить несколькими способами Так в любом языке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

275. Сообщение от Аноним (166), 09-Дек-19, 06:15	+5 +/–
Удачи тебе понять, надо ли ему это. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #281

276. Сообщение от Аноним (166), 09-Дек-19, 06:25	–2 +/–
> В то время на ассемблере больше и писали. Ассемблер был везде. И > никаких "заморочек" с сегментами не было. Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086. > Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки. Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных. > А селекторы в 32 и 64 - не заморочки? Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются. > бла-бла-бла Ну, расскажи нам, зачем нужен префикс lock.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #296, #373

277. Сообщение от Аноним (166), 09-Дек-19, 06:52	+/–
> - алгоритмы сложнее хелловорлда из асма не восстанавливаются. Ложное обобщение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269 Ответы: #298

278. Сообщение от Аноним (166), 09-Дек-19, 06:55	+/–
По-моему, роль России в закапывании Паскаля несколько преувеличена. Точнее, у нас наоборот он и производные получили большее распространение, чем на родине Кернигана и Риччи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #295

279. Сообщение от Аноним (279), 09-Дек-19, 06:59	+1 +/–
Спасибо господину Джеффу Мэррисону, теперь я знаю на чём надо писать программу, которая выводит строку "hello".
Ответить | Правка | Наверх | Cообщить модератору

280. Сообщение от Аноним (280), 09-Дек-19, 07:14	+2 +/–
Специалисты опеннета считают миллисекунды. Их жизнь полна и насыщена. Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207 Ответы: #366, #377

281. Сообщение от Аноним (280), 09-Дек-19, 07:24	+2 +/–
Рряяя! Это вы не понимаете! Люди должны даже пукать с оглядкой на risc-v! Как так, оно кому-то не нужно?! Ррряяя! Ну а если серьезно, то за почти 10 лет своего существования риск-пять стала своего рода вейландом среди архитектур. Мы только и слышим, что "вот-вот победим!", а по факту оно так и болтается на уровне микроконтроллеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275 Ответы: #288

282. Сообщение от Аноним (166), 09-Дек-19, 07:48	+/–
>[оверквотинг удален] >  /*WriteFile( >   GetStdHandle(STD_OUTPUT_HANDLE), // handle to file to write to >   s, // pointer to data to write to file >   sSize, // number of bytes to write >   &outCnt, // pointer to number of bytes written >   NULL  // pointer to structure needed for overlapped I/O >    );*/ > } > И, внезапно, окажется что это то же самое что и асм, только > приятней и проще. Оказывается, ты не понимаешь, что этот "аналог" использует kernel32.dll и ntdll,dll, а вариант для Linux вызывает непосредственно ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #328

283. Сообщение от Аноним (166), 09-Дек-19, 08:06	+/–
> Промерял Ocaml - 59 syscalls. Программа: > let _ = print_string "hello\n" > Компиляция > ocamlopt.opt -O3 -inline 1000 hello_ml.ml -o hello_ml Тоже померял: ocamlc hello.ml -o hello_ocamlbytecode strace -fc ./microcaml hello_ocamlbytecode hello % time     seconds  usecs/call     calls    errors syscall ------ ----------- ----------- --------- --------- ----------------   0,00    0,000000           0         1           write   0,00    0,000000           0         1           open   0,00    0,000000           0         1           close   0,00    0,000000           0         1           fstat   0,00    0,000000           0         1           mmap   0,00    0,000000           0         1           rt_sigaction   0,00    0,000000           0         1           execve   0,00    0,000000           0         1           sigaltstack ------ ----------- ----------- --------- --------- ---------------- 100.00    0,000000                     8           total Но сразу оговорюсь: в более сложных случаях проигрывает штатному интерпретатору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220

284. Сообщение от Аноним (284), 09-Дек-19, 09:16	–1 +/–
Что сразу бросилось в глаза, у него второй питон а не третий, также не указаны версии интерпретаторов и компиляторов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #309

285. Сообщение от VEG (ok), 09-Дек-19, 09:49	–1 +/–
Так я как бы о том же о чём и вы говорил в предыдущем комментарии. Хочешь по максимуму задействовать возможности SSE/AVX - переписывай код ручками. На асме или интринсиками в C - уже дело вкуса. А полагаться на то что компилер сам догадается - не приходится. Хотя иногда он таки догадывается как какие-то простые циклы можно векторизовать, но это не точно =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

286. Сообщение от Anonymoustus (ok), 09-Дек-19, 09:54	+/–
>>> Были справочники... >> Да-да. > Забавно, что вы не верите в существование такого справочника. Речь о справочнике по Win32 API? Да, был и есть. На сайте Майкрософта можно читать совершенно бесплатно: https://docs.microsoft.com/en-us/windows/win32/api/ В открытом доступе есть также сконвертированные в CHM версии, о полноте и корректности оных не могу судить: http://laurencejackson.com/win32/ http://sourceforge.net/projects/win32-help-chm/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269 Ответы: #297

287. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:02	+/–
> "Once upon a time my boss asked me to study if we > should use C++ or Erlang for a specialist XML parser to > be used in a product (for reasons of speed not energy). > My recommendations was an FPGA > We built an FPGA. > Relative speed of C++/Erlang was irrelevant compared to FPGA." > https://twitter.com/joeerl/status/1115990630793207808 Ничего, придёт ему на смену задорная молодёжь и перепишет всё это окаменевшее на жлобоскрипте (пихтона они уже знать не будут).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

288. Сообщение от Аноним (31), 09-Дек-19, 10:12	+/–
Да, нужно поддерживать монополию x86_64 такими проектами и славить Intel ME и AMD PSP. А все остальные архитектуры, включая i586 и i686, не нужны, нужно сидеть на опеннете и раздавать советы выкинуть компы и телефоны на помойку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281 Ответы: #367

289. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:29	+/–
> Еще один хипстор опубликовал видосик. И как я его в Links посмотрю? Да, видосики без ссылок для скачивания — это серпом по опенсорсам. Но выковырять можно: https://2ton.com.au/videos/tvs_part1/tvs_part1.mp4 (350 МБ) https://2ton.com.au/videos/tvs_part1/tvs_part1.webm (155 МБ)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #321

290. Сообщение от A10 (?), 09-Дек-19, 10:31	+/–
Мне кажется необъективным тест для python2 - забыли выполнить команду $ python2 -m compileall ./hello.py
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

291. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:39	+/–
На будущее, анон, пиши код в тегах: [CODE] твой говнокод [/CODE] На опеннете негодный парсер, так что запоминай, ибо повторять напряжно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

292. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:42	+/–
> Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования > - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/Text Ты открыл для себя Розеттский Камень, надо же! :) Там не только хелловорлды, но много всякой разной твари, в том числе игрушки. ЗЫ Тем не менее, плюсую за комментарий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258

293. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:46	+/–
> А может проблема не в языках и компиляторах, а в том, что > x86 просто неадекватна для реализации высокоуровневых ЯП?  В 70-х Xerox > Alto с тактовой частотой 5,88 МГц и 128-256 Кбайт памяти поддерживал > весьма продвинутую мультимедийную ОС с оконным интерфейсом и интерактивной средой разработки, > которая была написана на объектно-ориентированном языке с поздним связыванием и динамической > типизацией (Smalltalk, кто не слишком представляет, что это за язык, представьте > себе ОС полностью на Ruby).  Здесь можно почитать, как это > все разрабатывалось (и про аппаратную архитектуру): http://worrydream.com/EarlyHistoryOfSmalltalk/ По большому счёту, x86 — это только «внешняя» система команд. А как оно внутри там устроено, никто из присутствующих, скорее всего, не знает. Скорее всего, внутри современных x86-процессоров от x86 и следа не осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #300

294. Сообщение от Аноним (-), 09-Дек-19, 10:54	+/–
Эта утилитка представлена как образец выводящий хэлоуворлд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #312

295. Сообщение от Anonymoustus (ok), 09-Дек-19, 10:58	+1 +/–
> По-моему, роль России в закапывании Паскаля несколько преувеличена. Точнее, у нас наоборот > он и производные получили большее распространение, чем на родине Кернигана и > Риччи. На, вот, сам почитай, был уже здесь такой спор: https://www.opennet.ru/openforum/vsluhforumID3/118392.html Некоторые индивиды именно _ненавидят_ Паскаль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #278 Ответы: #362, #409

296. Сообщение от Урри (?), 09-Дек-19, 11:07	+2 +/–
Ахахахах, обезьянка обиделась и с головой бросилась повторно позориться. > Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных. Сразу видно вебмакаку, ни разу не использовавшую 16-битную архитектуру. Цпу сам, представь себе, автоматически делает операцию умножения и сложения между значением сегмента и смещения при доступе к данным. Ты совершенно свободно можешь использовать весь мегабайт под свои деревья (ну, кроме биоса, адресов замапленых на порты в/в устройств, текущей экранной части видеопамяти, таблицы прерываний и ОС - крч 640КБ плюс хвостик) - главное, не забыть одну простую вещь..., тадаааааам..., внимание, сейчас вылетит птичка..., вот: использовать два слова под указатели, а не один! одно под сегмент, одно под смещение. > Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются. А-ха-ха-ха-ха-ха-ха-ха!!!! Ну вы бы, детки, хоть в интернет заглядывали прежде чем позориться прилюдно на таких элементарнейших вещах. Вся вышеописанная математика 32 и 64 архитектуры используется всегда! Включая так называемый "реальный" режим работы 32 бит, когда при переключении из защищенного, надо было сначала подготовить и загрузить в селекторы правильно приготовленные вышеперечисленные чиселки (они при этом дублировались в теневые "типа кеш" регистры и только потом прыгать в реальный. Вот так вот - трансляция линейного адреса в физический - очень непростая задача. > Ну, расскажи нам, зачем нужен префикс lock. Достижение атомарности операций. Учись, студент, пока я жив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276 Ответы: #347

297. Сообщение от Урри (?), 09-Дек-19, 11:08	+1 +/–
При чем здесь винапи? Я писал про справочник интов - биоса, доса и дополнительного софта; всяких там БД, мышки, и кучи остального.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #326

298. Сообщение от Урри (?), 09-Дек-19, 11:10	+/–
Попытка съехать на буквоедстве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #349

300. Сообщение от Урри (?), 09-Дек-19, 11:16	–1 +/–
То, что вы в своем детском саду не знаете, еще не значит что никто не знает. Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация", "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси". Другое дело, что весь этот конвеер настолько сложен, что все сложнее хелловорлда в голове уже не уместится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #293 Ответы: #305

301. Сообщение от Аноним (260), 09-Дек-19, 11:20	+/–
Именно поэтому, как и многие другие VLIW процессоры. Не получился всемогущий компилятор, который сможет строить бандлы инструкций, достаточно длинные чтобы получить нормальную производительность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272

302. Сообщение от Anonymoustus (ok), 09-Дек-19, 11:27	+/–
> Да, кстати. Итаниум умер не поэтому. > Умер он потому, что его время новых инструкций без сохранения обратной совместимости > еще не пришло. > Через десять лет время пришло, но повезло в этот раз арму. Итаниум > - это же современный арм, разве что с увеличенной адресной шиной. История не знает сослагательного наклонения, но мне думается, что если бы Итаниум был дешевле, меньше грелся и меньше жрал электричества, то его судьба была бы иной. А ещё жаль, что ХаПэ отправила в музей Альфу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #306

303. Сообщение от Аноним (260), 09-Дек-19, 11:32	+/–
И поэтому сплошь и рядом компиляторы устраивают в коде какой-то бл..cкий цирк с жонглированием регистрами, выкинув при этом действительно важные переменный на стек. И кстати куда же делось вот это все: "микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги" ? Дошло что написали глупость ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271

304. Сообщение от Аноним (260), 09-Дек-19, 11:34	+/–
> Итаниум - это же современный арм, разве что с увеличенной адресной шиной. Блин, слона-то я и не приметил. Больше вопросов не имею.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #401

305. Сообщение от Anonymoustus (ok), 09-Дек-19, 11:35	+/–
> То, что вы в своем детском саду не знаете, еще не значит > что никто не знает. > Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация", > "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси". А ты, я гляжу, прямо знаток по всем вопросам. И слова какие умные знаешь, молодец. Ну так расскажи всем: есть внутри интеловских процессоров x86 или нету?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300 Ответы: #320

306. Сообщение от Аноним (260), 09-Дек-19, 11:36	+/–
Бабушка-с-членом-и-усами.jpg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302

307. Сообщение от InuYasha (?), 09-Дек-19, 11:48	+/–
Убийство - преступление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #396

308. Сообщение от Ordu (ok), 09-Дек-19, 12:15	–2 +/–
> Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при > этом неся чушь - я бы спокойно прошел мимо. А так > вы каждым предложением подчеркиваете что диванный эксперт без опыта, но зато > гонору как у гейтса. А, вы из этих, кому обязательно повоспитывать окружающих? Вы из тех, кто на дороге догоняет, обгоняет и ставит машину поперёк дороги тем, кто его подрезал, дабы потом рассказать им, как им следует и не следует водить автомобиль? SJW русского разлива? Вы видяшки снимаете, как вы это делаете? SJW в США когда тормозят родителей, чтобы поорать на них за то, что те ребёнка в машине на парковке оставили, когда отвозили корзину к супермаркету, снимают это на видео и потом выкладывают в интернет летопись о своих подвигах. > поотвечаю как и вы, по пунктам: >> У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался? ... Какое мне дело до апи разных осей? > Мб такое, что если вы не в курсе - то нечего и > лезть со своим мнением туда, где в курсе? Я вот пишу > для всего этого; причем одновременно и для того, чего еще не > выпустили - куча ифдефов, интринсики% совсем изредка ассемблерные вставки. И я > знаю о чем говорю. Какое мне дело до того, что вы там пишете? У меня складывается ощущение, что вам не удалось прочитать кусок беседу, предшествующий вашему вмешательству в неё. >> Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить. > Я рад что вас эти 9 забавляют. Им это и рассказывайте. А > я тут при чем? Меня забавляют не только 9, но и десятый тоже. Он отличается от этих девяти в лучшую сторону только тем, что умеет кодить, но это принципиально ничего не меняет. >>> Начиная с того, что в досе был большой и стабильный список интов... >> Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами... > Во-первых, процессов и их взаимодействия в ДОСе не было. PSP - это > Program Segment Prefix, а не Process. Никакой мультизадачности, никаких мьютексов с > семафорами; никакой реентерантности - все ручками через локи и велосипеды. Ну да, да. Но я не помню всех этих терминологий и более того, не стремлюсь помнить, всё это давно быльём поросло и нафиг никому не нужно. Вы же поняли о чём речь? > да, я в курсе резидентных программ - разошедшаяся тулза по убиванию > программ по Ctrl+Alt+Del - моя работа. Помните такую? Нет, простите. К тому моменту когда у меня появились интернеты, у меня стоял линукс, и дос я использовал к тому моменту исключитально в эмуляторе либо для запуска игрушек, либо для ностальгии. >> Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника. > И вы, конечно же, реализовали свои функции для CGA, Hercules, VGA и > всех их режимов? И это все отлично умещалось в сотню байтов > - у нас же дискетки еще большие но маленькие, места обмаль. Это вы приводите для того, чтобы подтвердить мою позицию о том, что программирование для DOS -- это отстой, даже если писать на асме? >>> Были справочники... >> Да-да. > Забавно, что вы не верите в существование такого справочника. Почему не верю? Верю, но толку-то мне с них теперь? Вон даже у вас эти справочники пыляться на антресолях невостребованными. У меня тоже парочка пылится, я их купил было, когда денег начал зарабатывать, полистал, и... где-то они должны лежать, не нужные никому в силу ненужности доса. >> Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку. > Во-первых, не можешь. Любую математику из любого кодека в ассемблерном виде вам > будет не по силам отладить ни за год, ни за пять > - алгоритмы сложнее хелловорлда из асма не восстанавливаются. Если эту математику найти в исходных текстах, то понять их не проще, чем в асме. И даже комментарии не помогают, ежели конечно они не в стиле literate programming, когда их можно скомпилять в статью-описание математики. Бывает что описание алгоритма на внятном русском языке не даёт понимания того, как алгоритм работает, и приходится несколько часов ломать голову. > Любые ошибки по > двойному освобождению памяти - тоже. И т.д. и т.п. > Хотя в вашей малинке, где программы по 100 байт размером и ничего > такого нет - может быть, может быть... У меня складывается ощущение, что вы никогда не пытались отлаживать программу без дебаг-инфы. Я не спорю, это сложнее, но если исключить антиотладку как фактор (её нет или она успешно снята), то дальше нужна лишь небольшая поддержка со стороны софта, чтобы давать осмысленные для меня имена адресам, и тогда единственным принципиальным усложнением по сравнению с исходными текстами, остаются данные -- статическая память и структуры нигде не описаны. И если со статической памятью ещё худо-бедно можно разобраться, найдя все обращения к интересующему адресу, то со структурами такое не прокатывает. Ну и да, это дос, детка. Там биос влезал в 1Mbit, вместе со всеми его прерываниями, настройками железа, ldt/gdt и прочими штучками. DOS целиком влезал на дискету, и ещё места оставалось. Чё там отлаживать? >> Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало? > А, так вы хакир. Как скажете. > Ну да, аналога ollydbg (x32dbg) в лине действительно нету. Но он там > и не нужен, ибо есть исходники и никто не запрещает самому > собрать с отладочной информацией. А дальше gdb с фронтэндами. Вот поэтому я и говорю, что у линя, как у платформы для написания на асме, есть недостатки. Не фатальные недостатки, но недостатки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269

309. Сообщение от анонн (ok), 09-Дек-19, 12:16	+1 +/–
> Что сразу бросилось в глаза, у него второй питон а не третий, > также не указаны версии интерпретаторов и компиляторов. truss -fc python3.6 -c "print('hello')" hello syscall                     seconds   calls  errors getgid                  0.000009173       1       0 getegid                 0.000009092       1       0 getuid                  0.000009299       1       0 geteuid                 0.000009966       1       0 ... dup                     0.000031753       3       0 close                   0.000591410      46       0 _umtx_op                0.000010842       1       0                       ------------- ------- -------                         0.011674676     740      40 truss -fc python3.5 -c "print('hello')" hello syscall                     seconds   calls  errors getgid                  0.000008866       1       0 getegid                 0.000008899       1       0 getuid                  0.000009029       1       0 ... fcntl                   0.000010414       1       0 dup                     0.000035829       3       0 close                   0.000635601      48       0 _umtx_op                0.000011185       1       0                       ------------- ------- -------                         0.018257540     781      40 truss -fc python2.7 -c "print('hello')" hello syscall                     seconds   calls  errors getgid                  0.000008682       1       0 ... close                   0.000917541      67       0 _umtx_op                0.000011242       1       0                       ------------- ------- -------                         0.022091739     912     206 truss -fc micropython -c "print('hello')"  #1.5.1 hello syscall                     seconds   calls  errors __sysctl                0.000025145       2       0 issetugid               0.000026012       2       0 write                   0.000062763       2       0 sysarch                 0.000010063       1       0 ... getdirentries           0.000028398       2       0 fstatfs                 0.000012848       1       0 fstat                   0.000072624       6       0 close                   0.000085231       7       0                       ------------- ------- -------                         0.001466043     100       5
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #317, #318

310. Сообщение от InuYasha (?), 09-Дек-19, 12:20	+/–
Что же в делфи хорошего? Разве что, если с Жавой сравнивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #357

311. Сообщение от Аноним (313), 09-Дек-19, 13:03	+/–
...прям стесняюсь спросить а в fasm уже подвезли поддержку e2k? Из коробки он и ARM и MIPS тоже не поддерживает. Так что шутка мимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #342

312. Сообщение от анонн (ok), 09-Дек-19, 13:03	+/–
> Эта утилитка представлена как образец выводящий хэлоуворлд. Странная версия, однако. truss -fc /bin/echo hello hello syscall                     seconds   calls  errors cap_enter               0.000011729       1       0 cap_ioctls_limit        0.000029684       3       0 __sysctl                0.000024730       2       0 issetugid               0.000026926       2       0 writev                  0.000041989       1       0 sysarch                 0.000009844       1       0 sigprocmask             0.000154586      14       0 readlink                0.000021708       1       1 ... close                   0.000061911       5       0 cap_rights_limit        0.000036024       3       0 cap_fcntls_limit        0.000029448       3       0                       ------------- ------- -------                         0.001061477      74       1 почти в 2 раза меньше сисколов, несмотря на обертку в капсикум.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294

313. Сообщение от Аноним (313), 09-Дек-19, 13:06	+/–
Тот же nasm текст вида mov rax, 1 ... syscall оптимизирует до mov eax, 1 ... syscall на выходе. Так как считает что так эффективнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #339

314. Сообщение от Аноним (314), 09-Дек-19, 13:07	+/–
Да, rust язык очень полезный. Программистом, которые пишут код на С++, работающий медленнее написанного на расте дорога одна, переходить на раст. Им ничто уже не поможет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

315. Сообщение от Аноним (313), 09-Дек-19, 13:11	+3 +/–
Блин, а ларчик то так просто открывался. Вы сделали мой день.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203

316. Сообщение от Аноним (316), 09-Дек-19, 13:13	–2 +/–
Ууу! Раст затащил ууу!!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #319

317. Сообщение от Аноним (313), 09-Дек-19, 13:20	+/–
От нас скрывают правду микропитон быстрее Go и Rust. Вот это скандалы, интриги, расследования показать все что скрыто. А казалось бы заурядная новость про какие-то левые тесты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309 Ответы: #329

318. Сообщение от Аноним (313), 09-Дек-19, 13:23	+/–
Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост текст еще не разобранный. python -m compileall
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309 Ответы: #325, #330

319. Сообщение от Аноним (313), 09-Дек-19, 13:24	+1 +/–
На дно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #316

320. Сообщение от Аноним (313), 09-Дек-19, 13:28	+/–
Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305 Ответы: #322

321. Сообщение от Аноним (321), 09-Дек-19, 13:38	+/–
Спасибо, братиш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

322. Сообщение от Anonymoustus (ok), 09-Дек-19, 13:43	+/–
> Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents... У меня на диске вся пачка этих мануалов, а ещё несколько ревизий документации AMD. На какой странице какого тома написано про место, которое x86 занимает в современном процессоре? Ой, а что это у нас там чорненькое белеется в чулане? Это же «80386 Hardware Reference Manual» (1986)! Пока ты ищешь нужную страницу в современных мануалах, я в этой книжке посмотрю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #320

323. Сообщение от Аноним (95), 09-Дек-19, 13:47	+/–
Можно было хотя бы на си, обожаю смотреть на сишку с https://ioccc.org/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

324. Сообщение от Аноним (324), 09-Дек-19, 13:49	+/–
Может в этом то все и дело что создать что-то действительно разухабистое на языке с динамической типизацией достаточно трудно. А работало быстро потому что ничего сложно и не делали. Да и вообще этот Xerox Alto это попытка внедрить разработки Дугласа Энгельбарта в жизнь. https://www.youtube.com/watch?v=yJDv-zdhzMY и как все знают неудачная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #368

325. Сообщение от Аноним (95), 09-Дек-19, 13:59	+/–
Так цель была показать что скрипты это фу и все должны срочно начинать писать на ассемблере (ни в коем случае не на си).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318

326. Сообщение от Совершенно другой аноним (?), 09-Дек-19, 14:02	+/–
Был, да вроде и есть, правда в бумажном виде не видел, Ralf's Brown Interrupt List/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297

327. Сообщение от Аноним (327), 09-Дек-19, 14:16	+/–
>Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus. Это все следствие того, что поддержку векторных типов и операций над ними в стандарт С не завезли. >Но это, по сути, ассемблер с синтаксисом C. Нет, по сути это не ассемблер. Не нужно вручную распределять регистры,  есть проверка типов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #421

328. Сообщение от Аноним (327), 09-Дек-19, 14:32	+/–
Все правильно, использует API ос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282 Ответы: #338

329. Сообщение от анонн (ok), 09-Дек-19, 14:49	+/–
> От нас скрывают правду микропитон быстрее Go и Rust. А сказать аноним хотел что? Или в пальцах чесалось, аж мочи терпеть не было? Вопрос выше был о версиях питона, а прикол тут в том, что у 2.7 при старте задействует заметно больше колов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317

330. Сообщение от анонн (ok), 09-Дек-19, 14:53	+/–
> Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост > текст еще не разобранный. python -m compileall Запускай - так и быть, разрешаю! Правда, сисколов будет ровно столько же, но …
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318 Ответы: #333

331. Сообщение от anonymous (??), 09-Дек-19, 14:58	+1 +/–
6mb потому что это debug сборка, если собрать релиз с оптимизациями будет 980kb и количество syscall будет 78 а не 120...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

332. Сообщение от Аноним (332), 09-Дек-19, 17:26	+/–
Искра-1030(1031)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

333. Сообщение от Аноним (334), 09-Дек-19, 18:23	–1 +/–
Лол спасибо. Только ты очередной раз показал своё незнание. Сисколов будет не столько же. Ты бы вот чисто для разнообразие сам бы проверил, но нет это же надо голову включить средний анонн на такое не способен. Итак python 3.6.9 strace -fc python3 -c "print('hello')" % time     seconds  usecs/call     calls    errors syscall ------ ----------- ----------- --------- --------- ---------------- 15.91    0.000867           5       175        39 stat ...   0.00    0.000000           0         1           getegid ------ ----------- ----------- --------- --------- ---------------- 100.00    0.005449                   730        62 total strace -fc python3 ./hello.py % time     seconds  usecs/call     calls    errors syscall ------ ----------- ----------- --------- --------- ---------------- 23.89    0.000436          11        38           mmap ...   0.00    0.000000           0         1           getegid ------ ----------- ----------- --------- --------- ---------------- 100.00    0.001825                   753        65 total strace -fc python3 ./__pycache__/hello.cpython-3.6.pyc % time     seconds  usecs/call     calls    errors syscall ------ ----------- ----------- --------- --------- ---------------- 19.24    0.000484          13        38           mmap ...   0.00    0.000000           0         1           getrandom ------ ----------- ----------- --------- --------- ---------------- 100.00    0.002515                   758        64 total Разница в 5 сисколов между pyc и py. А между вызовом команды из стоки и из файла целых 23 сискола разница. Но ты продолжай жить в своём мирке с пони где количество сисколов постоянно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #348

334. Сообщение от Аноним (334), 09-Дек-19, 18:25	+/–
Это против правил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

335. Сообщение от Аноним (335), 09-Дек-19, 19:16	+/–
> С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт? Так пишешь, будто sqlite не на той же файловой системе валяется. > Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY? Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #352

336. Сообщение от Аноним (335), 09-Дек-19, 19:19	+/–
> Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv Проблема точно не в libsolv, ибо zypper летает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223

337. Сообщение от alienjust (ok), 09-Дек-19, 19:23	+/–
del
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #343

338. Сообщение от Аноним (166), 09-Дек-19, 19:24	+/–
Не угадал. Вызывает kernel32.dll, то есть API подсистемы Win32. API операционной системы Windows NT является Native API. Впрочем, это не имеет отношения к тому, что подобное сравнение некорректно. В Windows NT так же возможно вызывать ядро, но номера системных вызовов различаются от версии к версии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328 Ответы: #358

339. Сообщение от Аноним (166), 09-Дек-19, 19:28	–1 +/–
В eax номер вызова. Параметры передаются в других регистрах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #313

340. Сообщение от Аноним (335), 09-Дек-19, 19:31	+/–
Зачем ему про LTO? Пусть сначала хоть это осилит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #351

341. Сообщение от Аноним (-), 09-Дек-19, 19:34	+/–
Раст использует c runtime library под капотом, но в пару строк конфигруации можно статически прикомпилить себе стандатрную библиотеку rust, естественно со всеми оптимизациями. https://github.com/japaric/xargo Тем не менее меньше чем у Си не будет в инструкциях из-за cruntime. Есть также реимплементация, но только для redox и линукс. https://github.com/redox-os/relibc
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

342. Сообщение от Аноним (166), 09-Дек-19, 19:35	+/–
> ...прям стесняюсь спросить а в fasm уже подвезли поддержку e2k? Из коробки > он и ARM и MIPS тоже не поддерживает. The FASMARM package is a free ARM cross-assembler add-on for FASM Runs under Win32 (9x/NT/2K/XP/Vista/7/8/8.1/10) and LINUX. Plus a linkable object file for UNIX/LibC FASMARM currently supports the full range of instructions for all 64-bit and 32-bit ARM processors and coprocessors up to v8. https://arm.flatassembler.net/ Ну и откройте уже для себя fasm g, который из коробки вообще ни одну архитектура не поддерживает, всё реализуется макросами. THIRD-PARTY RESOURCES i8080/85 support by shoorick. MCS-48 macros by shoorick. MOS 6502 assembler by codestar. PIC 14-bit by edfed. eZ80 includes by jacobly (GitHub). EFI x64 sample by Akeo (GitHub). EBC assembler for UEFI by Akeo (GitHub). Intel MCS-8 I8008 instructions by halak. STM8 MCU instruction set by shoorick. aarch64 instructions and formats by tthsqe (GitHub). PRELIMINARY PROJECTS WebAssembly Advanced x86 encoder https://board.flatassembler.net/topic.php?t=19389 > Так что шутка > мимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311 Ответы: #364

343. Сообщение от alienjust (ok), 09-Дек-19, 19:37	+/–
> del C#: syscalls:   117 taskclock
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #337

344. Сообщение от Аноним (-), 09-Дек-19, 19:38	+/–
Чтот не вижу его https://www.techempower.com/benchmarks/#section=data-r18
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

345. Сообщение от Аноним (335), 09-Дек-19, 19:39	+/–
Мультимедийность-то ты там где нашёл?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267

346. Сообщение от alienjust (ok), 09-Дек-19, 19:54	+/–
C#: syscalls:   117 .net core 3.1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #350

347. Сообщение от Аноним (166), 09-Дек-19, 19:57	+/–
> Ахахахах, обезьянка обиделась и с головой бросилась повторно позориться. Да, бомбануло её знатно. Под ДОС на асме она исписались, а читать русский язык не научилась. Напоминаю тебе исходное утверждение "Под linux писать на асме гораздо ПРИЯТНЕЕ чем под DOS или под Windows". Или тут кто-то сомневался, что ты первая в ДОСе после бога? >> Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных. > Сразу видно вебмакаку, ни разу не использовавшую 16-битную архитектуру. Цпу сам, представь > себе, автоматически делает операцию умножения и сложения между значением сегмента и > смещения при доступе к данным. Ты совершенно свободно можешь использовать весь > мегабайт под свои деревья (ну, кроме биоса, адресов замапленых на порты > в/в устройств, текущей экранной части видеопамяти, таблицы прерываний и ОС - > крч 640КБ плюс хвостик) - главное, не забыть одну простую вещь..., Кто ей сказал, что я могу? Её обманули. Меня жаба давит, я не привык так памятью разбрасываться. > тадаааааам..., внимание, сейчас вылетит птичка..., вот: использовать два слова под указатели, > а не один! одно под сегмент, одно под смещение. А что не 10? Чё мелочиться то, давай, вперёд. Я могу _в_ _некоторых_ случаях две ноды вместо одной использовать. >> Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются. > А-ха-ха-ха-ха-ха-ха-ха!!!! Ну вы бы, детки, хоть в интернет заглядывали прежде чем позориться > прилюдно на таких элементарнейших вещах. > Вся вышеописанная математика 32 и 64 архитектуры используется всегда! Включая так называемый > "реальный" режим работы 32 бит, когда при переключении из защищенного, надо > было сначала подготовить и загрузить в селекторы правильно приготовленные вышеперечисленные > чиселки (они при этом дублировались в теневые "типа кеш" регистры и > только потом прыгать в реальный. > Вот так вот - трансляция линейного адреса в физический - очень непростая > задача. У тебя комплекс непризнанного автора никому ненужной ОС, или зачем ты это пишешь? Я теряюсь в догадках. Повторяю: Под linux писать на асме. Это значит, что мы говорим о написании приложений, где плоская модель памяти. >> Ну, расскажи нам, зачем нужен префикс lock. > Достижение атомарности операций. Учись, студент, пока я жив. Когда ты предположил, что оппонент на может прочитать книжку, и возвёл свое предположение в догму ты чем руководствовался?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #296

348. Сообщение от анонн (ok), 09-Дек-19, 19:59	+/–
> Лол спасибо. Только ты очередной раз показал своё незнание. Сисколов будет не > столько же. Ты бы вот чисто для разнообразие сам бы проверил, > но нет это же надо голову включить средний анонн на такое не способен. Плохая из тебя ванга, аноним. Ну и "знаток" похоже тоже - неважнецкий: truss -fc python2.7 hello.py hello syscall                     seconds   calls  errors getgid                  0.000008887       1       0 getegid                 0.000008694       1       0 ... close                   0.000943776      69       0 _umtx_op                0.000011025       1       0 __getcwd                0.000016785       1       0                       ------------- ------- -------                         0.014583719     934     208 python2.7 -m compileall hello.py   Compiling hello.py ... truss -fc python2.7 hello.pyc   hello syscall                     seconds   calls  errors getgid                  0.000009410       1       0 getegid                 0.000009106       1       0 ...     close                   0.000885475      70       0 _umtx_op                0.000011768       1       0 __getcwd                0.000015304       1       0                       ------------- ------- -------                         0.014424597     934     208 python2.7 -m compileall -c "print 'hello'" option -c not recognized python2.7 -c "print 'hello'" -m compileall                                       hello # и что дальше? > Разница в 5 сисколов между pyc и py. Ну, ты понял. Умный и уверенный вид - не всегда помогают. > А между вызовом команды из стоки и из файла целых 23 сискола разница. Это ты классно придумал приписать мне. Еще бы показал, как анонимые гуру компиляют в байткод и запускают вызов из ком. строки. И что важнее - как (и зачем) потом результаты сравнивают. Чтение файла - это тоже сисколы, если ты не знал. > Но ты продолжай жить в своём мирке с пони где количество сисколов постоянно. Главное, не забывай с умным видом надувать щечки и приписывать мне посторонние высказывания, а то же с опровержениями реальных и лажанутся можешь ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333

349. Сообщение от Аноним (166), 09-Дек-19, 20:04	+/–
> Попытка съехать на буквоедстве. Да лан, расслабься. Если ты не способен восстановить алгоритмы сложнее хелловорлда из асма, это многое объясняет. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298

350. Сообщение от proninyaroslav (ok), 09-Дек-19, 20:12	+/–
> C#: syscalls:   117 > .net core 3.1 Смотрел и судил по скриншоту, там почему то его нет. Но в любом случае показатели не достоверны, так как не ясно насколько быстро работат сам язык, а не просто инициализация + работа языка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #346

351. Сообщение от Аноним (166), 09-Дек-19, 20:27	+/–
> Зачем ему про LTO? Пусть сначала хоть это осилит. Автор сообщения #141 описал, какой LTO должна быть. В теории. На практике пока недотягивает... немножко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #340

352. Сообщение от kai3341 (ok), 09-Дек-19, 21:29	+/–
> Так пишешь, будто sqlite не на той же файловой системе валяется. Происходит ли поиск файла при каждом обращении к уже открытому файлу? Подсказка -- что такое дескриптор? К какому числу файлов необходимо обратиться в случае работы ы sqlite и в случае работы с деревом на ФС? > Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке. То есть вы на полном серьёзе предлагаете отдельно держать дерево файлов с информацией о пакетах (имеющее структуру! Реляционную! Пакеты явно ссылаются друг на друга! Набор полей константный!) и отдельно держать также индекс? Больше файлов богу файлов? Ведь обращения к множеству файлов у нас быстро происходят, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #335

353. Сообщение от Аноним (353), 09-Дек-19, 23:37	+2 +/–
Free Pascal 3: syscalls:    12 taskclock:     0,20 instructions:       120939 /usr/bin/echo: syscalls:    33 taskclock:     0,96 instructions:       785291   Lua 5.3 JIT: syscalls:    77 taskclock:     1,81 instructions:      1900679       Lua 5.3: syscalls:   104 taskclock:     2,97 instructions:      2757088          Bash: syscalls:   178 taskclock:     2,70 instructions:      3045210     Perl 5.26: syscalls:   212 taskclock:     3,78 instructions:      3567224       TCL 8.6: syscalls:   246 taskclock:     6,39 instructions:      8794403    Python 2.7: syscalls:   766 taskclock:    23,54 instructions:     28200486      Ruby 2.5: syscalls:  1915 taskclock:   129,62 instructions:    224858707    Python 3.6: syscalls:  2392 taskclock:   321,96 instructions:    423332563
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #354, #363, #369, #370

354. Сообщение от Ананимас009 (?), 10-Дек-19, 00:13	+/–
Ну вот теперь я доволен :) лучше любого скриптового языка, даже баш обошел, хотя он еще тот тормоз. Обычный sh/csh бы еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353

355. Сообщение от Ананимас009 (?), 10-Дек-19, 00:24	+/–
>> паскаль никогда не был тормозом. проблема его в том что синтаксис слишком >> замудренный, долго писать, тяжело читать исходники. > Пришлось мне когда-то делать проектик на Pascal, который на практике я не > использовал. Реализовал всё в срок, сначала написал и отладил на плюсах, > потом день читал PDF от Free Pascal и день переводил исходник. > Непривычно, не более. Считаю, что язык был закопан исключительно по политическим > мотивам. Если говорить по турбо, он же борланд паскаль, то там имхо было две главных проблемы : - отсутсвие возможности создания obj файла для последующего использования с дру6ими языками, можно было лишь линковать чужие. Вторая - отсутвие множественного наследования в классах как в турбо/борланд си. Хотя в последнем могу ошибаться, давно не касался ни первого ни второго. При этом засчет компеляции модулей существенно сокращалась время компиляции всего проекта. На ЕС1840-1841 это было особенно заметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168

356. Сообщение от Ананимас009 (?), 10-Дек-19, 00:43	+/–
Прерываниыми биоса для вывода текста никто и не пользовался. Серьезные поцанчики работали напрямую с видеопамятью, борясь со снегом для CGA. Ну или досовскими, если речь была про хелловорлд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263

357. Сообщение от svsd_val (ok), 10-Дек-19, 04:25	+/–
> Что же в делфи хорошего? Разве что, если с Жавой сравнивать. В прямых руках не хуже сей++ и скорость разработки П.О. выше и косяков меньше. А если руки из опы тут увы извиняйте нечего на язык пинать коли с головой руки из опы, тут никакой язык не поможет. В своё время писал на нём игры и 64кб демки, особых проблем не видел. А с применением FPC портировал под  Linux и Darwin ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

358. Сообщение от Аноним (327), 10-Дек-19, 04:41	+/–
Нет, это не другое. Подсистема входит в ос, апи публичный, практически все приложения используют его. WriteFile и GetStdHandle от write и open принципиально не отличаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #338 Ответы: #361

360. Сообщение от Аноним (1), 10-Дек-19, 09:31	+/–
О, модераторы снизошли и вернули ветку на место. Я удивлён тем, сколько плюсов собрал этот коммент, ведь он абсолютно не имеет значения. Это какой-то злой пук без аргументов. И что это значит? Что бОльшая часть опеннета - это люди без личной жизни, которым лишь бы противопоставить что-нибудь кому-нибудь и не важно что это будет значить? В любом случае, у меня сложилось супер отрицательное мнение о аудитории этого сайта, комменты не буду больше ни читать не писать, и вообще добавлю их в фильтр адблока. Аноны, вы казались мне рациональными
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

361. Сообщение от Аноним (166), 10-Дек-19, 10:23	+/–
> Нет, это не другое. Вызов ядра непосредственно через шлюз идентичен динамическому связыванию?)) > Подсистема входит в ос, апи публичный, практически все > приложения используют его. Аналогично можно сказать про libc.so > WriteFile и GetStdHandle от write и open принципиально > не отличаются. Вот оно что.))) Пример на асме вызывает не write и open из библиотеки пространства пользователя. Функции определены как sys_write и sys_open макросами, подобными нижеприведённому: #define SYSCALL_DEFINE0(sname)                    \     SYSCALL_METADATA(_##sname, 0);                \     asmlinkage long sys_##sname(void);            \     ALLOW_ERROR_INJECTION(sys_##sname, ERRNO);        \     asmlinkage long sys_##sname(void) https://github.com/torvalds/linux/blob/v5.4/include/linux/sy...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358

362. Сообщение от Аноним (166), 10-Дек-19, 10:36	+/–
> Некоторые индивиды именно _ненавидят_ Паскаль. Будто бы именно они что-то решали в комитете по стандартизации, где по понятным причинам продвинули продукт своих соотечественников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #295

363. Сообщение от kek (??), 10-Дек-19, 10:40	+/–
Это надо было отдельной веткой комментариев пустить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353

364. Сообщение от Аноним (364), 10-Дек-19, 10:44	+/–
То-то я смотрю они из коробки этого франкенштейна боятся распространять. Да и тема MIPS и e2k не раскрыта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #342 Ответы: #365

365. Сообщение от Аноним (166), 10-Дек-19, 10:50	+/–
> То-то я смотрю они из коробки этого франкенштейна боятся распространять. "У меня нет телевизора: я ем грибы и смотрю ковёр". (с) Он (автор у fasm-а один) распространяет только свой продукт и как считает нужным. Точно так же отдельно идёт gcc, отдельно boost и прочие библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364

366. Сообщение от sage (??), 10-Дек-19, 12:34	+1 +/–
Какие миллисекунды? dnf — самый медленный пакетный менеджер из менеджеров в популярных дистрибутивах. Каждый раз его запускаешь и ждешь, пока он пропердится, пока всё прогрузит. Fedora с 30 до 31 обновляется на SSD примерно полтора часа чистого времени (без учета скачивания пакетов).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

367. Сообщение от Аноним (367), 10-Дек-19, 14:50	+1 +/–
Чтобы не поддерживать монополию, у юзеров должна быть возможность приобрести альтернативы, способные полностью заменить, а то и превзойти продукт монополистов. Что могут предложить Риска и прочие подобные проекты, чтоб юзеры вот прям сейчас бросились их покупать? Идеологическую чушь про "свободу используемых команд от корпораций" для полутора поехавших фанатиков? Нет, ребята, рынок так не работает. По факту это ноль целых нифига десятых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288

368. Сообщение от Аноним (267), 10-Дек-19, 16:17	+/–
Здесь Кэй демонстрирует ту систему из 70-х в эмуляторе, суди сами: https://youtu.be/AnrlSqtpOkw?t=2m37s
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #324

369. Сообщение от XXX (??), 10-Дек-19, 16:47	+/–
Это откуда циферки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353 Ответы: #371

370. Сообщение от Аноним 353 (?), 10-Дек-19, 20:58	+/–
для третьего питона неверные результаты, так точнее плюс csh:   Python 3.6: syscalls:   760 taskclock:    65,81 instructions:     83990520 csh 20110502: syscalls:  2250 taskclock:     6,79 instructions:      7491956
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353

371. Сообщение от Аноним 353 (?), 10-Дек-19, 21:07	+/–
запустил скрипт Джеффа, ссылка в статье
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369

372. Сообщение от Kaiwas (?), 10-Дек-19, 22:56	+1 +/–
только тут 'hello' могло так взбудоражить умы и быть поводом для сра4eй )
Ответить | Правка | Наверх | Cообщить модератору

373. Сообщение от suffix (ok), 11-Дек-19, 00:23	+/–
>Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086. А что там сложного то ? Кол ассигн по k-ому каналу, по n-ому флагу и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #276 Ответы: #397

374. Сообщение от Аноним (-), 11-Дек-19, 04:00	+/–
> Так не требуют производительности же. Ну например dnf. А в результате дебиан ворочается на vm с 128 мегами памяти, тогда как DNF дохнет и на 512. С вонью и брызгами - база после выноса OOM убита в хлам. Как ее восстанавливать - ктулху его знает. В общем отвратительный пакетный менеджер. По сравнению с тем что в debian, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

375. Сообщение от Аноним (-), 11-Дек-19, 04:04	+/–
Уже i++'й год переписывают, а все-равно куча пихона жрущая RAM оптом. И просто адское месиво вместо пакетного менеджера, говоря начистоту. Хороший пример как не надо делать пакетные менеджеры. По сравнению с этим позором даже менеджер какой-нибудь FreeBSD - шедевр.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240

376. Сообщение от Аноним (-), 11-Дек-19, 04:11	+/–
> Можно использовать microdnf, который python-free: Выковыривать за редхатом непотребное - зачем? Можно просто дебиан взять. Там пакетный менеджер изначально нормально сделан. Они почему-то смогли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

377. Сообщение от Аноним (-), 11-Дек-19, 04:14	+/–
> Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше! Когда у меня сдохла база пакетов по OOM в редхате - приключений было никак не на 2 секунды. Это в дебиане пакетный менеджер не дохнет фатально, даже при OOM, а если что не так - подскажет как починить. А в редхате вместо пакетного менеджера - индусский энтерпрайзный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

378. Сообщение от Аноним (-), 11-Дек-19, 04:16	+/–
> А теперь пусть напишет на асемблере бизнес логику Ну, блин, не всем же бизнес-логика нужна. Вот зачем мне твоя бизнес логика например? Спекулянтам ее втюхивай, пока их не раскулачили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

379. Сообщение от Аноним (-), 11-Дек-19, 04:17	–3 +/–
Может, никто не написал? Напишите и доложите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

380. Сообщение от Аноним (-), 11-Дек-19, 04:19	+/–
> Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает > производителям железа продавать новое железо. Он просто glibc наверное не пользуется :). Сишники тоже так могут - просто не все об этом догадываются. Можно вообще стандартные либы не линковать, взял да и сделал сам все syscall()-ы. Ну да, неудобненько и портабельность хромает. Но если с ассемблером зарубаться - на нем еще неудобнее и портабельность еще хуже, так что не аргумент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

381. Сообщение от Аноним (-), 11-Дек-19, 04:21	+/–
> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. Поэтому если у вас не энтерпрайзный сервак считающий неделю какую там бизнеслогику - получается нечто ужасное, старт hello world на этом больше похож на запуск космической ракеты. И то там наверное меньше действий требуется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

382. Сообщение от Аноним (-), 11-Дек-19, 04:25	+/–
> Наглядно демонстрирует, любителя забивать гвозди микроскопом, > и что кроме хелоуворлда на асме ничего не пишется. Еще кодеки и крипто забыли. Хорошая ассемблерная реализация может чисто сишную разика этак в три подвинуть если компилер с кодогенерацией в неудачном месте протупляет. Сишники правда немного жульничают сейчас с intrinsics, но по большому счету, это по сути тот же ассемблер и получается, просто чуть более кроссплатформенно и портабельно. Но из-за привязки к особенностям процессоров - именно чуть. Ну то-есть простой фрагмент может быть даже и соберется не только на SSE2 но и на neon каком. Но половина кода завалится за отсутствием потребных эквивалентов команд у железа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

383. Сообщение от Аноним (-), 11-Дек-19, 04:26	+/–
игогошечка годится для мелких серверцов, ну вообще совсем не как баш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

384. Сообщение от Аноним (-), 11-Дек-19, 04:30	–1 +/–
Ну ладно, а чего там на 207 кило? А то сишный бинарь с этим вот, после strip - 14 кило... Ну или с отладкой - так и быть, 16. Это такой пример насколько у растоманов руки из неправильного места? Или они там с go конкурируют за жирноту программ в дефолтном билде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #390, #403

385. Сообщение от Аноним (385), 11-Дек-19, 04:32	+/–
> На C++ никто не предлагает писать операционки А как же реактос? Им конечно не пользуются даже сами разработчики, но это им не мешает наворачивать ядро на плюсах. Наверное потому что поддержка C VS'ом - уг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

386. Сообщение от Аноним (-), 11-Дек-19, 04:36	+/–
Более того - xapian-index (если это про него) некая весьма опциональная штука. Он реально не нужен ни apt(-get) ни dpkg ни даже synaptic'у. Либа конечно есть но она не кусается. А так - у редхата тоже XMLки кешируются в скулайт, при том после того как они стали выгружать скулайт - XMLки никуда не делись и майнтайнеры все-равно имеют дело с этой монстрятиной. У дебиана в этом плане проще, это простые текстовики, которые можно парсить и без огромных мегабиблиотек. В отличие от XML.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

387. Сообщение от Аноним (-), 11-Дек-19, 04:39	–1 +/–
> "как два пальца"? Два, не два... с базами данных подстава в том что это реально работает у энтерпрайзныx DBA. А когда у меня oom killer выносит к чертям редхатовский пакетный менеджер - так он потом ошметки от своей чудной базы собрать уже не может. И система потом вообще ничего поставить и снести не может. Упс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

388. Сообщение от Аноним (-), 11-Дек-19, 04:42	–1 +/–
Ага, в apt отсутствует возможность убить свою базу в хлам по oom на тощей виртуалке. И если что не так идет - чинится с полоборота. В отличие от редхатского шалтайболтая где без пары саппортов RH вообще нечего ловить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

389. Сообщение от Аноним (-), 11-Дек-19, 04:48	+/–
> (на виртуалке не проявляется). Это на виртуалке по другому проявляется: после внезапного слета питания или ребута такая виртуалка часто отправляется в утиль - она не синхронизировала записи на диск и при внеплановом шатдауне теряется много данных. Порой достаточно чтобы серьезно развалить ФС. Собственно поэтому пакетные менеджеры так и не делают. ...но есть чудные хаки с LD_PRELOAD для самых храбрых, подгрузив либу игнорящую fsync/fdatasync и ко - скорость взлетит до небес. Правда, при внеплановом ребуте в этот момент систему может постичь та же участь что и виртуалку. Убитую виртуалку чинить проще - думаете, чего все разработчики на них это делают? По той же причине они и синхронизацию отключили. Умрет - новую из шаблона сделают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #398

390. Сообщение от burjui (ok), 11-Дек-19, 05:07	+/–
На этот вопрос я вам ответить не могу, не разбирался, а из какого места руки растут, покажет история. Rust пока что молодой, а у старика C за плечами почти 50 лет развития и полировки. Учитывая, как приятно писать на Rust, и какова его производительность, можно точно сказать одно - для 9-летнего щегла весьма неплохо. А компилятор доработают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384 Ответы: #395

391. Сообщение от Аноним (-), 11-Дек-19, 05:26	–1 +/–
> Питон - язык-связка. И пишут на нем сказочные... ну в общем синоним слова "раздолбай". > вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией. А еще упаси меня пользоваться критичным системным софтом от таких разработчиков, яву им в пакетный менеджер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

392. Сообщение от Аноним (-), 11-Дек-19, 05:29	+/–
> то время как всем остальным его придётся сначала запустить.. Cortex-M можно и чистой сишечкой раскочегарить. Но есть нюансы - потом сишечка будет не совсем чистым и вы таки позовете intrinsics/asm()/... - а си внезапно не умеет сам по себе прерывания например запрещать/разрешать, как и вообще доступаться к регистрам которые не mem-mapped.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

393. Сообщение от Аноним (-), 11-Дек-19, 05:32	–1 +/–
> А если консольное и «после разогрева», как тут уже заметили, То как тут уже заметили, это нужно только полутора корпорациям для их бизнес хрени. Все остальное в таком виде никуда не годится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #400

394. Сообщение от Аноним (394), 11-Дек-19, 05:37	–1 +/–
> -rwxr-xr-x 1 govno govno 199K Dec  8 14:00 x Отличное название, суть передает верно. > Может у вас там ночнушки? Это горшки которые?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

395. Сообщение от Аноним (394), 11-Дек-19, 05:43	–1 +/–
> На этот вопрос я вам ответить не могу, не разбирался, а из > какого места руки растут, покажет история. По-моему размер сгенеренных бинарей - показывает. Go конечно еще и не так умеет. > Rust пока что молодой, а у старика C за плечами почти 50 лет развития и полировки. Не помню использования компиляторов с 50-летней историей... да и си 50-летней давности был не очень похож на актуальный. > Учитывая, как приятно писать на Rust, и какова его производительность, можно > точно сказать одно - для 9-летнего щегла весьма неплохо. А компилятор доработают. Маркетинговый булшит и субъективщина, в отличие от результатов забега. В этом вся хипсотота - наобещают в рекламе золотые горы. По факту горы будут из другого материала и их замучаешься вычищать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #390 Ответы: #404

396. Сообщение от Аноним (394), 11-Дек-19, 05:44	+/–
> Убийство - преступление. Killall - вообще сплошной геноцид демонов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #307

397. Сообщение от Аноним (166), 11-Дек-19, 08:11	+1 +/–
>>Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086. > А что там сложного то ? > Кол ассигн по k-ому каналу, по n-ому флагу и т.д. В том то и дело, у PDP11 простая и понятная система команд, позволяющая кодировать непосредственно в восьмеричном представлении машинного кода без мнемоник. Той гиперболой проверял, знаком ли адресант с упомянутой системой команд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #373

398. Сообщение от Аноним (166), 11-Дек-19, 08:24	+/–
Вы переносите на rpm5 ту логику, которая реализована в других пакетных менеджерах, в частности в rpm4. В ROSA Fresh вызовы fdatasync() происходили без меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0. Сравните результаты независимого тестирования: Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек Поиск "правых" зависимостей пакета: urpmq --whatrequires libgcc1 - Mageia=7 сек - ROSA=1 мин. 48 сек. Поиск "правых" зависимостей пакета: urpmq --whatrequires glibc - Mageia=7 сек - ROSA=5 мин.32 сек. https://forum.rosalinux.ru/viewtopic.php?f=56&t=8427&hilit=r... Как оно сделано в rpm5 теперь никто не знает. Автор проект забросил, а исключительные инженеры тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #389 Ответы: #399, #406

399. Сообщение от Аноним (166), 11-Дек-19, 08:31	+/–
Примечательно, что без отключения fdatasync() БД всё одно падает, что объясняется "магическими причинами: Иногда, в силу каких-то магических причин база RPM падает. Ничего не установить, не обновиться, не удалить. Обычно признаки падения базы RPM примерно такие: http://wiki.rosalab.ru/ru/index.php/%D0%95%D1...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #398

400. Сообщение от Anonymoustus (ok), 11-Дек-19, 08:36	+/–
>> А если консольное и «после разогрева», как тут уже заметили, > То как тут уже заметили, это нужно только полутора корпорациям для их > бизнес хрени. Все остальное в таком виде никуда не годится. Чувак, ты просто попробуй. Если тебе нужно что-нибудь кроссплатформенно считать для твоего малого бизнеса — напиши на Жабе и познай смысл жизни и её удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж извини, что мне приходится выступать за КО.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #393 Ответы: #411

401. Сообщение от Anonymoustus (ok), 11-Дек-19, 08:51	+/–
>> Итаниум - это же современный арм, разве что с увеличенной адресной шиной. > Блин, слона-то я и не приметил. Больше вопросов не имею. Да уж, кучу выдающийся специалист Урри отложил размером с гору.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304

403. Сообщение от Аноним (426), 11-Дек-19, 13:08	+2 +/–
> Ну ладно, а чего там на 207 кило? А то сишный бинарь > с этим вот, после strip - 14 кило... Ну или с > отладкой - так и быть, 16. Это такой пример насколько у > растоманов руки из неправильного места? Или они там с go конкурируют > за жирноту программ в дефолтном билде? Это такой пример, как на опеннете обычно сравнивают жопу с пальцем - в этом случае дин. прилинкованный рантайм со статистическим. rustc hello_rust.rs -O -C prefer-dynamic && strip hello_rust && ls -al hello_rust -rwxr-x---  1 аноним  аноним  15296 11 Dez. 17:06 hello_rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384

404. Сообщение от burjui (ok), 11-Дек-19, 14:53	+/–
Аноним демагогировал-демагогировал, да не выдемагогировал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #395 Ответы: #412

405. Сообщение от антон (??), 12-Дек-19, 01:51	+1 +/–
В Haskell автор не смог? That's a shame.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #418

406. Сообщение от Аноним (406), 14-Дек-19, 03:02	+/–
> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0. Само по себе такое возможно и в нормальном виде - если там тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера на запись? Циферки в бенчах эти господа указывают без сброса буферов после каждой команды. Более того - SSD явно желают чтобы их информировали о намерении снять питание и все такое - и логгят если вы это не сделали. И с таким логом хрен чего предъявите производителю за потерю данных, покажут 5-й шрифт в доках и пробурчат "сами виноваты". Еще кстати стоимость разных позиксных вызовов у разных ФС довольно разная. Возможно у разработчика конфигурация была другой. > Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек ... > тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились. А, ну вот и объяснение факапища. Единственное чего я не понял - чего можно с fdatasync делать при поиске?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #398 Ответы: #425

407. Сообщение от Аноним (-), 14-Дек-19, 03:16	+/–
> Многие вещи в линукс реализованы на python, например - это в 144 > более затратно, чем на C. Все эти вещи к Linux (который вообще ядро) не имеют особого отношения. Можно юзать Linux вообще без всяких питонов. Питон затратен не только по системным вызовам - он еще и интерпретируемый к тому же. Это сразу его выносит в совсем другую лигу по скорости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

408. Сообщение от Аноним (-), 14-Дек-19, 03:17	+/–
> Технически, это камень в сторону компиляторов. Или рантаймов/библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

409. Сообщение от Аноним (-), 14-Дек-19, 03:18	+/–
> Некоторые индивиды именно _ненавидят_ Паскаль. Я вот учился на паскале, но в конце концов перешел на си. Системные вещи на паскале - ну не то чтобы совсем нельзя, чуваки даже в досе саундбластер из паскаля напрямую программировали. Но выглядело это порнографически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #295

410. Сообщение от Аноним (-), 14-Дек-19, 03:26	+/–
> А прикинь, сколько он бы потратил на программистов, пиши и сопровождай они > бизнес логику на ассемблере/с/спп? И тем не менее, LSE однажды познали что иной раз проще и дешевле не только писать на си++ но и всю команду купить. По сравнению с выплатами дотнетчикам за устранение их же клюков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

411. Сообщение от Аноним (-), 14-Дек-19, 03:34	–1 +/–
> Чувак, ты просто попробуй. У меня нет юзкейсов для этой фигни. > удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж > извини, что мне приходится выступать за КО. Компилировать ничего не надо, потому что это фуфло не только кряхтит GC, но и тащит с собой весь компилятор и поэтому тормозить своей компиляцией будет прямо в процессе работы. При том сгенерить именно оптимальный код - надо убить море ресурсов. И одно дело если это билдферма где-то там сделала месяц назад и другое - если это вотпрямща под текущим юзером, тудыть. Это уже даже до веб-хомяков доперло. Вон go - таки компилируемый. И одно это ему дает 100 очков форы. А вот прямо по сравнению с явой - он своим компилером будет тупить не при обслуживании юзера. И это хорошо и правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #400 Ответы: #426

412. Сообщение от Аноним (-), 14-Дек-19, 03:39	+/–
> Аноним демагогировал-демагогировал, да не выдемагогировал. Признаю: в порожней демагогии ты меня сделал как с куста. Но маркетинг у тебя все же лажовенький.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #404

413. Сообщение от Аноним (-), 14-Дек-19, 03:43	–1 +/–
> Для мыши есть int 33. И в учебниках это было описано еще > тогда, когда вас у родителей и в планах не было. Ага, а у современного железа с IOAPIC это может быть... эээ... у APIC много прерываний. И кстати что такое int33, допустим, в контексте usb? USB как таковой вообще прерываниями не оперирует. Хоть какие-то приколисты и назвали один из типов транзакций interrupt, но это не имеет ничего общего с прерываниями проца.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244

414. Сообщение от Аноним (414), 14-Дек-19, 03:52	+/–
> наблюдениям могу сказать, что может быть как двукратный прирост(php), так и > нулевой(zlib). У Zlib проблемы производительности просто не там. Есть всякие zlib-ng и проч, разгоняющие его раза в 2-3. А еще можно несколько тредов сделать. А есть наоборот, библы которые например пакуют плотнее оригинала, при совместимости формата с zlib. Просто это несколько нишевое и нужно не всем. Обладатели большого парка серверов - может и заморочатся, на предмет как снизить нагрузку или объем трафа, смотря что больше жмет. Но рядовому юзеру и zlib - либа. Хоть на нее и забили все кому не лень и это уже и близко не state of art. Ну и вообще - кто сказал что профайлинг серебряная пуля? Иди вон LZ4 обгони, хоть с профайлером, хоть с JIT, хоть с ассемблером. Там человек сделал железу удобно. А даже и просто сями. Настолько, что профилировать особо нечего: узнал ты что алгоритм уперся в скорость RAM. А дальше, собственно, чего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

415. Сообщение от Аноним (414), 14-Дек-19, 03:53	+/–
> Где, собственно, Java и применяется. Поэтому она "где-то там" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

416. Сообщение от Аноним (414), 14-Дек-19, 03:58	+/–
> во времена появления Си, но переписывания кода с x86-64 на ARM > по прежнему не приносит радости. К счастью на си это можно и не делать. Ну так, глядя на 25519 перепертый 1 в 1 с писючного tweetnacl в микроконтроллер. Да, на асме он будет быстрее...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

417. Сообщение от Аноним (414), 14-Дек-19, 04:01	+/–
У tcc есть один нюанс: компилим им какую-нибудь алгоритмику... и убеждаемся что gcc его очень сильно обижает с -O2/-O3. И дальше радости с уменьшения числа сисколов будет маловато.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

418. Сообщение от Аноним (-), 14-Дек-19, 04:03	+/–
> В Haskell автор не смог? That's a shame. Ну так смоги ты и выложи результаты, например?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #405

419. Сообщение от Аноним (-), 14-Дек-19, 04:08	–1 +/–
> Поиск на карте (с частым построением графов), кстати, одна из тех задач, > где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы > в виде реализации сборки мусора не в счет, естественно. Фича сей и тому подобных в том что если тебе надо GC - его можно сделать. Поэтому кому было надо - у них и си стал довольно высокоуровневым. А вот если в каком-нибудь Go этот самый GC мешается - уже упс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254

420. Сообщение от Аноним (-), 14-Дек-19, 04:09	+/–
> OpenCL-компиляторы -- могут. У них даже и не SSE/AVX. У типичного GPU алушек и регистров больше чем у дурака фантиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

421. Сообщение от Аноним (-), 14-Дек-19, 04:11	+/–
> Нет, по сути это не ассемблер. Не нужно вручную распределять регистры,   > есть проверка типов. По сути это возможность использовать почти ассемблерные вещи из типа-сей. Правда, начинаются те же проблемы - а такие интринсики компилятся лишь немногим портабельнее ассемблера, фичи бывают слишком уж специфичными для конкретных архитектур.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #327

422. Сообщение от Аноним (-), 14-Дек-19, 04:13	+/–
> Удивительно, как Питон почти на порядок просел относительно него. Удивительно - что это говорит разработчик из, кажется, BSD. Который мог бы и догадываться почему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

423. Сообщение от Аноним (-), 14-Дек-19, 04:17	+/–
> Может asmhttpd не на производительность заточен, а на потребление памяти. А lwan'а он делает? Этот и на производительность и на потребление памяти смотрит, автор явно шпарит в оптимизациях. И к тому же он может делать более-менее практичные вещи - вплоть до шаблонов и БД (см примеры, там реализации ряда вебапликушных бенчей - даже с базами и ответами в JSON). Правда lwan на си. Да и основная фича - удобный API handler'ов. А coroutines обеспечивают довольно прозрачную работу всего этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

424. Сообщение от Аноним (-), 14-Дек-19, 04:28	–2 +/–
> Ну зачем сразу из крайности в крайность? Не, ну можно и как парни из dropbox - переписать с ноля, три раза. Или как Брэйн Кохем, вынужденный в конце концов купить комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто потому что когда 300 кил прожка на винапи адово втыкает адовому питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #427

425. Сообщение от Аноним (166), 14-Дек-19, 06:44	+/–
>> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0. > Само по себе такое возможно и в нормальном виде - если там > тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера > на запись? Циферки в бенчах эти господа указывают без сброса буферов > после каждой команды. Более того - SSD явно желают чтобы их > информировали о намерении снять питание и все такое - и логгят > если вы это не сделали. И с таким логом хрен чего > предъявите производителю за потерю данных, покажут 5-й шрифт в доках и > пробурчат "сами виноваты". Это понятно. Другой дело, что на том же железе, на той же ФС, за то же время устанавливались те же пакеты в Gentoo, собираясь из исходников. > Еще кстати стоимость разных позиксных вызовов у разных ФС довольно разная. Так точно. Устанавливал эту ROSA Fresh на ZFS, где синхронизация отключается в свойствах тома https://github.com/zfsonlinux/zfs/blob/zfs-0.8-release/man/m... потому проблему не видел до смены ФС. > Возможно > у разработчика конфигурация была другой. У директора в то время вообще была MacOS. Разработчики (коих тогда было трое, включая "QA") признали проблему, как видно по ссылке на форум и из анонса R11 https://www.opennet.ru/opennews/art.shtml?num=50325 (здесь, кстати, исправили оригинальное fsync() на корректное fdatasync() -- то есть составитель "инженер" РОСА откровенно плавает в вопросе). >> Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек > ... >> тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились. > А, ну вот и объяснение факапища. Единственное чего я не понял - > чего можно с fdatasync делать при поиске?! Перестраивать индексы БД для ускорения повторного поиска. При чём делать это каждый раз (с чем и следовало разбираться, а безусловное отключение fdatasync и не является решением, лишь заметает грязь под ковёр).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #406

426. Сообщение от Аноним (426), 14-Дек-19, 14:11	+/–
>> удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж извини, что мне приходится выступать за КО. > Компилировать ничего не надо, потому что это фуфло не только кряхтит GC, > но и тащит с собой весь компилятор https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html > Chapter 6. The Java Virtual Machine Instruction Set > aaload > bipush https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht... > A Code attribute contains the Java Virtual Machine instructions and auxiliary information for a single method, The Code attribute has the following format: Code_attribute {     u2 attribute_name_index;     u4 attribute_length;     u2 max_stack;     u2 max_locals;     u4 code_length;     u1 code[code_length];     u2 exception_table_length;     {   u2 start_pc;         u2 end_pc;         u2 handler_pc;         u2 catch_type;     } exception_table[exception_table_length];     u2 attributes_count;     attribute_info attributes[attributes_count]; } Ох уж эти опеннетные знатоки жабы, оба два. > и поэтому тормозить своей > компиляцией будет прямо в процессе работы. При том сгенерить именно оптимальный код - надо убить море ресурсов. И одно дело если это > билдферма где-то там сделала месяц назад и другое - если это > вотпрямща под текущим юзером, тудыть. И процесса компиляции с оптимизацией - тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #411

427. Сообщение от Аноним (427), 14-Дек-19, 18:42	+/–
> Или как Брэйн Кохем, вынужденный в конце концов купить > комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто > потому что когда 300 кил прожка на винапи адово втыкает адовому > питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен. Правда, опять наш скромный анонимный аналитик стыдливо умалчивает незначительный фактик появления первой плюсовой реализация только годика через 4 после выхода питонячьей. Но! Как знают все-все-все стоящие аналитики опеннета: дело там было совсем уже почти все еще наверняка не в окончательном доказательстве практической эффективности протокола (там придумывать-то было - раз два и готово! Ну, наверняка так, раз уж даже питонисты с этим справились! Вон, Napster и eDonkey сразу писались на правильных сишках или плюсах и отличались завидной эффек … ой)! Как и не в обкатке, доводке и шлифовке протокола на питоньем прототипе - чего там доводить-то, оно ж само все ясно, стоит только чуть напрячь мозги! А все дело в том, что у спецов просто руки не доходили - ну там напстер и осла на правильныя ЯП писать надо было. А не то бы они бы питонистам бы как показали! Ух!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #424

428. Сообщение от Аноним (428), 16-Мрт-20, 12:59	+/–
> sqlite это шаг к реестру винды,  no way Какое просто позорное незнание! Раз уж сами речь о реестре завели. - Реестр для того и придуман, причём ещё во времена ПК уровня 486 100Mhz/ip1-50Mhz - чтобы компатно хранить, удобно централизованно искать текстовым поиском и усткорять доступ, притом не забывая про WINAPI установщиками и автоматичноть периодического авто-backup позже добавенного на случаи непредвиденных перезагрузок. Да, он в виндах реализован мог бы быть и ещё быстрей и удобней, но тем не менее. И систменые требования тех ОС я привёл - вовсе не случайно, соответвенно. Позор Торвальдсу и BSD-гомосятинам - что до сих пор ниасилил(и) [понять таких элементарных вещей]. А, sqlite тот ещё несравнимый тормоз, особенно если извратить формат БД, но скорей как из-за его скриптовости-для-кухарок, так и потому что там значительный переизбыток функциональности и универсальности ненужной в ОС реестре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема