The OpenNET Project / Index page

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



Индекс форумов
Составление сообщения

Исходное сообщение
"В рамках проекта Runtime.JS развивается ядро ОС на базе..."
Отправлено Аноним, 04-Июл-14 05:28 
> старенький, да, корадвадуба на 3 ггц. я очень консервативен,

Я себе относительно свежее железо все-таки взял. Чтобы не знакомиться с UEFIанскими secure-boot и FAT32 разделами на системных дисках в ближайшие годы. Зато система с IOMMU, современными разновидностями шин и кучей ядер. Еще и оперативка с ECC (у AMD так и на десктопах можно). На ближайшее время хватит.

> и технику меняю с трудом.

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

> уходит на раскрутку всяких шаблонов. нет, это не цпп. ;-)

Ну это как-то далеко от меня и моих задач.

> не в том, какое там железо, а в том, какие задачи на технике крутит хозяин.

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

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

Открывается то нормально, но могут случиться внезапные сюрпризы типа OOM killer-а. Немало удивлялся, попробовав устроить "тестовый забег" в духе моего типичного использования веба на хромиуме и получив OOM на машине с 8 гигз. Это было ВНЕЗАПНО, да.

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

Я это вообще не запускаю, как максимум раз в месяц - для валидации бага на кроссбраузерность проявления, etc.

> у меня нет софта, которому надо более трёх гигабайт. и я не
> могу представить, зачем мне такой софт нужен. как и большинству пользователей.

Где-то я похожее уже видел, правда там вроде про 640Кб было.

> знаю, чем он там занимается. потому что i/o тоже не особо
> дёргает при этом.

И правда, странно. Чего почтарю делать 10 секунд с письмом - не понятно. Проц при этом в полку не грузится? (1 ядро)

> зачем ты кормишь компилятор портянками на 20 гигабайт? ;-)

Не компилятор а скомпиленные программы. Я чертовски уверен что не собираюсь ограничиваться 4Гб при работе с mmaped файлами.

> дел-то… два пинка и две минуты, тьфу. при этом один раз.

Да знаешь, в DOS тоже за 2 минуты драйвер с дискетки ставился, но как-то противно машину постоянно тыкать носом как слепого котенка. При том что шины - у машины, так что процу виднее что там прицепили. Зачем мне самолично такой информацией свой мозг загаживать?

> 16 бит. а лучше на 8.

Напугал ежа голым задом. Я до сих пор иногда AVRками пользуюсь. Хотя по возможности как-то предпочитаю 32-битные cortex M3 в подобных применениях. За не в пример более "жирные" MIPSы: 1МГц 8-битника и 32-битника - сильно разные вещи. За нормальное линейное пространство памяти. За могучую периферию. При цене даже дешевле чем большинство атмелок.

>> Да, Кэп, я занимаюсь оптимизациями лишь когда вижу в этом практический смысл.
> то есть, никогда почти. «а чего, пусть лохи технику помощнее покупают». знаю-знаю, жава.

Не настолько редко как тебе кажется. Потому что мелкими железками я все-таки увлекаюсь, по поводу чего твои бухтения мне кажутся в высшей мере забавными. Ты сам то когда в последний раз в 16 кило флеша и 4 кило оперативы укладывался? Там твои навороты типа шаблонов вообще жирование, знаешь ли :)

> понимаешь, привычка класть на оптимизацию проявляется сама по себе.

У меня нет таких привычек. Есть оценка соотношения затрат усилий к результатам. И понимание того ради чего затевается (или не затевается) некое мероприятие. Я не против что-то оптимизнуть, если это не требует затрат времени и не создает дурных неудобств на ровном месте. Слом плагнплея - это в моем понимании недостаток и неудобство. Я считаю что автоконфигурация оборудования это хорошо. Задолбался я перемычки на платах переставлять и прописывать досу драйвера. Нехай само разбирается что и куда подключили.

> в итоге техника всё мощнее,

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

> а софт всё жирней и медленней. при этом никаких
> мегауберфич, которые бы оправдывали тормоза, он не приобретает. do not want.

Тебе никто не запрещает использовать древние версии софта, если они по твоему мнению лучше.

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

Ну так я и не наблюдаю. Я запускаю это в фоне и занимаюсь чем-нибудь другим. Пусть себе там компилит. Пять минут, семь или десять - не так уж и принципиально: а зачем мне на этот процесс ффтыкать? Система многозадачная, однако - во время выполнения длительных фоновых задач можно заниматься другими делами. А т.к. за 5 секунд никогда не завершается - "длительная фоновая задача". Время выполнения которой не так уж критично в типовых случаях.

> зачем мне собирать уберядро с биотуалетом, если нужные
> модули я могу дособрать и позже, когда понадобятся?

Затем что мне совершенно не хочется засорять свой мозг составлением подробного списка оборудования которое может мне понадобиться.

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

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

> так ядро пожалуется, что видит грушу, а скушать не может. и какую именно.

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

> ну да, у тебя же ядро по часу собирается.

Ты несколко недооцениваешь восьмиядерники :-). Час оно будет собираться только с полным конфигом, всем дебагом и билдовкой deb-пакета. Ядро и модули будут готовы через ~15 минут максимум (наихучший случай - все объектники перестраиваются). Остальное время - создание из этого пакетов. Если оно вообще надо (как ты понимаешь, это имеет смысл далеко не всегда).

> а у меня — пять минут. с нуля. поэтому ты панически боишься пересобрать ядро,
> если что-то изменилось, а я — нет.

Cool story, bro. Правда, действительности не соответствует. И ты не понял. Я не боюсь его пересобирать, я хочу чтобы у меня в системе был нормальный человеческий plug-n-play. Установка дров в виндозно-досявом стиле меня несколько подзае... - пингвин может просто подхватить железку и не канифолить мне мозг. Это в моем понимании вкусная фича и я не собираюсь от нее отказываться, что-то зачем-то оптимизируя на системе где плюс-минус пара метров модулей вообще ничего не решали, так что я ничего не выиграл кроме неудобства и шанса обломаться лишний раз именно тогда когда мне работа некоей железки была нужна больше всего.

> вот и питонисты то же самое говорят. один-в-один. и чего ты их
> так не любишь-то? братья же практически.

Они не понимают что и как работает, поэтому они не могут распереться сделать быстро даже когда это становится надо. Так что не братья они мне. Я их подeлий типа yum наелся, добавки что-то не хочется. К тому же гонка как на пожар при разработке софта обеспечивает гунявое качество. Если уж рапидная разработка - так халтура везде, по всей площади. От архитектуры до багфиксинга.

> да, не каждый день. тем не менее, читаю. по необходимости, увы.

Ну вот я не испытываю никакого желания читать х86 код. Код х86-64 я со скрипом еще согласен почитать, хоть оно тоже не предел мечтаний. Но не такая лютая дрянь как 16- или 32-битный х86.

> бы, все опции задавал правильно.

В gcc4.8 для сей и плюсов - работает.

> я в потроха gcc лазил ещё во времена третьей версии, и
> что там происходит сейчас — представляю только в весьма общих чертах.

Gdc - это наверное хорошо, но крутые высокоуровневые навороты для меня как-то просто не востребованы.

> а если помочь компилятору интринсиками — то он будет в состоянии сгенерировать
> асм-код с использованием симда. «непортабельно» это потому, что «gcc-измы», видите ли.

Если уж gcc-измы, пусть тогда сразу asm и лопает. Потому что аккуратно выписанный человеком критичный к скорости блок кода - всяко лучше чем то что компилер генерит. А потом еще в оптимизаторе чего-нибудь поменяют, и оно стухнет по скорости в два раза. Придется лишний раз корпеть в ассемблерных дампах, изучая чего отломали в той или иной версии компилера. А оно кому-то надо - становиться экспертам по закидонам оптимизатора в зависимости от версии компилера? Проще 1 раз написать на асме вставку и более к этому безобразию не возвращаться вообще. А непортабельно еще и потому что simd есть не у любого проца. А даже там где и есть - достаточно разный бывает, да еще нескольких видов. Особенно здорово если код - generic и заранее неизвестно на каком именно проце его запустят и какой вариант там работает и какой работает лучше. По этому поводу особо крутые экспонаты делают рантайм детектирование фич проца и/или бенчмарк разных вариантов критичных кусков кода и выбор наилучшего.

> причём повторять это надо много раз, и радостно отлаживать кучу почти одинакового
> кода. ну нафиг.

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

> 32-битные программы на 64-битной системе таки работают медленней, чем на чистой 32-битной.

За счет чего? И какого порядка отличие? Впрочем, я при случае ребутнусь в 32-битную систему и посмотрю насколько оно быстрее.

> не так, чтобы сильно заметно, но. так и различие в бенче не ломающее.

Я почему-то так подозреваю что выигрыша явно не хватит чтобы побить тот дефолтный 64-битный бинарник. Есть у меня такое ощущение.

> что ты сделал со своим компилятором, что он такой сумасшедший-то? O_O

GCC 4.8, -O3 - изначально завинчен автором LZ4, его я не трогал. Я согласен что результат использования tune/arch довольно странный, но выглядит одинаково и в 32- и в 64-битных версиях. На первый взгляд, с тюнингом попросту генерится несколько более пухлый код. Возможно, компилер считал что так обычно быстрее. А в этом конкретном случае оказалось что нифига. Это уже надо рассматривать в виде асмовых портянок что там сгенерилось.

> не надо, просто сам посмотри. любопытно же.

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

> …нифига не оптимизировал код для 32-х бит на том же уровне, что и для 64-х бит? ;-)

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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



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

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