Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>FUSE — это сравнительно недавнее появление, да еще и специфичное для >> C>нескольких ОС. Классическая Unix-модель не предлагает никаких средств >> C>расширения FS кроме именованых пайпов/сокетов. >> Кто вам такое сказал? >> vnode/vfs в UNIX давно придумали? C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах C>добавить в ядро свой модуль и подмонтировать свою FS?
Да. Только ядро будет работать с твоим модулем через FUSE (см .схему работы в предыдущем посте).
Если нужно исключить FUSE вообще, то придётся работать через sudo (аналог run as в Windows) для выполнения административных задач по подключению модуля к ядру.
Хотя на разных этапах загрузки можно что угодно сделать в UNIX. Например, во FreeBSD можно вручную на лету подгружать новые ядра и модули на этапе начальной загрузки системы. В Solaris собственный механизм управления загрузкой (там вообще машина может не выключаться). root, как администратор, может дать специальные привелегии пользователям и ещё больше: быть root'ами в собственных операционных окружениях (например, клетка Jail во FreeBSD).
iZEN wrote: > C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах > C>добавить в ядро свой модуль и подмонтировать свою FS? > Да. Только ядро будет работать с твоим модулем через FUSE (см .схему > работы в предыдущем посте).
Я это прекрасно понимаю. Все дело в том, что FUSE — это совсем недавняя
и непортабельная вещь.
> Если нужно исключить FUSE вообще, то придётся работать через sudo > (аналог run as в Windows) для выполнения административных задач по > подключению модуля к ядру.
Несекьюрно и совсем не в духе Unix. Проблема в том, что файл в юниксах —
это абстракция, но системная абстракция, а не пользовательского
уровня.
И если я хочу написать портируемую программу — то могу рассчитывать
только на пайпы/сокеты и временные файлы.
Здравствуйте, Cyberax, Вы писали:
C>iZEN wrote: >> C>Вопрос на засыпку: я могу из под обычного пользователя в юниксах >> C>добавить в ядро свой модуль и подмонтировать свою FS? >> Да. Только ядро будет работать с твоим модулем через FUSE (см .схему >> работы в предыдущем посте). C>Я это прекрасно понимаю. Все дело в том, что FUSE — это совсем недавняя C>и непортабельная вещь.
>> Если нужно исключить FUSE вообще, то придётся работать через sudo >> (аналог run as в Windows) для выполнения административных задач по >> подключению модуля к ядру. C>Несекьюрно и совсем не в духе Unix. Проблема в том, что файл в юниксах — C>это абстракция, но системная абстракция, а не пользовательского C>уровня. FUSE (Filesystem in USErspace) была частью проекта AFVS. Сейчас код выделен в отдельный проект и входит в ядро Linux (старое 2.4 и новое 2.6) и включён в порты FreeBSD 6.x (текущие ветки) and 7.x (экспериментальная ветка).
Представляет собой абстрактный драйвер уровня ядра, который может работать с "драйверами" непривилегированных пользователей (уровня userland). То есть Вы пишете свой "драйвер" и спокойно запускаете его в адресном пространстве пользователя. FUSE с помощью механизма обратных вызовов делает прозрачным работу ядра с вашей собственной файловой системой как с нативной (Ext2fs, Ufs, XFS и т.д.). Это гораздо быстрее, чем с помощью пайпов и тем более сокетов, так как здесь используются вызовы функций, а не пакетные протоколы. C>И если я хочу написать портируемую программу — то могу рассчитывать C>только на пайпы/сокеты и временные файлы. FUSE работает на: http://fuse.sourceforge.net/wiki/index.php/OperatingSystems (Linux и FreeBSD)
Учитывая, что исходный код открыт, можно надеяться, что будет портирован на более экзотические OS.
(Пример из 100 строк на Си для драйвера "Hello World" разве не впечатляет?)
iZEN wrote: > FUSE <http://fuse.sourceforge.net/> (Filesystem in USErspace) была > частью проекта AFVS.
Не надо мне это 10 раз повторять — я прекрасно знаю что такое FUSE.
> C>И если я хочу написать портируемую программу — то могу рассчитывать > C>только на пайпы/сокеты и временные файлы. > FUSE <http://fuse.sourceforge.net/> работает на: > http://fuse.sourceforge.net/wiki/index.php/OperatingSystems (Linux и > FreeBSD) > Учитывая, что исходный код открыт, можно надеяться, что будет портирован > на более экзотические OS.
Например, мне важны: Solaris, HP-UX, Cygwin, FreeBSD старых версий, QNX,
Windows.
На многих из них FUSE не будет очень долго. Кроме того, FUSE не входит в
LSB (и соответствующий ISO-стандарт).
> (Пример из 100 строк на Си для драйвера "Hello World" разве не впечатляет?)
Посмотрите Plan 9
iZEN wrote:
> Выделенное — чистый, незамутнённый бред.
У меня такое же впечатление сложилось... Есть такие люди, которые уверены: Украина — родина слонов.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Вот именно это и важно. У меня при компиляции происходит обращение C>примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении C>- это 10 секунд в сумме.
Можно узнать сколько времени занимает процесс компиляции?
C>А так как инкрементальную компиляцию я запускаю раз 100 в день — то C>общая сумма сэкономленного времени получается очень неплохой.
Твои 10 гипотетические секунди если и появляются то, только если речь идет о перекомпиляции всего проекта. А при инкрементальной компиляции их проросту не будет. Так что твоя экономия это секунд 40 растянутые на весь день. Ты реально каждый час прошляпливашь больше.
Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее.
А если выбросись свой С++ то вообще получишь возможность резко ускорить процпсс компляции.
Теперь о том почему твои 10 секунд гипотетические а не реальный.
Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов.
Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды.
У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Вот именно это и важно. У меня при компиляции происходит обращение C>>примерно к 10000 файлов. Сэкономленная миллисекунда на каждом обращении C>>- это 10 секунд в сумме. VD>Можно узнать сколько времени занимает процесс компиляции?
Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые надо перекомпилировать, а пересвязать исполняемый файл.
VD>Твои 10 гипотетические секунди если и появляются то, только если речь идет о перекомпиляции всего проекта. А при инкрементальной компиляции их проросту не будет. Так что твоя экономия это секунд 40 растянутые на весь день. Ты реально каждый час прошляпливашь больше.
Блин. Я же написал при инкрементальной компиляции. Секунд 8-10 занимает именно сканирование зависимостей.
На Линуксе на моей машине для того же проекта — около секунды.
VD>Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее.
Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов.
VD>А если выбросись свой С++ то вообще получишь возможность резко ускорить процпсс компляции.
Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — те же 10 секунд на сканирование зависимостей.
VD>Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов. VD>Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды.
Ну напиши простенький тест, который откроет эти файлы и прочтет их содержимое. Увидишь о чем я говорю.
VD>У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения.
Да, да. Иду вызывать экзорциста, чтобы изгнал дьявола из моего компьютера.
VladD2 wrote: > У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не > более чем под больного воображения.
"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге
Windows: 1241 папок и 11163 файлов.
На разбросаных по всей FS include-файлах, половина которых evict'ится из
кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS.
Кстати, если тебе так нравится NTFS и Windows, то расскажи как сделать
аналог Линуксового laptop mode?
В laptop mode отключается винчестер (совсем) и работа идет только
через файловый кэш, и изменения в FS также накапливаются в памяти и
сбрасываются на диск через какой-то интервал (у меня стоит 15 минут).
Так как обычно работа идет только с определенным набором файлов — то
диск включается, фактически, только во время commit'ов изменений.
Здравствуйте, Cyberax, Вы писали:
C>Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые надо перекомпилировать, а пересвязать исполняемый файл.
Понятно, значит 5 секунд из которых 10 занимает обращение к файлам.
Хорошо излагает — собака. Учитесь Киса... (с)
C>Блин. Я же написал при инкрементальной компиляции. Секунд 8-10 занимает именно сканирование зависимостей.
Не выдумывай.
C>На Линуксе на моей машине для того же проекта — около секунды.
Обнови значит драйверы. Или разберись с тем что у тебя конфигурации винды не так.
VD>>Потом скорость компиляции куда больше зависит от компилятора. Так MS VS работает куда как быстрее GCC. Стало быть воспользовавшись Виндовс ты свой проект скомпилируешь банально быстрее. C>Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов.
И как ты сравнивашь вайловые системы на VC c GCC?
C>Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — те же 10 секунд на сканирование зависимостей.
Ищи проблемы в дровах или каких-то левых настройках сделанных тобой лично.
VD>>Только что зашел на свою рабочую машину (ишу с ноута) и провел слерственный экспермент. У меня есть каталог с RSDN Offline (переведенные в html сообщения с форумов РСДН). В каталоге содержится где-то 22.8 тысяч файлов. VD>>Первое нажатие энтера в Винкомандере заставляет машину задуматься где-то на 2-3 секунды. После того как MFT кэшируется открытие каталога занимает менее секунды. C>Ну напиши простенький тест, который откроет эти файлы и прочтет их содержимое. Увидишь о чем я говорю.
А зачем читать содержимое? Ты ведь об инкрементальной компиляции говоришь. Я правильно понял?
Полная компиляция проекта из 10К С++-файлов занимает поди пол часа или даже болше. Так? На них ни 10 ни 20 секунд значения иметь не убдут.
Я же тебе написал у меня открывается каталог. При этом считываются все характеристики файлов. В том числе и дата последнего изменения. Именно этим и ползуются все системы сборки. Занимает это не более секунды в Винкомандере.
Ну, ладно, сделаем простой эксперемент.
Вот простой тест эмулирующих поведение IDE:
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Stopwatch timer = Stopwatch.StartNew();
string[] files = Directory.GetFiles(@"F:\Backup\rsdn.ru\WWW\Offline\Forum");
DateTime oldestTime = DateTime.Now;
foreach (string file in files)
{
DateTime dt = File.GetLastWriteTime(file);
oldestTime = dt > oldestTime ? dt : oldestTime;
}
Console.WriteLine(timer.Elapsed);
Console.WriteLine("В каталоге " + files.Length + " файлов.");
Console.WriteLine("Самый старый файл обновлялся " + oldestTime);
}
}
}
А вот его результат:
00:00:00.8381922
В каталоге 22824 файлов.
Самый старый файл обновлялся 03.07.2006 22:35:43
Файлов в двое больше чем ты описывашь. Код на дотнете и далек от оптимального. Но результат как-то совсем не подтверждает твоих слов.
В общем, или ты мягко говоря говоришь не правду, или у тебя какие-то локальные проблемы на машине, а ты свой опыт обобщаешь на всех окуражающих.
Кстати, заметь, у меня на машине никаких специальных настроект (типо отключения чего-то там не быстрого) не проводилось. Это штатная ХРюша.
VD>>У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не более чем под больного воображения. C>Да, да. Иду вызывать экзорциста, чтобы изгнал дьявола из моего компьютера.
Вызывай не вызвай. Но проблема в твоих личных руках. Ты просто не сумел добиться от своей машины нормальной работы. Или наоборот наставил разного дерьма которое и тормозит машину.
Конфигурация то у машины какая?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> У тебя файлов в два раза меньше, так что расказы про твои 10 секунд не >> более чем под больного воображения. C>"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге C>Windows: 1241 папок и 11163 файлов.
Серьезно? Ну, тогда перестать мошейничать и убери опцию "/Q". Сразу станет пошустрее. У меня в виндовс 23К файлов и тест отрабатывает быстрее чем за секунду (когда информация закэширована). На ноуте где-то 17К файлов и тоже меньше секунды.
В общем, сдается мне, что дело не в машине. А в чьей-то честности.
Что можно доказать откровенными подлогами?
Ни одна система сборки проектов не занимается фигней вроде сбора информации о владельцах файлов. И уж темболее не будет превращать все это в текст и записывать в файл.
C>На разбросаных по всей FS include-файлах, половина которых evict'ится из C>кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS.
У тебя же была инкрементальная компиляция? Поди еще и прекомпилируемые заголовки включены?
Как же выходит, что нужно читать все иклюды?
В общем, заврался ты совсем. Извини, но мне уже надоело тратить на тебя время.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>"dir /Q /4 /S WINDOWS >nul" у меня работает 6 секунд. В каталоге > C>Windows: 1241 папок и 11163 файлов. > Серьезно? Ну, тогда перестать *мошейничать* и убери опцию "/Q". Сразу > станет пошустрее. У меня в виндовс 23К файлов и тест отрабатывает > быстрее чем за секунду (когда информация закэширована). На ноуте где-то > 17К файлов и тоже меньше секунды.
BJam внутри делает проверку, что файл можно открыть — это примерно
аналогично опции "/Q" (я как раз пытался ускорить BJam, заменяя открытие
файла на проверку ACLей).
Не веришь — смотри файл headers.c и hcache.c из исходников BJam.
> Ни одна система сборки проектов не занимается фигней вроде сбора > информации о владельцах файлов. И уж темболее не будет превращать все > это в текст и записывать в файл.
Вывод в текстовом файл — копейки по времени.
> C>На разбросаных по всей FS include-файлах, половина которых evict'ится из > C>кэша между компиляциями — 10 секунд вполне нормальная цифра для NTFS. > У тебя же была инкрементальная компиляция? Поди еще и прекомпилируемые > заголовки включены? Как же выходит, что нужно читать все иклюды?
А как еще определить, что именно нужно перекомпилировать?
Например, если я поменяю файл boost/filesystem/fstream.hpp, то нужно
будет перестроить половину проектов (включая и подключенный
boost::filesystem).
VladD2 wrote:
> В каталоге 22824 файлов. > Самый старый файл обновлялся 03.07.2006 22:35:43
Плоский каталог обычно обрабатывается быстро. Исходники же имеют ветвистую структуру. Создай дерево 5*5 каталогов с 5
файлами в листьях. Будет 15625 файлов. На винде такая хрень жутко тормозит, в линухе такое обрабатывается также как и
плоский каталог. (Естественно это верно при первом обращении, а не из дисковых кэшей).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
VladD2 wrote: > C>Так же порядка 5-10 секунд. Обычно меняется один-два файла, которые > надо перекомпилировать, а пересвязать исполняемый файл. > Понятно, значит 5 секунд из которых 10 занимает обращение к файлам.
5-10 секунд занимает непосредственно сама компиляция (вызов cl+link),
после того как граф зависимостей уже построен.
> C>На Линуксе на моей машине для того же проекта — около секунды. > Обнови значит драйверы. Или разберись с тем что у тебя конфигурации > винды не так.
Драйверы чего обновлять? Все как поставилось с родного
установчного диска — так и стоит.
Конфигурация Винды и так уже накручена: отключены 8.3-имена, поставлены
настройки "большого кэша", отключено отслеживание времени последнего
доступа к файлам.
> C>Обычно как раз MSVC и компилирую, а сейчас еще на DMC подсел — он > компилирует примерно в 5-10 раз быстре MSVC для отладочных билдов. > И как ты сравнивашь вайловые системы на VC c GCC?
А это неважно. В сканировании зависимостей компилятор не участвует. Вся
разница может быть только в разном наборе sysinclude'ов (которые не
сканируются) или в разном наборе файлов из-за условной компиляции (на
пару файлов разница).
> C>Ant на Java-проекте из 18000 файлов тоже весьма заметно задумывается — > те же 10 секунд на сканирование зависимостей. > Ищи проблемы в дровах или каких-то левых настройках сделанных тобой лично.
На всех остальных машинах у нас в оффисе — примерно так же с коррекцией
на мощность процессора/скорость дисков.
> C>Ну напиши простенький тест, который откроет эти файлы и прочтет их > содержимое. Увидишь о чем я говорю. > А зачем читать содержимое? Ты ведь об инкрементальной компиляции > говоришь. Я правильно понял?
Для инкрементальной компиляции зависимости все равно нужно отслеживать.
Можешь спросить у eao197 (автор еще одной build-системы), если мне не
веришь.
> Полная компиляция проекта из 10К С++-файлов занимает поди пол часа или > даже болше. Так? На них ни 10 ни 20 секунд значения иметь не убдут.
Полная компиляция делается раз в день, там действительно не важны 10-20
секунд.
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Stopwatch timer = Stopwatch.StartNew();
string[] files = Directory.GetFiles(@"c:/windows/system32");
DateTime oldestTime = DateTime.Now;
foreach (string file in files)
{
DateTime dt = File.GetLastWriteTime(file);
try
{
FileStream fl = File.OpenRead(file);
fl.Dispose();
} catch (IOException ex) { }
oldestTime = dt > oldestTime ? dt : oldestTime;
}
Console.WriteLine(timer.Elapsed);
Console.WriteLine("В каталоге " + files.Length + " файлов.");
Console.WriteLine("Самый старый файл обновлялся " +
oldestTime);
int a = 0;
}
}
}
> А вот его результат: > 00:00:00.8381922 > В каталоге 22824 файлов. > Самый старый файл обновлялся 03.07.2006 22:35:43
Машина — двухпроцессорный AMD64 с 4Гб памяти (нет у меня FW2 на моем
компьютере) и отключенными редиректором FS.
Теперь мой ход:
import os
DIR = '/var/lib/vpopmail/[хрумс]/Maildir/cur'
maxsize = 0
for f in os.listdir(DIR):
path = os.path.join(DIR, f)
fl = open(path,"rb")
fl.close()
sz = os.path.getsize(path)
if sz>maxsize: maxsize=sz
print"The biggest readable file is %d bytes." % maxsize
Результат:
root@scblinux:~/test-sp# time python test.py
The biggest readable file is 33748150 bytes.
real 0m0.118s
user 0m0.064s
sys 0m0.052s
root@scblinux:~/test-sp# ls /var/lib/vpopmail/[хрумс]/Maildir/cur | wc
9062 9062 244345
root@scblinux:~/test-sp# cat /proc/cpuinfo | grep "model name"
model name : AMD Athlon(tm) 64 Processor 3000+
root@scblinux:~/test-sp# cat /etc/issue.net
Debian GNU/Linux testing/unstable
root@scblinux:~/test-sp# cat /etc/fstab | grep "/ "
/dev/md2 / reiserfs notail 0 1
Cyberax wrote: > E:\Users\Cyberax\TestSpeed\TestSpeed\bin\x64\Debug>TestSpeed.exe > 00:00:02.1704177 > ? ???????? 5680 ??????. > ????? ?????? ???? ?????????? 7/4/2006 1:07:50 PM > Машина — двухпроцессорный AMD64 с 4Гб памяти (нет у меня FW2 на моем > компьютере) и отключенными редиректором FS.
Стоп! Числа могут быть неверными — машина могла быть под нагрузкой.
Правильные числа будут вечером, когда машину освободят.
AndrewVK wrote: >> > работают все доступные среды. И оно логично. > C>Можно пример таких сред? Я знаю, пожалуй, только OmniCore. > http://www.jcreator.com
И за ЭТО еще хотят денег? Нда...
Ну ладно, есть две современных Windows-only Java IDE.
AndrewVK wrote: > C>Ну ладно, есть две современных Windows-only Java IDE. > Заметь, эти ссылки тебе накидали люди, которые на Java не программируют.
Я на Java программирую, но искать себе геммороя в виде Windows-only IDE?
Нет уж...
