Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 4, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
Вышла Menuet OS 0.79 pre1
 Вышел в свет релиз 0.79 pre 1.Новый релиз содержит переработанный клавиатурный драйвер Mike.dld. Исходные коды подверглись небольшой очистке и в ядро добавлена очередь ожиданий. Релиз содержит приложения MFAR от Mike.dld, Calendar от Андрея Ивушкина, XTree от Павлушина Евгения, CPUID от Сергея Кузьмина, новую версию CPU от Mario 79. В состав входит новая версия FASM 1.57.1 Сообщает menuet.narod.ru |
Комментарии
| captain cobalt |24.03.2005 07:23 | |
 Зарегистрирован: 04.07.2004 21:44 | Культовая ОС.  Возможно, гораздо более культовая, чем любая из последнего опроса.  |
| Chizh |24.03.2005 13:26 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | Мне кажется только для русских она культовая. |
| ddc |24.03.2005 15:40 | |
 | Да и то не для всех. По-моему, писать 100%-ассемблерную ОС - это как рубашку только на одну пуговицу застёгивать. |
| podletz |24.03.2005 15:45 | |
 Зарегистрирован: 12.11.2004 08:30 | Хихи так там же написано на оф.сайте: hobby OS |
| ddc |25.03.2005 15:28 | |
| Ещё бы там что-то ещё написано было. Но я до сих пор не встречал людей, которые бы рубашку только на одну пуговицу застёгивали, потому что у них такое хобби... |
| captain cobalt |25.03.2005 16:56 | |
Зарегистрирован: 04.07.2004 21:44 | Ну почему обязательно нужно приплетать сюда пуговицы, и т. п. Неужели нельзя ясно выражать свои мысли в терминах предметной области? |
| captain cobalt |25.03.2005 17:01 | |
Зарегистрирован: 04.07.2004 21:44 | А если кто-нибудь скажет, что разрабатывать ось на С\С++ - это как ходить с расстёгнутой ширинкой? |
| Dron |25.03.2005 17:21 | |
 | Ну я например считаю что все писать на асме - глупость... Ибо 80% кода не влияют на производительность... Всмысле не так... 20% кода выполняются 80% времени. Так что оптимизировать все - необходимости нету... К тому же сами идеи, заложенные в MenuetOS - они какие-то ограниченные... несерьезно. |
| captain cobalt |25.03.2005 18:51 | |
Зарегистрирован: 04.07.2004 21:44 | С другой стороны, для 80% объёма кода, слабо влияющего на производительность, есть возможность оптимизировать его по размеру. Меньше размер -> меньше качать по интернету, меньше загружать в память при запуске, и даже более высокая скорость работы за счет разницы в скорости работы разных уровней иерархии памяти. 80% - приличная доля объёма. Скажем, если его удасться уменьшить в два раза, то объём всей системы уменьшится на 40% - прилично. А компиляторы языков высокого уровня практически не предоставляют возможности указать, какой код оптимизировать по скорости, а какой по размеру... Кроме того, на уровне машинно-ориентированного языка имеется возможность реализовать Run-Time Code Generation and Manipulation. |
| Chizh |25.03.2005 20:18 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | Когда компилятор оптимизирует по скорости, он также оптимизиует и по размеру, но только до предела, не ухудшаещего скорость исполнения. Поэтому в общем случае код достаточно компактный. Ещё есть момент глобального характера - даже если 80% кода слабо влияют на скорость, то всёравно в проектах критических по скорости, весь код должен быть скоростным. "Тут хочу скорости, а тут не хочу" - так не бывает. |
| Chizh |25.03.2005 20:26 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | И к стати на глаз определить медленные точки программы не такая простая задача, можно и наколоться. Более менее точно это определяется профайлером, но это только если есть подходящий профайлер, и есть время и желание с ним возиться. |
| captain cobalt |25.03.2005 20:52 | |
Зарегистрирован: 04.07.2004 21:44 | А Что значит "так не бывает"? А почему? |
| Chizh |25.03.2005 22:05 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | Потому что заданные характеристики обычно относятся ко всему проекту. Где-то важна скорость, где-то размер, где-то стабильность, где-то скорость разработки и т.д., а попытка получить сразу всё - это как погнаться за двумя зайцами, ни одного не поймаешь |
| Chizh |25.03.2005 22:09 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | "Тут хочу скорости, а тут не хочу" - это похоже раздвоение личности |
| captain cobalt |26.03.2005 12:42 | |
Зарегистрирован: 04.07.2004 21:44 | Означает ли это, что если цель проекта - максимальная производительность, то его необходимо разрабатывать ПОЛНОСТЬЮ на ассемблере? |
| vilmor |26.03.2005 13:24 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | Да, если вам не важно, что программа будет привязанной к одной платформе, содержать множество ошибок и не поддаваться разбору другими людьми, которые после вас будут заниматься её поддержкой и развитием. Да, если вам интереснее уделить больше времени оптимизации, пожертвовав временем на добавление новой полезной функциональности. Ибо время - всегда ограниченный ресурс. Если же программа пишется группой людей, и полностью на асме, то с большой вероятностью проведёте своё время вы весело, но без какой бы то ни было пользы для дела. |
| vilmor |26.03.2005 14:26 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | Ещё есть момент глобального характера - даже если 80% кода слабо влияют на скорость, то всёравно в проектах критических по скорости, весь код должен быть скоростным. "Тут хочу скорости, а тут не хочу" - так не бывает. В общем-то, бывает, поскольку не весь проект бывает критическим, а только его малая часть. Остальное оптимизировать особого смысла не имеет. Впрочем согласен, нет и особого смысла отказываться от оптимизации компилятором. Другое дело, для особо критичных участков кода следует применять так называемые "дорогие" оптимизации: вложенные inline-функции, разворачиваение циклов... А от этого код несколько разбухает, что в принципе не нужно для осталных 80-99% кода. Итог: к машинной оптимизации надо подходить дифференцированно PS: а по поводу оптимизации размера 80% кода, с использованием асма - см. предыдущее сообщение. |
| captain cobalt |26.03.2005 15:23 | |
Зарегистрирован: 04.07.2004 21:44 | А я тут вообще не при чём. Просто некоторые товарищи кидаются необоснованными заявлениями. |
| vilmor |26.03.2005 16:08 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | А я и не говорил ничего такого |
| Chizh |26.03.2005 16:36 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | "Означает ли это, что если цель проекта - максимальная производительность, то его необходимо разрабатывать ПОЛНОСТЬЮ на ассемблере?" - Нет конечно. Я к тому, что использовать ассемблер с целью выборочной (управляемой) оптимизации - плохая (даже можно сказать бессмысленная) идея. Обоснование я уже привёл. |
| Chizh |26.03.2005 16:44 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | "В общем-то, бывает, поскольку не весь проект бывает критическим, а только его малая часть" - Я такие части программы программы располагаю в разных файлах, и для отдельных файлов можно задаю разные ключи компиляции. Так вот и дифференцируется |
| Chizh |26.03.2005 16:44 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | слово "задаю" забыл стереть |
| vilmor |26.03.2005 17:30 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | Не совсем понял, что понимается под "использованием ассемблера с целью выборочной (управляемой) оптимизации". Если здесь под целью понимать настройку разных приоритетов оптимизации - это одно, и асм тут и правда не нужен. Но если подразумевается переписываение на асм наиболее критичных участков кода - это уже совсем другое, и этого иногда не удаётся избежать. Мне кажется, мы все здесь говорили немного о разных вещах. |
| Roman I Khimov |26.03.2005 22:49 | |
| Комментарии: 952 | Alexander написал(а) ... Я к тому, что использовать ассемблер с целью выборочной (управляемой) оптимизации - плохая (даже можно сказать бессмысленная) идея. Все зависит от постановки задачи. Если переносимость как задача не стоит, то использовать ассемблерные вставки в некоторых случаях имеет смысл. Даже если необходима переносимость, есть случаи, когда стоит переписать кусок кода на асме под разные процессоры. Объемные распределенные задачи от этого могут здорово выиграть (дурной пример - взлом RC5). Более наглядный пример - mplayer, в нем есть куски ассемблерного кода для MMX, 3DNow!, SSE - все это очень здорово работает, когда процессор держит. |
| Chizh |27.03.2005 18:47 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | Переносимость это такая же утопия, как GPL. |
| Chizh |27.03.2005 18:51 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | "Не совсем понял" - ну это когда речь шла об оптимизации в зависимости от критичности отдельных участков кода. А "переписываение на асм наиболее критичных участков кода" - не нужно никогда, всегда достаточно элементарных ассемблерных вставок. |
| vilmor |28.03.2005 00:05 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | "переписываение на асм наиболее критичных участков кода" - не нужно никогда, всегда достаточно элементарных ассемблерных вставок. При оптимизации видео кодеков, например, приходится переписывать на асм целые функции, причём довольно большие. Это - факт. Переносимость это такая же утопия, как GPL. Люди пишут переносимые программы. Это тоже факт. Некоторые выигрывают иски против компаний, нарушающих GPL. И это факт. Вот поэтому я бы никогда не стал делать такие заявления. |
| Chizh |28.03.2005 01:31 | |
| Комментарии: 85 Зарегистрирован: 13.09.2004 18:42 | Целая песочница фактов, это верно |
| vilmor |28.03.2005 08:25 | |
| Комментарии: 27 Зарегистрирован: 29.10.2004 17:09 | осталось только кому-то сделать выводы |
| Dron |28.03.2005 10:27 | |
| Я тоже считаю что переносимость - это зло! Меня тошнит от configure. Ж) Но если смотреть на вещи объективно... gcc - очень хороший компилятор... как-ты не лезь из кожи - в два раза программу ты не ускоришь... ну в лучшем случае выиграешь процентов 20 производительности... Главное не потратить на программирование в два раза больше времени... ну хотя когда разговор идет об увлечениях - разговор о времени не уместен. Про непродуманность - я имел в виду следующее... Изначально в MenuetOS заложено то, что один процесс не можешь использовать больше 4 мег памяти... и всего не больше 16 процессов... мне кажется это ужасно скудные условия. А переносимость - зло однозначно! Даешь скоростную одноплатформенность!!! |
| Dreamer |28.03.2005 11:15 | |
 Зарегистрирован: 04.07.2004 14:01 | Да чего вы вообще спорите? Факт тот, что Menuet - это просто игрушка, красивая демка, если хотите. Если кто не читал статейку некогда ярого разработчика MeOS (кстати, человека, о "профессионализме" которого сомневаться не приходится), заходите: www.meosfiles.narod.ru, файл Trans_Statiya_MeOS_full_version.pdf (название увидите). |
Комментарии доступны только авторизованным пользователям, авторизуйтесь или зарегистрируйтесь на сайте здесь