LINUX.ORG.RU

Поиск по сайту

 
Раздел:
Всего найдено 5395 результатов, показаны 25

Тест на ЛОРовца

Вообще, ЛОР немного почитал -- как лет на 10 помолодел... Те же срачи, те же упоротые анонимусы (увы, далеко не везде) сносно говорящие на русском; та же школота ЛОРовским миром правит (Макском, извини, но ты мне сам говорил, что я могу в любой момент вернуться и вас всех по критиковать...). Вообще, самое прикольное, что ЛОР -- жив...

Die-Hard ★★★★★
()

Тест на ЛОРовца

Привет, Только что опять с UVV и его второй половинкой в кабачке посидели, и они мне этот тред показали. Я вообще поражен -- Dimez, как ты меня вычислил? Мы с тобой пару раз по телефону говорили, и больше никакого личного общения не было жешь! Даже на ЛОР зашёл, чтобы прокомментировать, первый раз лет за много... Вообще, не совсем удачная фотка -- я не всегда такой пьяный... :)

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

> Зачем? Моя ситуация была такая: есть N процессоров и N процессов. Надо максимально эффактивно реализовать IPC. Очевидное решение -- юзерспейсные спинлоки.

Die-Hard ★★★★★
()

x86-64, очистить кэш

Спасибо всем ответившим! > Используй команды movnt*. Ну, это, типа не из Це вообще писАть... Мне хочется такого (в идеале): есть адрес (виртуалный), валидный но "грязный" в кэше, записанный из моей любимой Це - программы, и мне надо так инвалидировать линейку кэша с этим адресом, чтобы он при этом в память не ушёл. Подробнее начальная проблема: Я пишу подряд в ячейки памяти, но нужны они мне только изредка. БОльшая часть записанных данных больше не пригодиться, и я знаю, какие именно. К сожалению, по техническим причинам я не могу реюзать эти адреса. Я не хочу при этом пользоваться наворотами, препятствующими загрязнению кыша; он загрязняется, гад! Вопрос -- можно ли его "почистить"?

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

> Хех, так самое-то интересное - это FUTEX_WAIT и FUTEX_WAKE. volatile в шаред мемори вместо со спинлоками и без всяких man 7 futex можно использовать. Конечно, я про это и говорю. В NTPL POSIX мутексах всё это и сделано во взаимодействии с ядрёным футекс_колл. Они без нужды в ядре не уснут... Согласись, pthread семантика не сложнее TCP/IP...

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

>> Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись) > Эээээ... Ты уверен? man 7 futex (be not confused by man 2 futex)

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

> ...нужно использовать futex'ы, а это опять ядро ;) ... Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись), в отличие от TCP/IP, который проходит через ядро, с двойной буферизацией и созданием / очисткой кучи очередей.

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

>> а кто сделает теперь какой-нить пример локального IPC без участия ядра? > Никто не сделает. Я делал...

Die-Hard ★★★★★
()

Выпущен клиент для POHMELFS

>> Вообще, я не верю, что один человек сможет написать нечто достойное > Emacs? 8-/? Emacs с самого начала разрабатывался довольно большой командой из MIT AI Lab, а потом в нем поучаствовали тысячи человек, соорудивших много форков. Да, дядька Столлман затеял его делать и заложил основные идеи, и то не один, но народу там сразу хватало.

Die-Hard ★★★★★
()

Выпущен клиент для POHMELFS

> ...Это в 1.8 будет, но чтото долго оно, задерживается. IMHO этого не надо. FS -- не БД. На самом деле ИМХО распределённые "reliable" файлухи с транзакциями вообще не нужны. Вместо них нужны всякие распределённые БД, Берклиевские Хэши и прочие Ораклы. А распределённые файлухи нужны исключительно для скрэтчей для HPC(High-performance computing).

Die-Hard ★★★★★
()

[Q] TCP/IP as an internal application IPC

> Все это собирается в _один_бинарник_. ... используя TCP/IP, как средство внутреннего IPC, не изобретая бажных велосипедов. ... количество коротких (макс. 4кб) сообшений может достигать пика в 2000/сек... :-) Посмеялся, спасибо!

Die-Hard ★★★★★
()

Выпущен клиент для POHMELFS

>> Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше. > Трудно сказать. Для каких-то операций наверное будет как для write-through, для каких-то быстрее (где редко нужно флашить на сервер). Наверное для случая непрерывной записи в один и тот же файл кучей клиентов будет медленнее. Вот, боюсь, по-любому будет медленнее... На самом деле, в распределенных файлухах, как я понял (только не принимайте мои слова слишком близко к сердцу -- я решительно не спец и вполне могу неверно интерпретировать слова, что мне говорят специалисты, когда я им жалуюсь на то, что моя аппликуха тормозит на их супре-пупер кластере), не в хэшах проблема, отнюдь... Мне приходится работать на двух сравнительно больших (тысячи корок) кластерах с Ластрой. Разница между ними в том, что один имеет достаточное кол-во железяк для того, чтобы хранить метаданные, и динамическую маршрутизацию сетки (КвадриксНет2), а в другом оно

Die-Hard ★★★★★
()

Демонизация скрипта

> Во FreeBSD есть команда daemon(8), под Linux мне всегда ее не хватало. Отвязывает от терминала, делает chdir("/"), stdout в /dev/null, умеет pidfile - сказка. Ну, Линуксовая setsid(8) позволяет сделать всё это и более (в кооперации с командами оболочки), см. выше. Но обе они -- не ПОЗИКСные.

Die-Hard ★★★★★
()

Выпущен клиент для POHMELFS

> У люстры (как и у nfs) write-through кэш, а не грамотный write-back, что равносильно тому, что кэша нет вообще - вот была главная точка зрения автора. Ну, как-то мне эта точка зрения не импонирует. Вообще ИМХО "грамотный write-back кэш" для распределённой файлухи сделать невозможно. Работать-то оно, может, и будет, но тормозов добавит больше. Впрочем, я не специалист по FS. С Ластрой я работаю, и вижу, что основная проблема там в том, что она слишком сложная. Если ещё наворотов добавить то, боюсь, вообще не взлетит...

Die-Hard ★★★★★
()

[C/C++] Атомарные переменные

> что конкретно подразумевается под фьютексами: общая концепция man 7 futex или конкретный API man 2 futex Концепция, конечно. API в pthread сидит.

Die-Hard ★★★★★
()

Демонизация скрипта

>>> nohup ./script.sh & > пасиба, помогло)) Это не настоящая "демонизация": у процесса остался терминал; группа, сессия и ppid остались оболочечные. Могут быть проблемы, например, если зашёл по ssh, то не выйдешь -- этот дурак будет ждать, пока все его порождения не закроют терминал. Вот бронебойный способ, настояший демон получается: setsid ./script.sh >/dev/null 2>&1 </dev/null (перенаправления под башем показаны)

Die-Hard ★★★★★
()

Выпущен клиент для POHMELFS

Почитал на опеннете обсуждение POHMELFS -- не уверен, но похоже на очередной велосипед. Есть же Lustre, которая все это с лихвой перекрывает. Автор пеняет ей на то, что Сантехники её неправильно развивают и в конце концов погубят, но как-то неубедительно... Вообще, я не верю, что один человек сможет написать нечто достойное. Надежда на то, что коммьюнити поддержит, пока оно не слишком разрослось и обозримо -- посмотрим...

Die-Hard ★★★★★
()

кэши интела

Мне тоже интересно стало... Я, возможно, не прав, но, сдаётся мне, что концепция столь явного маппинга всех кышей на виртуальные и физические несколько устарела? Я к тому, что сейчас TLB многоуровневая и тесно завязана на конкретные кыши и (многоуровневые же) бранч предикторы, особенно в свете возрождения Nehalem'ами SMT ("гипертединга")...

Die-Hard ★★★★★
()

[C/C++] Атомарные переменные

> futex (man 2 futex) сразу уходит в ядро Нет. man 2 futex :-) Hint: "futex - Fast Userspace Locking system call" Кстати, полезно сделать RTFM насчёт man 4 futex ;)

Die-Hard ★★★★★
()

[C/C++] Атомарные переменные

> Зачем тогда писать в него такой большой пост? Судя по твоему ответу, ты тоже мало что понял ;) > Атомарные операции есть в builtin-ах, gcc. В других компиляторах они тоже могут быть, но о переносимости придётся позаботиться руками (если надо). Вообще-то, именно это я и написАл. А чего я не понял -- топикстартер изначально спрашивал про атомарные типы, потом обсуждение незаметно перешло на атомарные операции. Между тем, атомарных типов -- сколько угдно (де-факто для почти всех компиляторы на почти всех платформах можно смело полагать любой целый тип атомарным), а атомарных операций нет ни в стандарте, ни в "стандарте де-факто". Даже интринсики у одного и того же компилятора могут различаться на разных платформах. Проще всего заюзать готовую библиотеку -- я ссылку привёл. > Атомарные операции на мьютексах -- результат фатального и необратимого поражения головного мозга. Во-первых, обкладка некими блокировками атомарных операций -- единственный способ, если оставаться в рамках POSIX'а.

Die-Hard ★★★★★
()

Время поиска 19 ms, время БД 1 ms