The OpenNET Project / Index page

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



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

Оглавление

Опубликованы тесты простейших приложений на различных языках..., opennews (??), 08-Дек-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


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

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

8. "Опубликованы тесты затрат на выполнение простейших приложени..."  –3 +/
Сообщение от Илья (??), 08-Дек-19, 09:44 
> реализованы на python

Так не требуют производительности же. Ну например dnf.

Ответить | Правка | Наверх | Cообщить модератору

54. "Опубликованы тесты затрат на выполнение простейших приложени..."  +7 +/
Сообщение от Аноним (54), 08-Дек-19, 12:11 
> не требуют производительности же. Ну например dnf.

Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?

Ответить | Правка | Наверх | Cообщить модератору

99. "Опубликованы тесты затрат на выполнение простейших приложени..."  +3 +/
Сообщение от kai3341 (ok), 08-Дек-19, 14:22 
> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?

А что именно там тормозит не подскажете? Где узкое место?

apt, apt-get, aptitude, dpkg тормозят ещё больше, кстати. Потому, что давайте информацию о пакетах положим файлами на ФС! А потом будем вычитывать эти файлы в память! Больше чтений диска, это же быстро происходит! sqlite не нужен, это сложно!

Ответить | Правка | Наверх | Cообщить модератору

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

122. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от kai3341 (ok), 08-Дек-19, 15:36 
>  sqlite это шаг к реестру винды,  no way

То есть вы настаиваете на том, что идейность важнее здравого смысла?
Кстати, где вы реестр нашли? Хм. Похоже, идейность уже заменила вам здравый смысл.

Ответить | Правка | Наверх | Cообщить модератору

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

157. "Опубликованы тесты затрат на выполнение простейших приложени..."  –4 +/
Сообщение от kai3341 (ok), 08-Дек-19, 17:42 
>  Где ты нашёл здравый смысл? sqlite тормозит сильнее, чем xapian.

А чтобы поиск не тормозил, мы в дополнение к базе пакетов на диске добавим xapian! Это же так здорово, когда для выполнения одной и той же задачи используются сразу 2 вещи одновременно! И работающий всё время сервис -- это же так круто! Ведь пользователь занимается поиском пакетов всё свободное время!

Ответить | Правка | Наверх | Cообщить модератору

190. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от имя (ok), 08-Дек-19, 19:17 
> И работающий всё время сервис -- это же так круто!

Xapian — библиотека, а не сервис. Вас, видимо, очень больно покусали фанатики Elasticsearch.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

191. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от имя (ok), 08-Дек-19, 19:21 
> sqlite это шаг к реестру винды,  no way

Я вам реестров принёс: http://mirror.centos.org/centos-7/7/os/x86_64/repodata/

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

428. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (428), 16-Мрт-20, 12:59 
> sqlite это шаг к реестру винды,  no way

Какое просто позорное незнание! Раз уж сами речь о реестре завели.
- Реестр для того и придуман, причём ещё во времена ПК уровня 486 100Mhz/ip1-50Mhz - чтобы компатно хранить, удобно централизованно искать текстовым поиском и усткорять доступ, притом не забывая про WINAPI установщиками и автоматичноть периодического авто-backup позже добавенного на случаи непредвиденных перезагрузок.
Да, он в виндах реализован мог бы быть и ещё быстрей и удобней, но тем не менее.
И систменые требования тех ОС я привёл - вовсе не случайно, соответвенно.
Позор Торвальдсу и BSD-гомосятинам - что до сих пор ниасилил(и) [понять таких элементарных вещей].

А, sqlite тот ещё несравнимый тормоз, особенно если извратить формат БД,
но скорей как из-за его скриптовости-для-кухарок, так и потому что там значительный переизбыток функциональности и универсальности ненужной в ОС реестре.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

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

139. "Опубликованы тесты затрат на выполнение простейших приложени..."  +3 +/
Сообщение от Аноним84701 (ok), 08-Дек-19, 16:27 
> Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?

Админы нелокалхоста не слышали об ACID? o_O
Или же для них реализовать трансакцию/atomic commit на любой ФС  - "как два пальца"?  

Ответить | Правка | Наверх | Cообщить модератору

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

387. "Опубликованы тесты затрат на выполнение простейших приложени..."  –1 +/
Сообщение от Аноним (-), 11-Дек-19, 04:39 
> "как два пальца"?

Два, не два... с базами данных подстава в том что это реально работает у энтерпрайзныx DBA. А когда у меня oom killer выносит к чертям редхатовский пакетный менеджер - так он потом ошметки от своей чудной базы собрать уже не может. И система потом вообще ничего поставить и снести не может. Упс.

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

160. "Опубликованы тесты затрат на выполнение простейших приложени..."  –1 +/
Сообщение от kai3341 (ok), 08-Дек-19, 17:47 
>  Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?

Произвольный доступ к диску уже приблизился по скорости к последовательному? Индексы на ФС уже завезли?

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

167. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (54), 08-Дек-19, 18:15 
> Произвольный доступ к диску уже приблизился по скорости к последовательному?

Да, уже лет много как придумали SSD.

> Индексы на ФС уже завезли?

Apt использует xapian для индексов.

Ответить | Правка | Наверх | Cообщить модератору

173. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от kai3341 (ok), 08-Дек-19, 18:36 
>> Произвольный доступ к диску уже приблизился по скорости к последовательному?
> Да, уже лет много как придумали SSD.

Как говорил Чапаев, есть один нюанс. С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт?

>> Индексы на ФС уже завезли?
> Apt использует xapian для индексов.

Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY?

Ответить | Правка | Наверх | Cообщить модератору

335. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (335), 09-Дек-19, 19:16 
> С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт?

Так пишешь, будто sqlite не на той же файловой системе валяется.

> Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY?

Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке.

Ответить | Правка | Наверх | Cообщить модератору

352. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от kai3341 (ok), 09-Дек-19, 21:29 
> Так пишешь, будто sqlite не на той же файловой системе валяется.

Происходит ли поиск файла при каждом обращении к уже открытому файлу?
Подсказка -- что такое дескриптор? К какому числу файлов необходимо обратиться в случае работы ы sqlite и в случае работы с деревом на ФС?

> Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке.

То есть вы на полном серьёзе предлагаете отдельно держать дерево файлов с информацией о пакетах (имеющее структуру! Реляционную! Пакеты явно ссылаются друг на друга! Набор полей константный!) и отдельно держать также индекс? Больше файлов богу файлов? Ведь обращения к множеству файлов у нас быстро происходят, да?

Ответить | Правка | Наверх | Cообщить модератору

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

136. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от Аноним (54), 08-Дек-19, 16:20 
> apt, apt-get, aptitude, dpkg тормозят ещё больше

ЛПиП
Показывай time на аналогичных командах.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

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

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

166. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от Аноним (166), 08-Дек-19, 18:08 
>> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
> А что именно там тормозит не подскажете? Где узкое место?

Про эти не скажу, а вот в ROSA Fresh тормозил rpm5 из-за беспорядочно вызываемого fdatasync(). Процессорные ядра почти свободны, а система стоит колом, пользоваться невозможно, пришлось исправлять. Забавно, что сами разработчики не замечали (на виртуалке не проявляется).

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

389. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 04:48 
> (на виртуалке не проявляется).

Это на виртуалке по другому проявляется: после внезапного слета питания или ребута такая виртуалка часто отправляется в утиль - она не синхронизировала записи на диск и при внеплановом шатдауне теряется много данных. Порой достаточно чтобы серьезно развалить ФС. Собственно поэтому пакетные менеджеры так и не делают.

...но есть чудные хаки с LD_PRELOAD для самых храбрых, подгрузив либу игнорящую fsync/fdatasync и ко - скорость взлетит до небес. Правда, при внеплановом ребуте в этот момент систему может постичь та же участь что и виртуалку. Убитую виртуалку чинить проще - думаете, чего все разработчики на них это делают? По той же причине они и синхронизацию отключили. Умрет - новую из шаблона сделают.

Ответить | Правка | Наверх | Cообщить модератору

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ообщить модератору

399. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (166), 11-Дек-19, 08:31 
Примечательно, что без отключения fdatasync() БД всё одно падает, что объясняется "магическими причинами:

Иногда, в силу каких-то магических причин база RPM падает. Ничего не установить, не обновиться, не удалить. Обычно признаки падения базы RPM примерно такие:

http://wiki.rosalab.ru/ru/index.php/%D0%95%D1...

Ответить | Правка | Наверх | Cообщить модератору

406. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (406), 14-Дек-19, 03:02 
> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0.

Само по себе такое возможно и в нормальном виде - если там тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера на запись? Циферки в бенчах эти господа указывают без сброса буферов после каждой команды. Более того - SSD явно желают чтобы их информировали о намерении снять питание и все такое - и логгят если вы это не сделали. И с таким логом хрен чего предъявите производителю за потерю данных, покажут 5-й шрифт в доках и пробурчат "сами виноваты".

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

> Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек

...
> тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.

А, ну вот и объяснение факапища. Единственное чего я не понял - чего можно с fdatasync делать при поиске?!

Ответить | Правка | К родителю #398 | Наверх | Cообщить модератору

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ообщить модератору

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

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

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

377. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 04:14 
> Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше!

Когда у меня сдохла база пакетов по OOM в редхате - приключений было никак не на 2 секунды. Это в дебиане пакетный менеджер не дохнет фатально, даже при OOM, а если что не так - подскажет как починить. А в редхате вместо пакетного менеджера - индусский энтерпрайзный код.

Ответить | Правка | К родителю #280 | Наверх | Cообщить модератору

164. "Опубликованы тесты затрат на выполнение простейших приложени..."  +5 +/
Сообщение от Анонисмус (?), 08-Дек-19, 17:55 
Можно использовать microdnf, который python-free:
https://github.com/rpm-software-management/microdnf

Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

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

Спасибо, на меня просмотр работы обновления dnf очень положительно влияет. Прихожу домой с работы, sudo dnf upgrade и сижу зачем-то смотрю, как он работает

Ответить | Правка | Наверх | Cообщить модератору

193. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от Анонисмус (?), 08-Дек-19, 19:50 
Не факт, что в этом виноват именно dnf, а не скорость Вашего интернет-соединения или ширина канала зеркала откуда обновляетесь.
Ещё не факт, что у Вас не установлено кучу пакетов, о назначении которых Вы даже не догадываетесь.

Есть возможность выкачивать только дельты пакетов:

https://stackoverflow.com/questions/30553951/how-to-enable-d...

Ответить | Правка | Наверх | Cообщить модератору

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

223. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Анонисмус (?), 08-Дек-19, 22:14 
Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv, а не во всем выше перечисленном или в прослойке между компьютером и креслом.

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

Ответить | Правка | Наверх | Cообщить модератору

336. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (335), 09-Дек-19, 19:19 
> Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv

Проблема точно не в libsolv, ибо zypper летает.

Ответить | Правка | Наверх | Cообщить модератору

376. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 04:11 
> Можно использовать microdnf, который python-free:

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

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

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

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

374. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 04:00 
> Так не требуют производительности же. Ну например dnf.

А в результате дебиан ворочается на vm с 128 мегами памяти, тогда как DNF дохнет и на 512. С вонью и брызгами - база после выноса OOM убита в хлам. Как ее восстанавливать - ктулху его знает. В общем отвратительный пакетный менеджер. По сравнению с тем что в debian, например.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

31. "Опубликованы тесты затрат на выполнение простейших приложени..."  –2 +/
Сообщение от Аноним (31), 08-Дек-19, 11:13 
>например - это в 144 более затратно, чем на C.

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

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

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

А в python большинство этого функционала доступно из коробки в виде стандартной библиотеки, например.

Ответить | Правка | Наверх | Cообщить модератору

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

78. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Фигноним (?), 08-Дек-19, 13:22 
Не туда ответил, ну ладно.
Ответить | Правка | Наверх | Cообщить модератору

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

117. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от Анонисмус (?), 08-Дек-19, 15:21 
Write-only - это скорее Perl, в котором, по словам его создателя, можно одну и ту же задачу выполнить несколькими способами.

Это значит, что читать такой код будет нелегко.

Ответить | Правка | Наверх | Cообщить модератору

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

274. "Опубликованы тесты затрат на выполнение простейших приложени..."  +1 +/
Сообщение от Аноним (273), 09-Дек-19, 04:58 
> по словам его создателя, можно одну и ту же задачу выполнить несколькими способами

Так в любом языке

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

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

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

424. "Опубликованы тесты затрат на выполнение простейших приложени..."  –2 +/
Сообщение от Аноним (-), 14-Дек-19, 04:28 
> Ну зачем сразу из крайности в крайность?

Не, ну можно и как парни из dropbox - переписать с ноля, три раза. Или как Брэйн Кохем, вынужденный в конце концов купить комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто потому что когда 300 кил прожка на винапи адово втыкает адовому питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен.

Ответить | Правка | Наверх | Cообщить модератору

427. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (427), 14-Дек-19, 18:42 
> Или как Брэйн Кохем, вынужденный в конце концов купить
> комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто
> потому что когда 300 кил прожка на винапи адово втыкает адовому
> питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен.

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

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


Ответить | Правка | Наверх | Cообщить модератору

391. "Опубликованы тесты затрат на выполнение простейших приложени..."  –1 +/
Сообщение от Аноним (-), 11-Дек-19, 05:26 
> Питон - язык-связка.

И пишут на нем сказочные... ну в общем синоним слова "раздолбай".

> вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.

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

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

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

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

407. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 14-Дек-19, 03:16 
> Многие вещи в линукс реализованы на python, например - это в 144
> более затратно, чем на C.

Все эти вещи к Linux (который вообще ядро) не имеют особого отношения. Можно юзать Linux вообще без всяких питонов. Питон затратен не только по системным вызовам - он еще и интерпретируемый к тому же. Это сразу его выносит в совсем другую лигу по скорости.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

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

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

392. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 05:29 
> то время как всем остальным его придётся сначала запустить..

Cortex-M можно и чистой сишечкой раскочегарить. Но есть нюансы - потом сишечка будет не совсем чистым и вы таки позовете intrinsics/asm()/... - а си внезапно не умеет сам по себе прерывания например запрещать/разрешать, как и вообще доступаться к регистрам которые не mem-mapped.

Ответить | Правка | Наверх | Cообщить модератору

378. "Опубликованы тесты затрат на выполнение простейших приложени..."  +/
Сообщение от Аноним (-), 11-Дек-19, 04:16 
> А теперь пусть напишет на асемблере бизнес логику

Ну, блин, не всем же бизнес-логика нужна. Вот зачем мне твоя бизнес логика например? Спекулянтам ее втюхивай, пока их не раскулачили.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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