DragonFly BSD 2.4

> А сам-то стандарт тот читал?

От корки до корки не осилил. Значительную часть - прочел.

> Твой код про 65536 поросту неверен(с точки зрения того, чего ты ожидаешь).

А чего я ожидаю? Расскажи :)

>А чего я ожидаю? Расскажи :)

Приводишь результат сложения к int, а ожидаешь получить uint16_t

> Дурачок, для таких как ты убогих даже вика пишет: http://en.wikipedia.org/wiki/Integer_overflow - In the C programming language, signed integer overflow causes undefined behavior, while unsigned integer overflow causes the number to be reduced modulo a power of two, meaning that unsigned integers "wrap around" on overflow.

Ну и кто тебе виноват что ты сам не осилил это прочитать? И ещё жалуешься.

> Но ты, кончено, сейчас продолжишь свой скулеж про каноничность VS и про волшебные патчи в альтлинуксе. Поэтому отсылаю тебя к ISO/IEC 9899:TC2 раздел 3.4.3 абзац 3.

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

> Приводишь результат сложения к int

Результат сложения я явно привожу к int с единственной целью: чтобы ни у кого не возникало сомнений в соответствии между printf fomant string и фактически переданными в printf аргументами.

> а ожидаешь получить uint16_t

4.2 Я ведь рядом с кодом написал, операнды будут подвергнуты integer promotion. Никакого uint16_t ожидать не приходится.

>> Приводишь результат сложения к int

>Результат сложения я явно привожу к int с единственной целью: чтобы ни >у кого не возникало сомнений в соответствии между printf fomant string >и фактически переданными в printf аргументами.

Я выше писал как правильно: (int) ((uint16_t) (a+b)). Либо замени в своем примере объявление "c" как int, и тогда разультаты будут одинаковы :)
Ну и строго говоря, приведение типа и форматирование для printf должны быть беззнаковыми, иначе например на таржете с 16-битным int-ом опять у тебя будут приключения(но для говнокода, где ожидаемый результат всегда 0 это не важно)

>4.2 Я ведь рядом с кодом написал, операнды будут подвергнуты integer promotion. Никакого uint16_t ожидать не приходится.

И все делается в соответсвии с тем, как ты написал.

> Ну и кто тебе виноват что ты сам не осилил это прочитать? И ещё жалуешься.

Нет, это не я не осилил прочитать. Это _ты_ час назад заявлял, что разработчики gcc не осилили стандарт, потому что в альте и в вежуальнике все работает: http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4075609 Сперва ты дерзил, а теперь пытаешься вот так вот беспонтово съехать с базара. Знаешь, почему так получается? Потому, что ты - лично ты - опущенное говно. Ты ничего не достиг, ничего не умеешь, у тебя нет подруг, и твой беспонтовый троллинг на ЛОРе для тебя словно свет в окошке. Мой тебе совет - исчезни отсюда по-тихому, не дожидайся дальнейших унижений.

>> что системный вызов write не может завершиться после записи только части буффера;

как все запущено

Судя по всему, ты ничего не умеешь и самое натуральное г***но которое всю свою жизнь провело созерцая небо в решетку, нечего строить из себя программиста, мозгов не хватает =)

о! давно хотел что-нибудь очень гиковское. на грани матана и кибер-панка ))

Поправьте раздел.

>Основная файловая система - HAMMER http://www.dragonflybsd.org/hammer/

Идём на сайт, читаем анонс и ... "Unless your virtual hard disk is 50G or larger we recommend doing a UFS install and not the default HAMMER install. We also recommend installing from the CD ISO and not the DVD ISO. The DVD ISO HAMMER install has bugs (see Known Release Issues)."

гы гы

> Я выше писал как правильно: (int) ((uint16_t) (a+b)).

А я об этом писал еще рядом с кодом:

Не скастовал программист сумму вручную к uint16_t - сам дурак.

В общем, твои ко мне претензии http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4076040 не обоснованы. Ты просто невнимательно читаешь :)

Перечеитал, но все равно не очень понятно, что тебя в данном конкретном случае не устраивает.
То, что
uint16_t c = a + b;
и
int c = a + b;
дают разные результаты тебя не смущает, а присутствие в printf неявной переменной типа int - да?

>Ни один из них не избегает главной проблемы Си: нетривиальной, требующей экспертных знаний, семантики.

Если для вас C так нетривиален, то вам только биореактор поможет. C прост, удобен и лаконичен.

POSIX тоже, а так таких как вы мыслителей (а-ля создадим свою ОС с своим АПИ необычным, и будет нам счастье) - полно, только вот вопрос - сколько пилить будете ? Написать ведро (особенно если монолит) дело еще посильное (только на фик никому не нужное), свои нативные либы - ибо свое API ну допустим тоже не сложно, а дальше? свои тулзы, кучу ПО и прочего поделия - это уже не осилить, портировать никак - нет C и POSIX - пейшите свое, и главное даже если будет что то - то еще неизвестно куда закапывать поделку, ибо можете просрать в чем угодно от стабильности до производительности и масштабируемости.

привет.

>Ага, так что у ребят в ядре есть на выбор 2 варианта: >1. отложить запись на по-дольше, и получить немеряные лаги в >sqlite/firefox/whatever

деточка полоумная, ты тут о чем вообще? какие лаги ? ничего что твои поделки типа фирефокса читают не напрямую из диска - а из page cache файловой системы. Ты вестимо не то чне не инженер,даже наверное не быдлокодер(хотя ... быдлокодеры они такие быдлокодеры что не знают как система работает).

>2. сделать запись по-скорее, и получить срыв оптимизаций дискового IO

ну читай выше.

> Один только strict pointer aliasing чего стОит! Глюкодром.....

-fno-strict-aliasing, не?

А вообще -Wstrict-overflow=5 -Wstrict-aliasing=3 А еще лучше -Wall -Wextra :-)

Кстати, если вспомнить, что некоторые архитектуры требуют разное выравнивание для типов разной длины, то становится ясно, почему нельзя (double*) приводить к (int*) — легко получится AC#. Машинно-зависимая вещь, как-никак.

> все равно цикл останется вечным.

Опять же, если программист хочет использовать машинно-зависимые вещи — это его головная боль, ибо эти вещи, по большому счету, непереносимы. И да, TDD.

> ISO/IEC 9899:TC2

Manhunt, если не секрет, где Вы сам стандарт раскопали? Давно было интересно почитать :-), а покупать влом.

> Приводишь результат сложения к int, а ожидаешь получить uint16_t

madcore, сделайте то же самое, только замените uint16_t на uint32_t, а в финальном printf приведите сумму к uint64_t. Ну и не забудьте поменять спецификаторы формата в printf.

Думаю, Вы несколько удивитесь от результата.

> Manhunt, если не секрет, где Вы сам стандарт раскопали?

Как минмум довольно поздний драфт C99 был в сети.

[quote] То, что uint16_t c = a + b; и int c = a + b; дают разные результаты тебя не смущает, а присутствие в printf неявной переменной типа int - да? [/quote]

[code] #include <stdint.h> #include <stdio.h>

int main(int argc, char** argv) { uint32_t a = 1; uint32_t b = 0 - a; uint64_t c = a + b; uint32_t d = a + b; printf("%" PRIu32 "+%" PRIu32 "=%" PRIu32 "\n", a, b, d); printf("c=%" PRIu64 "\n", c); return 0; } [/code]

[code] $ gcc tect.c -o test && ./test 1+4294967295=0 0 [/code]

Хотя c — uint64_t, c=0. Правила языка нужно знать.

>> Ты наверное ножиком по пять раз на дню режешься

> За последние 20 лет мне ни разу не удалось как следует себя порезать. Радость моя по этому поводу омрачена тем ужасным фактом, что я вынужден тебя разочаровать

Ну вот - ножиком пользоваться можешь. А о С "зубы" ломаешь. Может стоит подумать о интуитивном Visial Basic ?

Что ты хотел мне продемонстрировать?

> ты тут о чем вообще? какие лаги ? ничего что твои поделки типа фирефокса читают не напрямую из диска - а из page cache файловой системы.

Фирефокс использует sqlite. Sqlite часто делает fsync (а что еще ему делать? fbarrier-то нет!). Дальше сам догадаешься, или найти тебе линк, где последствия разжеваны?

Это не стандарт, а драфт. Первая же ссылка в гугле по запросу "ISO/IEC 9899:TC2"

> Может стоит подумать о интуитивном Visial Basic ?

Тогда уж лучше о QBasic (спасибо дяде Биллу за нескучное детство). Возможно, что и стОит. Вообще полезно время ото времени задумываться о положении вещей в окружающем мире .)

>Хотя c — uint64_t, c=0. Правила языка нужно знать.

А, понял к чему ты. А если int 64 бита, какой рзультат будет?

> Перечеитал, но все равно не очень понятно, что тебя в данном конкретном случае не устраивает.

Меня не устраивает неосведомленность бОльшей части программистов о хитровывертах стандарта. И решается это единственным способом: хитровывертов быть не должно в принципе. Семантика языка должна быть KISS, а не как у Си.

> Что ты хотел мне продемонстрировать?

То, что тип lvalue никак не отражается на типе rvalue.

>> Что ты хотел мне продемонстрировать?

>То, что тип lvalue никак не отражается на типе rvalue.

Да прямо там, никак.

> А, понял к чему ты. А если int 64 бита, какой рзультат будет?

Я немного к другому, но не суть.

Если int 64 бита, uint32_t a, uint32_t b, c = a + b даст 2^32, так как a и b будут преобразованы в unsigned int. Как-то так.

> Первая же ссылка в гугле по запросу "ISO/IEC 9899:TC2"

Отлично, спасибо.

Суть в том, что стандарт с хочет производить операции с дефолтным машинным словом.

Сложность приблизительно уменшена на 3928,5714286 процентов :)

> В том, что fdatasync "записывает на диск содержимое всех буферов данных, связанных с файлом, причем возврат из функции происходит только после того, как это было сделано". А fbarrier никаких немедленных записей не вызывает.

Но если к моменту выполнения rename() файл должен существовать, а данные должны быть записаны, в чем принципиальная разница? Как ни крути, по крайней мере данные, получаются, должны быть записаны. Или я упустил из виду что-то фундаментальное?

> Суть в том, что стандарт с хочет производить операции с дефолтным машинным словом.

В архитектуре amd64 машинное слово 64 бита, но sizeof(int) == 4 (по крайней мере, gcc), то есть 32 бита.

>В архитектуре amd64 машинное слово 64 бита, но sizeof(int) == 4 (по крайней мере, gcc), то есть 32 бита.

А на ia64 оно 64, а 8086 - 16, и что? Полагаться при перелополнениях на простой int нельзя.

> А на ia64 оно 64, а 8086 - 16, и что?

Я так понял, что мы говорим о разных вещах.

По производительности по отношению к Linux, как этот DragonFly BSD? Тесты есть?

>> не переживай от "перенапряжения" не умру.

>Я бы и не переживал.

Ты за линукс переживай вот статя еще одна тех лет, о проблеме роста и его цены: http://www.dwheeler.com/essays/linux-kernel-cost.html

Уже обсудили.. http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4075298

В этом релизе много больше изменений и новшеств чем обычно. Писали люди, баги есть, через месяц выйдет DragonFly BSD 2.4.1 где профиксят все найденые баги... Для установки на кластера стоит дождатся этого релиза, "напосмотрать в виртуалке" хватет и того что есть сегодня.

>POSIX тоже, а так таких как вы мыслителей (а-ля создадим свою ОС с своим АПИ необычным, и будет нам счастье) - полно, только вот вопрос - сколько пилить будете ? Написать ведро (особенно если монолит) дело еще посильное (только на фик никому не нужное), свои нативные либы - ибо свое API ну допустим тоже не сложно, а дальше? свои тулзы, кучу ПО и прочего поделия - это уже не осилить, портировать никак - нет C и POSIX - пейшите свое, и главное даже если будет что то - то еще неизвестно куда закапывать поделку, ибо можете просрать в чем угодно от стабильности до производительности и масштабируемости.

В неокласических монолитных ядрах есть проблема. С микроядрами есть проблема в самой их мат-модели, ну работали писали но пока не получается.. Данный проэкт, ЕДИНСТВЕННАЯ за всю историю юникс попытка изменить архитектуру мат-модели ядра, и добавить асинхронность работы на MP системы, что _должно_ значительно упростить развитие _другой_ юникс в будущем, когда неокласические ядра достигнут заката, а микроядра так создать и не получится...

>а дальше? свои тулзы, кучу ПО и прочего поделия - это уже не осилить, портировать никак - нет C и POSIX - пейшите свое, и главное даже если будет что то - то еще неизвестно куда закапывать поделку, ибо можете просрать в чем угодно от стабильности до производительности и масштабируемости.

Принято решение писать эмулятор POSIX, в планах эмуляторы Linux, FreeBSD.

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

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

Чем больше ты знаешь о предстоящих после барьера действиях, тем удачнее ты распланируешь действия до барьера. При некоторых ограничениях можно объединять несколько разделенных барьерами участков работы в одну большую транзакцию, и внутри нее свободно переставлять операции. Это довольно абстрактные идеи, детали определяются конкретной ФС. В случае с f(data)sync о предстоящих действиях тебе не расскажут до тех пор, пока ты не поработаешь с диском - и это ограничивает твои возможности по планированию.

Теоретически она должна вставлять фрю и линукс не только на многих процесорах, но даже на одном...

Тестов новых нету. Нашёл старые заангажированые в сторону free-7.0 http://people.freebsd.org/~kris/scaling/dfly.html

Тесты криса били перепроверены линуксистами и в них линукс уже вставля фрю по всем параметрам...

DragonFly BSD есть долгострочный технический проект... не все планы там реализованы и не всё пока оптимизированно. Надо новые тесты...

>Тесты криса били перепроверены линуксистами и в них линукс уже вставля фрю по всем параметрам...

http://www.opennet.ru/opennews/art.shtml?num=14606

Прочитал. Но так и не понял, как так ловко удается обходиться без критических секций: почему не будет переключения между двумя работающими с одной структурой данных процессами? За счет маркеров? Не понял, как работает IPI.

> не понял, как так ловко удается обходиться без критических секций

критических секций избежать нельзя // К.О.

> почему не будет переключения между двумя работающими с одной структурой данных процессами? За счет маркеров?

И за счет того, что ядро невытеснимое %)

>> Перечеитал, но все равно не очень понятно, что тебя в данном конкретном случае не устраивает.

>Меня не устраивает неосведомленность бОльшей части программистов о хитровывертах стандарта. И решается это единственным способом: хитровывертов быть не должно в принципе. Семантика языка должна быть KISS, а не как у Си.

Ну есть идеальные модели, а есть жизнь. Как не удивительно, а реально работающая железке похрен на различные KISS и стандарты. Альтернатив-то на самом деле нет (ну не научились еще писать работающие ОС на java/C#). И всякие oberon, это как раз еще никак не проявивше себя идеальные модели.

ЗЫ: я не madcore.

>> не понял, как так ловко удается обходиться без критических секций

>критических секций избежать нельзя // К.О.

В модели lwkt критеческих секций по отношению ко всей системы нет, критические секции возникают только на каждом процессоре, а вся многопроцессорная система работает без кретических секций полностью асинхронно, даже I/O всех девайсов работает асинхронно! Это достигается путём запуска на каждом процессоре своего планировщика задач lwkt, который и обслуживает вход нитей в локальные критические секции. Там до недавна у них была проблема с асинхронной работой сети на многих ядрах, вот незнаю решили уже?

http://www.linux.org.ru/jump-message.jsp?msgid=4071750&cid=4075175

"1. Для каждого процессора в системе имеется свой собственный, автономный LWKT-планировщик (sheduler). Нити умышленно привязываются к своим процессорам и могут быть перемещены на другой процессор только при наступлении некоторых особых условий. Любая операция планирования LWKT на конкретном процессоре может выполняться только непосредственно на этом процессоре. Это значит, что LWKT-планировщик может производить планирование и переключение нитей без каких бы то ни было блокировок. Никаких блокировок на уровне многопроцессорной системы, ничего, кроме простого критического участка. "

>.....Не понял, как работает IPI.

"4. Процессор, который пытается планировать нить, принадлежащую другому процессору, для выполнения операции будет посылать целевому процессору сообщения основанные на IPI. Эти сообщения асинхронны по умолчанию, и хотя IPI могут обладать некой латентностью, они не обязательно растрачивают вхолостую циклы по этой причине. Нити могут заблокировать подобные операции путем входа в критический участок, что фактически и делает LWKT-планировщик. Вход в критический участок и выход из него считаются экономными операциями и не требуют ни блокировки, ни выполнения команд блокирования шины.

5. Подсистема сообщений IPI работает со взаимными блокировками FIFO, путем прокручивания и обработки очереди входящих сообщений в ожидании разгрузки очереди исходящих сообщений. В этих условиях подсистема сообщений IPI специально не переключает нити, что позволяет программе воспринимать ее как неблокирующий API, хотя может происходить прокручивание."

Хитрая внутриядерная система сообщений с помощью которой планировщики выполняемые на разных ядрах обмениваются информацией...