> я всегда наивно думал, что ошибки вычислений происходят от ошибок в

прикладных программах, а не в ОС.

И совершенно напрасно. Промежуточные результаты вычислений хранятся в физической памяти. Физическая память отображается в виртуальную, которую видит процесс. При ошибках работы системы с табличкой для процессора, в которой записано соответствие физического и виртуального адреса (TLB) на месте нормальных данных может оказаться полнейшая чушь. Сталкивался с этим на ещё на NT4.0, при частом и многократном Alloc и Free, после очередного Alloc вместо странички с данными иногда появлялась совершенно левая страница. Пришлось в начале работы программы тупо делать Alloc огромного куска памяти, который может потребоваться и пользовать потом его. Причина была где-то в ntdll.dll Nt(Zw)AllocateVirtualMemory, окончательно так и не выяснили, терпения не хватило. Это, кстати, к вопросу, о том, отчего винда и её софт так прожорливы. А вот поэтому в том числе.
Это раз.

В винде нередки сбои ОС, не приводящие к чему-то фатальному, но портящие данные процесса. Ядро, прочитав данные из устройства (с файлами вроде всё хорошо было), например, пишет данные не в предоставленный буфер, а куда-то от балды. Это два.

Ну и разумеется реализация системных математических функций. Честно скажу - с ошибками в математической библиотеке винды я не сталкивался. Может быть тут у микрософта всё хорошо. Это три.

Но почему я этих проблем не заметил за многолетнее использование Виндовс XP на домашнем и рабочем компьютерах?

Приведите примеры системных математических функций Виндовс (или Линукса). Именно системные вызовы, а не библиотека С.

> Но почему я этих проблем не заметил за многолетнее использование

Виндовс XP на домашнем и рабочем компьютерах?

Никогда-никогда за много лет сама не перезагружалась, никогда про Exception внезапно ничего не говорила и никогда не вываливалась в синий экран?

> Приведите примеры системных математических функций Виндовс (или

Линукса). Именно системные вызовы, а не библиотека С.

А разве математическая либа не является частью системы? Речь-то не о ядре, а о системе целиком. ntdll.dll или там kernel32.dll - не системные библиотеки?
Впрочем, если докапываться до столба, то обработка FPU Exception и всякая эмуляция сопроцессора, если FPU нету - прям в ядре и находятся.

А чем FPU на Linux так кардинально отличается от FPU на Windows?

Синий экран Виндовс как-то давала в результате проблем с памятью, после замены планки проблемы исчезли. Никаких exception от самой виндовса не было, только от прикладных программ без проблем у самой виндовс. ЧЯДНТ?

FreeBSD у меня вешалась гораздо чаще. Даже тупое переключение между консолями ctrl-alt-F* бывало вешало наглухо. Загрузка процессора её вешала. После перезагруки открытые файлы были пустые. И т.д.

> А чем FPU на Linux так кардинально отличается от FPU на Windows?

Если FPU есть - то оно не на линуксе и не на винде, а в процессоре.

Отличаются математические библиотеки, ибо в x86 в FPU всяких синусов и косинусов нету.

>в x86 в FPU всяких синусов и косинусов нету.

какой жёсткий слив.

«Чем принципиально 64-битные x86 процессоры отличаются от 32-битных? Помимо возможности быстрой работы с целыми 64-битными числами и прямой адресации несравнимо больших объёмов как виртуальной, так и физической памяти, новый индустриальный стандарт для x86 процессоров ликвидировал три принципиальных недостатка этой архитектуры:

1. Удвоение числа целочисленных регистров общего назначения - по этому параметру все потомки Intel 386 очень сильно отставали от современных RISC и VLIW процессоров. Использование компилятором этих регистров позволяет заметно улучшить эффективность реализации многих алгоритмов. 2. Использование для операций с плавающей точкой не стека, а регистров, используемых в наборе команд SSE2. Очень заметно отражается на производительности, но также требует перекомпиляции программного обеспечения. 3. DEP - Data Execution Protection (защита от передачи на выполнение содержимого сегмента данных при возникновении ошибки переполнения), также называется EVP (Enhanced Virus Protection), сильно затрудняет работу определённых классов вредоносных программ, в первую очередь - червей и троянцев. Не требует перекомпиляции ПО, поддерживается и 32-битными ОС Microsoft, начиная с WindowsXP SP2 и Wndows 2003 Server SP1» ???

> Никаких exception от самой виндовса не было, только от прикладных

программ без проблем у самой виндовс.

Откуда такая уверенность? :)
Как раз exception на виндовсе и говорят о проблемах в ядре.
Характерное поведение в винде - _внезапно_ выскакивает exception, софтина закрывается. Последующие попытки повторить это, совершая те же самые действия ни к чему не приводят, софтина нормально работает. Это и есть свидетельство того, что с большой вероятностью проблема в системе.

Если проблема в софтине - то она вываливается по exception всегда, при совершении одних и тех же действий. Что и наблюдается как правило во фре и линуксе. И авторы софтин под линукс частенько прикручивают на обработку exception форму отправки сообщения об ошибке, чтобы оно отсылалось автору софтины.

А теперь, внимание, вопрос - куда винда предлагает (если предлагает вообще) отослать сообщение об ошибке?
А почему не автору софтины?

Здесь не домохозяйки сидят, а в том числе профессиональные программисты, которые прекрасно знают, что такое ошибки и откуда они берутся. Смешить так не надо своими познаниями. Сначала разберитесь, куда у вас пропали синусы в интеловских FPU.

> какой жёсткий слив.

Минуточку. в винде double sin(double) это FSIN?
Ахренеть.

> Сначала разберитесь, куда у вас пропали синусы в интеловских FPU.

Не знаю как у вас, а у меня синус из интелевского FPU сидит в fsin() и никогда не используется, а что?

Ну нету double sin(double) в x86 FPU. Оно везде ручками написано. Ну хоть в сырцы libc гляньте для приличия.

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?

где в словах «в x86 в FPU всяких синусов и косинусов нету» слово винда? Слив - они есть слив, не оправдывайтесь :))

> где в словах «в x86 в FPU всяких синусов и косинусов нету» слово

винда? Слив - они есть слив, не оправдывайтесь :))

Единственное в чём я облажался - надо было какой-нибудь арксинус упомянуть. Ну не пришло мне в голову, что кто-то знаменитый своим вечным багом FSIN/FCOS x87 может всерьёз воспринимать. Впрочем, и остальные «тяжёлые» функции x87 типа логарифмов и пр. тоже не особо используют в математических библиотеках, а пишут ручками.
Но суть-то не в этом.

Вы говорите об архитектуре процессора, а не о программной части.Во всех процессорах Intel x585 (могу ошибиться Pentium I) использована нормальная FPU с мат функциями. На ASM в любом случае этого не видно, но инструкции прописаны...

>обработка FPU Exception и всякая эмуляция сопроцессора, если FPU нету - прям в ядре и находятся.

в каком ядре? в ядре Виндовс? или в ядре МС-ДОС тоже была эмуляция сопроцессора на случай его отсутствия для процессоров 8086-80386?

> На ASM в любом случае этого не видно, но инструкции прописаны...

Речь шла вообще-то о том, как именно OC может влиять на результаты работы стороннего приложения. Один из вариантов такого влияния - кривая/неточная реализация математических функций. Не подумав о том, что кто-то может не знать про FSIN и причины по которым его не используют для вычислений синуса почти везде, а используют написанную руками функцию, я ляпнул про «синусы-косинусы». Отсюда и произошёл весь этот пустой флейм.

FPU с начала 486х уже все нормально обрабатывала. В архитектуре, считается 16 знаков после запятой, или 65536 байт в такте. Адресация ограничена также.Но математические функции все реализованы.Не вижу разницы в количестве мат. функций x64 архитектуры.

>>обработка FPU Exception и всякая эмуляция сопроцессора, если FPU нету

- прям в ядре и находятся.

в каком ядре? в ядре Виндовс? или в ядре МС-ДОС тоже была эмуляция

сопроцессора на случай его отсутствия для процессоров 8086-80386?

Ну да, в ядре виндовса. Откуда сопроцессор, например, в каком-нибудь древнем iPAQ?

Продолжим разбор сливов. Ранее мы установили, что никаких синусов у интела нет. Потом они неожиданно появились.

И что мы видим?

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?

gcc вовсю использует инструкции сопроцессора, что можно узнать, например, в пункте 3.17.15 Intel 386 and AMD x86-64 Options документации GCC.

Так круто сливать это надо уметь.

В винде используют FSIN. В GCC используют FSIN. в glibc используют FSIN. Может быть вам стоит остановиться и перестать врать?

Насколько я помню была такая история:
сначала выпустили 387.
потом через достаточно продолжительное время оказалось, что он неправильно (с недостаточной точностью) считает синус и косинус при определённых диапазонах аргумента.
т.к. сопроцессоров уже было выпущено дофига, и софт подстроили под этот глюк, то в следующих сопроцессорах fsin и fcos решили оставить как есть, с ошибкой. Ещё были всякие флеймы по поводу того, что AMD то-ли тоже повторила этот глюк, то-ли наоборот не повторила и софт стал неправильно считать, не помню уже.
Продолжает ли тянуться этот глюк во всяких CoreDuo и прочем - я не знаю, но судя по интелевской привычке обеспечивать обратную совместимость любой ценой и тащить до сих пор 16-разрядный режим, глюк должны были оставить.

> gcc вовсю использует инструкции сопроцессора, что можно узнать,

например, в пункте 3.17.15 Intel 386 and AMD x86-64 Options

документации GCC.

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

насколько помните или насколько нашли в гугле мало что понимая о предмете? пункт 4.2 правил форума не для вас писали?

Вроде пофиксили на атлонах и пентиумах. Иначе мы живем в математичеки неправильном мире. :)))

действительно с чего бы не использовать FSIN? я тоже удивляюсь. Ещё я удивляюсь на вас, уважаемый, ваша светлая персона за пару часов несколько раз уже изволила кардинально поменять своё мнение, сообщив массу недостоврной информации.

> В винде используют FSIN.

Не в курсе. Если используют - то идиоты.

В GCC используют FSIN.

GCC - это компилятор, а не ОС. Если я хочу по каким-то причинам использовать именно fsin - то компилятор обязан предоставить мне эту возможность.

в glibc используют FSIN.

Где? Я что-то не нашёл.
Даже в uClibc - и то fsin будет только если _специально_ __FAST_MATH__ включить.

подведём итоги.
вы наврали:
1) в процессорах интела нет синусов (но они там есть)
2) синусы есть, но их никто не использует (но используют и по умолчанию)
3) в glibc нет синусов интела (но они там есть)
3) в синусах есть ошибка ещё до пентиума, которую все повторяли (но ошибка была в делении у пентиума и никто её не повторял)

я за бан по 4.2

1) в процессорах интела нет синусов (но они там есть)

То, что там есть - не синус, а глюк.

2) синусы есть, но их никто не использует (но используют и по умолчанию)

Я нашёл только в uClibc если принудительно включить __FAST_MATH__

3) в glibc нет синусов интела (но они там есть)

Не нашёл. Где? файл:строчку кода на бочку.

3) в синусах есть ошибка ещё до пентиума, которую все повторяли (но ошибка была в делении у пентиума и никто её не повторял)

Не могу уловить смысл написанного.

кушай, тролль! желаю тебе приятного бана по 4.2

bubuntu@bubuntu-desktop:~$ cat test.c 
#include <math.h>
int main(int argc, char** argv)
{
	return (int)sin(argc);
}

bubuntu@bubuntu-desktop:~$ gcc -lm test.c

bubuntu@bubuntu-desktop:~$ gdb a.out 
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/bubuntu/a.out...(no debugging symbols found)...done.

(gdb) break sin
Breakpoint 1 at 0x804836c

(gdb) run
Starting program: /home/bubuntu/a.out 

Breakpoint 1, 0x00137200 in sin () from /lib/tls/i686/cmov/libm.so.6

(gdb) disassemble
Dump of assembler code for function sin:
=> 0x00137200 <+0>:	fldl   0x4(%esp)
   0x00137204 <+4>:	fxam   
   0x00137206 <+6>:	fstsw  %ax
   0x00137209 <+9>:	mov    $0x45,%dh
   0x0013720b <+11>:	and    %ah,%dh
   0x0013720d <+13>:	cmp    $0x5,%dh
   0x00137210 <+16>:	je     0x137236 <sin+54>
   0x00137212 <+18>:	fsin   
   0x00137214 <+20>:	fnstsw %ax
   0x00137216 <+22>:	test   $0x400,%eax
   0x0013721b <+27>:	jne    0x137220 <sin+32>
   0x0013721d <+29>:	ret    
   0x0013721e <+30>:	xchg   %ax,%ax
   0x00137220 <+32>:	fldpi  
   0x00137222 <+34>:	fadd   %st(0),%st
   0x00137224 <+36>:	fxch   %st(1)
   0x00137226 <+38>:	fprem1 
   0x00137228 <+40>:	fnstsw %ax
   0x0013722a <+42>:	test   $0x400,%eax
   0x0013722f <+47>:	jne    0x137226 <sin+38>
   0x00137231 <+49>:	fstp   %st(1)
   0x00137233 <+51>:	fsin   
   0x00137235 <+53>:	ret    
   0x00137236 <+54>:	push   %ebx
   0x00137237 <+55>:	call   0x131517
   0x0013723c <+60>:	add    $0x1bdb8,%ebx
   0x00137242 <+66>:	call   0x1313a8 <__errno_location@plt>
   0x00137247 <+71>:	movl   $0x21,(%eax)
   0x0013724d <+77>:	pop    %ebx
   0x0013724e <+78>:	jmp    0x137212 <sin+18>
End of assembler dump.
(gdb) 

И ещё для неугомонных ононимов:

test.c: -------------------

#include <math.h>
#include <stdio.h>

double fsin( double x )
{
register double res;
asm( «fsin» : «=t» (res) : «0» (x) );
return res;
}

int
main(int argc, char** argv)
{
printf(«sin(43998769152.000000) is %.16le\n», sin(43998769152.000000));
printf(«fsin(43998769152.000000) is %.16le\n», fsin(43998769152.000000));
}
------------------------

$ gcc -lm -o test test.c
$ ./test
sin(43998769152.000000) is -4.0252920638371055e-09
fsin(43998769152.000000) is -4.0819367251002277e-09

Офигенно fsin синусы считает.

Если чо -
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Mobile Intel(R) Celeron(R) CPU 2.40GHz
stepping : 9
cpu MHz : 2400.304
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 4801.15
clflush size : 64

Это чо за ужос?

Где обещанный точный и замечательный FSIN имени Интеля?

Не можем никак успокоиться после всей лжи? пример показывает, что
1) fsin есть у интела
2) fsin используется в линуксах
3) fsin используется в GCC
4) fsin используеться в glibc
5) fsin используется по умолчанию без явного указания пользователем

За 4.2 надо банить анонимусов, причём превентивно.

Вот ещё, тот же код выдаёт:

$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16

Этот FSIN не может даже sin(около pi) посчитать правильно.

Не можем никак успокоиться после всей лжи? пример показывает, что
1) fsin есть у интела
2) fsin используется в линуксах
3) fsin используется в GCC
4) fsin используеться в glibc
5) fsin используется по умолчанию без явного указания пользователем

Бла-бла-бла.

--------------- test.c -------------------------------
#include <math.h>
#include <stdio.h>

double fsin( double x )
{
register double res;
asm( «fsin» : «=t» (res) : «0» (x) );
return res;
}

int
main(int argc, char** argv)
{
printf(«sin(%.16le) is %.16le\n», M_PI, sin(M_PI));
printf(«fsin(%.16le) is %.16le\n», M_PI, fsin(M_PI));
}

-----------------------------------------

$ gcc -lm -o test test.c
$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16


Этот пример показывает, что для вычисления sin() не используется fsin имени интеля а используется куча кода, которая может быть разная в разных ОС, что может служить источником ошибок.

гыгыгы. ты хоть на калькуляторе проверял вывод своей программы? sin(43998769152.000000) = 0.951056516

откуда там fsin взялся то? у Вас же его не было в принципе и в линуксах он не использовался, только в винде. Таки откуда он объявился?

> гыгыгы. ты хоть на калькуляторе проверял вывод своей программы?

sin(43998769152.000000) = 0.951056516

Радианы включи, чудо... На твоём калькуляторе есть радианы?

что ты так облажался? твой же текст

Не знаю как у вас, а у меня синус из интелевского FPU сидит в fsin() и никогда не используется, а что?

Ну нету double sin(double) в x86 FPU. Оно везде ручками написано. Ну хоть в сырцы libc гляньте для приличия.

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?

GCC тогда почему использует, лгунишка?

> откуда там fsin взялся то? у Вас же его не было в принципе и в

линуксах он не использовался, только в винде. Таки откуда он

объявился?

Где это я такое говорил?

Я утверждал, что :

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

А чем FPU на Linux так кардинально отличается от FPU на Windows?

Если FPU есть - то оно не на линуксе и не на винде, а в процессоре.

Отличаются математические библиотеки, ибо в x86 в FPU всяких синусов

и косинусов нету.

Ибо fsin от интеля за синус считать никак нельзя. Даже выдернутый из убунты код libm для вычисления синуса почему-то содержит кучу всякой всячины, а не единственный fsin, который якобы синус сам по себе.
В винде, скорее всего, код sin будет другой.

Облажался не я, а кто-то другой.

Если sin === FSIN, то как тогда получается это:

$ ./test
sin(3.1415926535897931e+00) is 1.2246467991473532e-16
fsin(3.1415926535897931e+00) is 1.2246063538223773e-16

Любому идиоту понятно из этого примера, что для вычисления правильного sin() используется не команда сопроцессора FSIN, а какой-то код.

Убунта по умолчанию использует fsin интела. А ты что понаписал вранья кучу?

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899619
в x86 в FPU всяких синусов и косинусов нету.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899653
Минуточку. в винде double sin(double) это FSIN?
Ахренеть.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899662
Не знаю как у вас, а у меня синус из интелевского FPU сидит в fsin() и никогда не используется, а что?

Ну нету double sin(double) в x86 FPU. Оно везде ручками написано. Ну хоть в сырцы libc гляньте для приличия.

Вы не знали, что FSIN на практике не используют, и что для синуса практически везде написана своя функция которая быстрее и точнее чем FSIN?


http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899695
Ну не пришло мне в голову, что кто-то знаменитый своим вечным багом FSIN/FCOS x87 может всерьёз воспринимать.

http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899715
Не подумав о том, что кто-то может не знать про FSIN и причины по которым его не используют для вычислений синуса почти везде, а используют написанную руками функцию


http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899734
С чего бы это _компилятору_ не давать возможность использовать любые инструкции сопроцессора, если этого хочет пользовательн?



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

В винде используют FSIN.

Не в курсе. Если используют - то идиоты.

в glibc используют FSIN.

Где? Я что-то не нашёл.

Это всё вообще к чему?
Ну посмотрели на бубунтов sin. Функция не состоит из единственного fsin, а состоит из кучи кода, как и утверждалось.
В винде используется такой же код?
В винде линуксе и пр. - может использоваться разный код?
Очевидно может. И если где-то он кривой - то это приведёт к ошибкам при вычислениях. Что не так?

Не нравится sin(), потому что как бы есть fsin?
Ну давайте поговорим об arcsin()
Надеюсь утверждение, что arcsin реализован программно в математической библиотеке не вызовет аналогичного баттхерта?
Если не вызовет - то можно перейти к сути.
Итак, дадите гарантию, что в винде и линуксе и где-то там ещё код arcsin() одинаков и что этот код не может служить источником ошибок?

Ты утверждал, что fsin вообще нет. Потом что fsin есть, но не используется. Потом утверждал что использующие её люди являются идиотами. Потом что её нет в glibc.

Таким образом ты энергично сливал, пользовался гуглом. потом опять сливал и так много раз.

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

сливал и так много раз.

Слил тут кто-то другой. Тот, кто пытается рассказать, что fsin в интеле - это синус, вместо того, чтобы понять, что речь шла вовсе не об этом.

Я, кстати, опечален тем, что в убунте кривой sin().
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490
Правда, всех послали в glibc жаловаться на регрессию.
У меня вот sin() нормальный и fsin не использует, как оказалось.

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

Синус который fsin - использует для уменьшения аргумента число пи с мантиссой 66 бит. В glibc видно (код я приводил), что там для уменьшения аргумента используется отдельная команда почему-то, которая загружает в FPU число пи, которое округляется по документации до 64 знаков. Уменьшение аргумента происходит с этим более грубым пи.

Поэтому есть основания доверять больше чистому fsin, а не реализации glibc, которая ещё от себя код добавляет.

какой из них нормальный? какими средствами, независимыми от линукса, виндовс, интела и амд проверялись? Откуда уверенность, что верно первое, а не второе?

sin(43998769152.000000) is -4.0252920638371055e-09
fsin(43998769152.000000) is -4.0819367251002277e-09

>У меня вот sin() нормальный

как это было доказано? какую использоали библиотеку, независимую от 80-битных чисел с плавающей точкой и процессоров интела и амд? Где взять точное значение вашего синуса хотя бы 20 значащих цифр, чтобы убедиться, что ваш синус правильный, а не чистый синус fsin?

Но мой-то sin() который без fsin даёт правильный результат, а чистый fsin даёт неправильный.

Если glibc где-то использует fsin - то это и есть доказательство того, что от системы зависит наличие ошибок в софтине. Софтина-то может и правильно считает, а вот синус ей даден неправильный. О чём с самого начала и шла речь.

Уверены, что результат правильный? Уверены, что у вас sin без fsin? на 32 разрядах по умолчанию FPU используется.

MathLab говорит первое правильно.
Винда, кстати, в калькуляторе так же считает.
http://web2.0calc.com/ тоже.

Да, уверен.
Если бы sin был с fsin - то результаты совпадали бы, разве не так?

Не так. Ассемблерный код приведите вашего sin. В случае использования константы sin вообще не вызывается - компилятор туда константу забивает вычисленную заранее. Если константу умножить на argc (т.е. 1), то происходит вызов sin (там внутри fsin) и результат становится другой.

Уверен.
Вот результат с D-Link DIR-320 - он вообще MIPS и без всякого сопроцессора:
---------------- sin_test.c ------------------------
#include <math.h>
#include <stdio.h>

int
main(int argc, char** argv)
{
double d = 43998769152.000000;
printf(«sin(%.16le) is %.16le\n», d, sin(d));
}
------------------------------------------------------

# /tmp/sin_test
sin(4.3998769151999998e+10) is -4.0252920638371056e-09
# cat /proc/cpuinfo
system type : Broadcom BCM5354 chip rev 3
processor : 0
cpu model : BCM3302 V2.9
BogoMIPS : 237.56
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available

Результат при

double d = 43998769152.000000;
printf(«sin(%.16le) is %.16le\n», d, sin(d));
и при
printf(«sin(43998769152.000000) is %.16le\n», d, sin(43998769152.000000));

Одинаков.

-4.0252920638371055e-09
Так что и glibc и препроцессор gcc использует одинаковую функцию и без использования fsin
потому что fsin даёт
-4.0819367251002277e-09

uClibc на MIPS тоже даёт
-4.0252920638371055e-09

В принципе, могу и на ARM проверить, только уже лень....

надо умножить на 1 (argc), тогда результат становится разным и неправильным, потому что выключается оптимизация и вызывается функция sin в процессе работы программы.

Поздравляю, Ваша убунта неправильно считает синус. :)
А препроцессор gcc - правильно.

на убунте 386 sin и fsin дают одинаковые результаты. Так что «идиоты» есть и в линуксе такие же как в виндовс, по вашей терминологии, раз используют fsin в функции sin, что и подтверждает ассемблерный код и одинаковые результаты работы функций sin и fsin.

значит препроцессор gcc не использует glibc.

Таким образом имеем использование fsin в Линуксах, в glibc, и её функция sin имеет ошибки. А винда не имеет ошибки, как вы подвердили.

Вывод: Линукс - глючное дерьмо и не готово для вычислений :))) Что и требовалось доказать. Кто там плохо про винду писал недавно? Не вы ли?

Блин. Всё просто.

Если написать
double d = 1234;
printf(«%.16le»,sin(d));
И не включать оптимизацию, то вызовется функция.

08048404 <main>:
8048404: 8d 4c 24 04 lea 0x4(%esp),%ecx
8048408: 83 e4 f0 and $0xfffffff0,%esp
804840b: ff 71 fc pushl -0x4(%ecx)
804840e: 55 push %ebp
804840f: 89 e5 mov %esp,%ebp
8048411: 51 push %ecx
8048412: 83 ec 14 sub $0x14,%esp
8048415: b8 00 00 00 e0 mov $0xe0000000,%eax
804841a: ba 0f 7d 24 42 mov $0x42247d0f,%edx
804841f: 89 45 f0 mov %eax,-0x10(%ebp)
8048422: 89 55 f4 mov %edx,-0xc(%ebp)
8048425: 83 ec 08 sub $0x8,%esp
8048428: ff 75 f4 pushl -0xc(%ebp)
804842b: ff 75 f0 pushl -0x10(%ebp)
804842e: e8 09 ff ff ff call 804833c <sin@plt>
.....

Если написать прям внутри синуса или включить -O2 - то посчитает препроцессор gcc, потому что он умеет sin.

080483c0 <main>:
80483c0: 8d 4c 24 04 lea 0x4(%esp),%ecx
80483c4: 83 e4 f0 and $0xfffffff0,%esp
80483c7: ff 71 fc pushl -0x4(%ecx)
80483ca: 55 push %ebp
80483cb: 89 e5 mov %esp,%ebp
80483cd: 51 push %ecx
80483ce: 83 ec 10 sub $0x10,%esp
80483d1: 68 da 49 31 be push $0xbe3149da
80483d6: 68 87 89 6b fd push $0xfd6b8987
80483db: 68 0f 7d 24 42 push $0x42247d0f
80483e0: 68 00 00 00 e0 push $0xe0000000
80483e5: 68 c0 84 04 08 push $0x80484c0
80483ea: e8 fd fe ff ff call 80482ec <printf@plt>
80483ef: 83 c4 20 add $0x20,%esp
80483f2: 8b 4d fc mov -0x4(%ebp),%ecx
80483f5: c9 leave
80483f6: 8d 61 fc lea -0x4(%ecx),%esp
80483f9: c3 ret

Убунта x86 10.04 LTS, полностью обновлённая несколько часов назад, неправильно считает синусы. Вот так вот, господа присяжные заседатели :))))

> Вывод: Линукс - глючное дерьмо и не готово для вычислений :))) Что и

требовалось доказать. Кто там плохо про винду писал недавно? Не вы

ли?

Пока только выяснили, что Интель глючное дерьмо и Убунта, которая использует Интелевский fsin глючное дерьмо.

А про винду я писал следующее:

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

Ну и разумеется реализация системных математических функций. Честно

скажу - с ошибками в математической библиотеке винды я не

сталкивался. Может быть тут у микрософта всё хорошо. Это три.

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

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

>Честно скажу - с ошибками в математической библиотеке винды я не сталкивался.

Я тоже не сталкивался. А в Линуксе теперь столкнулся. Так позорно Линукс сливает винде, на каком-то синусе! Это надо постараться криворуким линуксовым разработчикам :)))

Этож каким лохом нужно быть, что бы линукс на сервера ставить. Он даже 2+2 сложить врядли сможет без ошибок. :(

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

Когда речь зашла о том, что,

я всегда наивно думал, что ошибки вычислений происходят от ошибок в

прикладных программах, а не в ОС.

я написал тут: http://www.linux.org.ru/jump-message.jsp?msgid=5896513&cid=5899582 что встречал ошибки при работе винды с TLB, и при работе ядра винды с юзерскими буферами при чтении из устройств. И написал что есть ещё возможность влияния ОС на ошибки вычислений при корявой реализации системных мат. функций, причём честно написал, что с последним в винде не сталкивался.

После чего анонимусы взбесились и давай флеймить за корявый интелевский fsin.

В итоге выяснилось, что ОС всё-же может давать ошибки вычислений из-за ошибок в мат.функциях, только оказалость что в этом случае ошибки обнаружились в линуксе.

И в чём же я был не прав?

Очень радует, что упомянутые ранее физики так называемый «процесс распада в ядерной реакции» считают под надёжной Виндовс, а не под Линуксом с его кривыми синусами. Так ведь и ядерную катастрофу можно вызвать с этими линуксовыми ошибками в математических библиотеках :)) ))

>И в чём же я был не прав?

В этом и не прав. Твои же слова.. " только оказалость что в этом случае ошибки обнаружились в линуксе." ))))

К стати, как там в Линуксе 4/3*3 Все так же криво считает?

Ну ошибки в синусе, да ещё и не во всех линуксах как-то меньше беспокоят, чем проблемы с менеджментом памяти в винде :) В конце-концов поправят glibc и проблема будет решена. А к XP-то сервиспаков больше не будет.

Как в том анекдоте. «Я-то завтра протрезвею, а у тебя ноги кривые так и останутся»

Кстати, не факт, что калькулятор в винде использует системные функции.
Если у кого есть VC - проверьте, что там в системе на самом деле.

perl -e 'print 4/3*3 . «\n»;'
4
Всё хорошо, успокойтесь.

>Ну ошибки в синусе, да ещё и не во всех линуксах как-то меньше беспокоят

А меня беспокоит. Какой мне Линукс ставить на атомной электростанции, а какой для космических вычислений. :( Или виртуалки поднимать для каждой задачи?

Вы неправы в очернении Виндовс и расхваливании глючного Линукса, который даже синусы считать не умеет :))

Также было заявление

Отличаются математические библиотеки, ибо в x86 в FPU всяких синусов и косинусов нету.

Библиотеки действительно отличаются. Как и было наглядно показано. :)) И не в пользу Линукса они отличаются.
Но синусы и косинусы есть в FPU, тут уж вы облажались конкретно с этим заявлением. Они даже в glibc есть эти синусы от FPU.

Не понял.
Я наверно тупой как валенок.
Ошибки вычислений в программах не могут происходить по вине ОС?

>Всё хорошо, успокойтесь.

Ну слава Богу хоть примитив считать умеет.

> Библиотеки действительно отличаются. Как и было наглядно показано.

:)) И не в пользу Линукса они отличаются.

Кто сказал? Тут пока ещё никто не скомпилил под винду тестик.
Калькулятор может и свою математику использовать.

Но синусы и косинусы есть в FPU, тут уж вы облажались конкретно с

этим заявлением.

синус, который даёт ошибку в проценты - это не синус.
Или тут как на войне? Во время атаки синус может быть и 2 и даже 3?

Они даже в glibc есть эти синусы от FPU.

Хорошо что не везде. И плохо что эти «синусы военного времени» где-то есть.
А виноват - интель.

2*2 проверить?

>А виноват - интель.

В том что Виндовс кривая или Линукс? Ты меня уже совсем запутал. :(

И где хвалёная мега-скорость исправления ошибок в Линуксе? Эти синусы - это же даже не дыра, а огромная дырища с точки зрения математических вычислений. Когда же пропатчат? Может попросить квалифицированных программистов Майкрософта потратить пару часов и исправить glibc, раз уж линуксоиды тормозят и не умеют ничего делать :)))

>раз уж линуксоиды тормозят и не умеют ничего делать :)))

Линуксоиды могут только кричать-откройте свой код, у нас ничего не получается.

> В том что Виндовс кривая или Линукс?

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

Ты меня уже совсем запутал. :(

А кому сейчас легко?

Ну всё, анонимусы, доигрались.
Я винду нашёл с компилятором.

C:\Drova>sin_test.exe
sin(4.3998769152000000e+010) is -4.0819367251002277e-009

Windows XP Porfessional Service Pack 3 версия 2002

И кто это будет исправлять?

Да, sin() из msvcrt.dll

>Ну всё, анонимусы, доигрались. Я винду нашёл с компилятором.

Со своим кривым глибсом? ))

Ошибка 2002 года в Виндовс теперь есть и в Линуксе! Это успех Линукса. Это реальная победа. Теперь Линукс может гордиться - он таки догнал Виндовс :)))

msvcrt.dll это glibc?
О как.
Продолжайте, это забавно :)

Ну дайте мне rdesktop на Win7 с компилятором, поглядим что там...
Дело-то нехитрое.

Да забавен твой бред. Ты бы еще ДОС вспомнил, которая с производства снят.

Ну где же результаты для Win7?

>Ну дайте мне rdesktop на Win7 с компилятором, поглядим что там... Дело-то нехитрое.

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

> Ты бы тут не игрался с виндой, а лучше бы пошел да умом занялся,

поддерживая своих опенсурсников.

Что, как очередной глюк в винде нашёлся, так сразу не надо её трогать, надо идти линукс пилить? :)

Конечно Вам надо идти пилить Линукс. Раз уж Вы так хорошо разбираетесь в данных вопросах, то и исправьте это позорище с синусом. Покажите виндузятникам скорость исправления ошибок опенсорсным сообществом.

> Эти синусы - это же даже не дыра, а огромная дырища с точки зрения

математических вычислений.

...

Может попросить квалифицированных программистов Майкрософта потратить

пару часов и исправить glibc

C:\Drova>sin_test.exe
sin(4.3998769152000000e+010) is -4.0819367251002277e-009

Не, лучше не надо. Они наисправляют...

Это Виндовс 7 с последними обновлениями? Или виндовс 2002 года?

> Конечно Вам надо идти пилить Линукс. Раз уж Вы так хорошо

разбираетесь в данных вопросах, то и исправьте это позорище с синусом.

Так у меня-то с синусом всё в порядке. И на x86, и на MIPS.
Что я в багзиллу писать буду?
«Вы знаете, тут на ЛОРе у какого-то анонимуса glibc в убунте синусы неправильно считает».

Это XP SP3 Других виндовсов доступных у меня не нашлось.

На Win7 что-то никто не хочет тестик прогнать.

Скомпилённый еxe'шник не предлагаю, на винде это вроде как неприлично.

>сначала выпустили 387. потом через достаточно продолжительное время оказалось, что он неправильно (с недостаточной точностью) считает синус и косинус при определённых диапазонах аргумента. т.к. сопроцессоров уже было выпущено дофига, и софт подстроили под этот глюк, то в следующих сопроцессорах fsin и fcos решили оставить как есть, с ошибкой.

Что-то незаметно, что софт подстроили под этот глюк. Линукс до сих пор не подстроен, хотя эта ошибка идёт с 387 процессоров, то есть с середины 80-ых годов, это если вам верить. Т.е. критические ошибки в Линуксе не исправляются по 25 лет! Он уже дефектный родился и так им и остался.

>Что я в багзиллу писать буду?

Да вы оказывается просто халявщик, батюшка, а не фанатик-линуксоид? В Винде 2002 года ошибки-это ОС виновата, те же ошибки в Ляпихе-Интел.

А, можно проще сделать.

На этой XP SP3 версия msvcrt.dll - 7.0.2600.5512
Размер - 343040 байт.

А на Win7 какая версия?

>Это XP SP3 Других виндовсов доступных у меня не нашлось.

Сколько вы зарабатываете, что не можете купить приличную ОС?

> Т.е. критические ошибки в Линуксе не исправляются по 25 лет! Он уже

дефектный родился и так им и остался.

У меня нет ошибки в Линуксе.
Есть в винде и у какого-то анонимуса в убунте.
Мне надо анонимусу с убунтой исправить ошибку?

О чем спор? Венда вся такая плоха и криваю, но ее успешно юзают на линейных ускорителях и атомных электростанциях, бла-бла, линукс при всей моей любви к нему, остается ос для роутеров, многоядерных серверов и игрушкой, якобы «для работы». И только законченный фанатик будет спорить.

Такие уж реалии серьезной работы. Заплатил деньги - получил качественный, продукт с поддержкой, а не «свободный, сообщество, открытые коды, блабла».

7.0.7600.16385

> Сколько вы зарабатываете, что не можете купить приличную ОС?

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

Скорее всего то же самое с синусом.

Это ж Вы давали такую ссылочку?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43490

Этой ошибке в GLIBC уже скоро год. И до сих пор никто не закрыл. Вот оно во всей красе - опенсорсное сообщество. Ошибка в процессорах существует с 80387 (по словам Stanson) и значит с середины 1980-ых, обнаружена же ошибка в Линуксе лишь в 2010 году и до сих пор не исправлена. Это хуже, чем бюрократия корпорации Микрософт.

т.е. Интел уже третий десяток лет штампует процессоры с ошибкой и никто из разработчиков ПО на это не обращает внимания? Даже линуксоиды не хотят показать свои способности по скоростному закрытию дырок.

> О чем спор?

Да нет никакого спора. Вот, анонимусы выпендривались-выпендривались и довыпендривались, в винде синус кривой оказался.

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

Вообще-то это багзилла gcc.
А gcc тут не при чём. Он-то как раз правильно считает в своём препроцессоре.

Почему пользователи убунты не отписали о баге в нужное место, я не знаю. Видимо, такое у убунты сообщество.

>О чем спор? Венда вся такая плоха и криваю, но ее успешно юзают на линейных ускорителях и атомных электростанциях, бла-бла, линукс при всей моей любви к нему, остается ос для роутеров, многоядерных серверов и игрушкой, якобы «для работы». И только законченный фанатик будет спорить.

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

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

Взаимно надеюсь, что в серьёзном софте под Линукс используют свою математическую библиотеку, а не дырявую glibc, которую никто не хочет исправлять уже почти год.

>>>Да нет никакого спора

Я уже писал, где эта самая винда используется. К примеру тот же ускоритель. Неужели вы думаете, на оборудовании, от которого зависит качество и длительность жизни человека, будут использовать систему, в которой, по субубо вашему мнению, полно ошибов и вообще глючит каждые 5 минут?

Не находите это несколько нелогичным?

> т.е. Интел уже третий десяток лет штампует процессоры с ошибкой и

никто из разработчиков ПО на это не обращает внимания?

Почему не обращают? Именно из-за этой ошибки и есть всякие __FAST_MATH__ и workaround'ы в библиотеках. Другой вопрос - накой убунтоводы собрали glibc с включенным fsin?

>Видимо, такое у убунты сообщество.

Systems that were found to be broken:
gcc 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
gcc 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)
GNU C 4.3.2 (i686-pc-linux-gnu) (Gentoo 4.3.2-r3 p1.6, pie-10.1.5

Дебианщики, гентушники и убунтовцы сидят в луже с кривым синусом.

> Неужели вы думаете, на оборудовании, от которого зависит качество и

длительность жизни человека, будут использовать систему, в которой,

по субубо вашему мнению, полно ошибов и вообще глючит каждые 5 минут?

Во-первых, я не писал, что винда глючит каждые 5 минут. И не писал, что в ней полно ошибок. Я писал о том, что в ней есть ошибки, и что периодически я с ними сталкиваюсь. Вот прям в реалтайме только что столкнулся, до сегодняшнего дня думал что с математикой в винде всё в порядке. Не ахти какая ошибка, но тем не менее.

Что до того, будут использовать или нет - на территории СНГ будут даже описанную Вами «глючащую каждые 5 минут» использовать, если на этом кто-то получит выгоду. Не всегда, конечно, но с очень большой вероятностью.
Кроме того, Вы же сами сказали, что в Вашем случае на винде только расчёты гоняют, а это не так критично, даже если оно будет всё время падать.

>Именно из-за этой ошибки и есть всякие __FAST_MATH__

__FAST_MATH__ (ключик -ffast-math) не помогает. Результат тот же. Потому что он не для этого предназначен.

Этот #define я обнаружил в uClibc который на x86 отключает при сборке uClibc использование fsin
Как дело обстоит в glibc и будет ли толк от использования ключиков при сборке софта использующего glibc я не знаю.

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

В моем случае это не только расчеты, а и лазерная разметка и собвственно управление процессом. И да, дейтсвительно, какая разница, если возникнут ошибки, ну подумаешь, облучим мы пациенту не предстательную железу, а мочевой пузырь или прямую кишку. Ну помучается 2 недели с циститом. Это же не критично.

В таком случае хотелось бы узнать, где такое творится. Чтобы никогда туда не попасть.

Итак, почти год известна ошибка в Линуксе с синусом. Обнаружена в Дебиане, Генту, Убунте. И что говорите Вы, расхваливающий Линукс и его надёжность и непадучесть? Что у Вас этого нет и проблема это не Ваша, что это вообще Интел во всё виновата. Поэтому с Линуском всё в порядке.

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

А с чего все начиналось? С заявувления «операционная система говно, если ее (винду) нельзя поставить на роутер»...

Во-первых, я не писал, что винда глючит каждые 5 минут. И не писал, что в ней полно ошибок

Конкретно вы не писали этого. А что должно означать заявление, что «„виндовс только для домохозяек“ и „Хотел требовать немедленного разглашения местоположения этого ужаса, в целях безопасности“?

>>>В таком случае хотелось бы узнать, где такое творится. Чтобы никогда туда не попасть.

Такое творится во всех онкологических клиниках, да еще и во всем мире.

Понятно, спасибо. Раком постараюсь не болеть.

Простейший пример с картинками: http://www.lissod.com.ua/ru/about-us/equipment/

Все это (о, ужас!!1) управляется виндой.

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

А теперь представьте, что это оборуование начнёт работать под Линуксом с его кривыми синусами. Ошибки во вычислениях быстро приведут к плачевным результатам.
Вот и рухнул миф о том, что если исходники открыты, то ошибки исправляются моментально. Критическая ошибка висит почти год как минимум.

>>>Понятно, спасибо. Раком постараюсь не болеть.

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

> А с чего все начиналось? С заявувления «операционная система говно,

если ее (винду) нельзя поставить на роутер»...

Не-а. Начиналось всё с того, что микрософт внезапно решил, что его винда - это универсальная ОС. Впихнув своего кренделя в топ менеджмент Нокии, микрософт навешал остальному топ менеджменту лапшу на предмет универсальности винды и пригодности её не только для десктопов, но и для всего прочего. То, что это лапша - несложно догадаться, потому как универсальная система, которая не может решать элементарные задачи не может быть универсальной. Если заявляется о применимости винды в embedded секторе (а телефоны это пока ещё embedded), то она обязана работать в простейших вариантах embedded. Роутер - это фактически тот же телефон, только без экранчика и размером побольше. А объём памяти, периферия и пр. - как раз соответствуют телефонным. И вот оказывается, что эта якобы замечательная винда для embedded никак не может работать на роутерах, зато может работать на телефонах.

А что должно означать заявление, что «„виндовс только для домохозяек“

и „Хотел требовать немедленного разглашения местоположения этого

ужаса, в целях безопасности“?

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

>>>менеджменту лапшу на предмет универсальности винды

http://www.debian.org - в шапке написано «универсальная». Покажите мне то же, с виндовсом?

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

А теперь задайтесь простым вопросом, почему критические приложения написаны для «ненадежной системы», вместо супернадерного линукса?

Вообще-то на http://www.lissod.com.ua/img/st_img/equipment/165/big/2.jpg
на крайнем слева мониторе ни разу не виндовс. :)

Наверно это и есть управление девайсом?
Ну не будет серьёзный производитель поручать управление движением такой дуры винде. Я так понимаю вся махина может как минимум поворачиваться вокруг пациента. Дык вот, решение этой задачи поручать винде - верный способ угробить аппарат. В винде нет реалтайма, а чтобы управлять двигателем, способным крутить такую дуру реалтайм просто необходим. Задача весьма непростая и винде она не под силу. Так что управляется оно либо отдельным достаточно умным контроллером, либо вот той штукой, со странным интерфейсом.

Под винду есть некое подобие motion controller'а. Mach3 называется. Для хоббистов со станками с ЧПУ.
Но до линуксячьего EMC2, который с реалтаймом (RTAI) ему как до луны. Вот EMC2 - уже может управлять двигателем такой штуки - с плавным разгоном и торможением, с отработкой инерции и люфтов и т.д. Да и то, я бы поставил отдельный узкозаточенный контроллер с кучей дублирования и контроля.

>>>Вообще-то на http://www.lissod.com.ua/img/st_img/equipment/165/big/2.jpg на крайнем слева мониторе ни разу не виндовс. :)

С каких пор операционную систему начали определять по скриншотам? Может и на банкоматах не виндовс, потому что там нет кнопочки «пуск»?

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

4.2 в чистом виде. Или ты как и все красноглазые путаете десктопную и эмбедед винду? Вообще и линакс и винда обеспечивают soft RT - hard RT это не к ним, это к чему-нибуть типа QNX. Но он на таких задачах и не нужен.

> А теперь задайтесь простым вопросом, почему критические приложения

написаны для «ненадежной системы», вместо супернадерного линукса?

Ознакомившись с фотками, я не уверен, что винда управляет чем-то действительно критическим. Выдавать несколько циферок для контроллера агрегата, да ещё с контролем человеком (посмотреть, проверить, в правильное ли положение оно встало) - может быть. Но управлять тем, что показано на снимках - винда никак не сможет. Уже только на motion control двигателя поворота агрегата она не справится.

>>>Ознакомившись с фотками, я не уверен, что винда управляет чем-то действительно критическим. Выдавать несколько циферок для контроллера агрегата, да ещё с контролем человеком (посмотреть, проверить, в правильное ли положение оно встало) - может быть. Но управлять тем, что показано на снимках - винда никак не сможет. Уже только на motion control двигателя поворота агрегата она не справится.

угу, с «я не уверен» надо было и начинать.

> 4.2 в чистом виде.
Хде?
В винде есть реалтайм?
Чтобы точно позиционировать двигло с приличной массой на валу не нужен реалтайм?

Или ты как и все красноглазые путаете десктопную и эмбедед винду?

Мне достаточно информации о том, что они от одного производителя.

Вообще и линакс и винда обеспечивают soft RT - hard RT это не к ним,

это к чему-нибуть типа QNX.

4.2 в чистом виде. RTAI - hard RT на линуксе.

Но он на таких задачах и не нужен.

4.2 опять же. Для motion control необходим hard realtime. Да чего там, даже в поганеньком струйном принтере - и то hard realtime необходим, чтоб двигателями крутить, а тут такая дура здоровая.

>Уже только на motion control двигателя поворота агрегата она не справится

Вроде бы игрушки-открывашки для машин делаешь, а тут такой бред несешь.

> угу, с «я не уверен» надо было и начинать.

Т.е. Вы утверждаете, что приложение под виндой читает сигнал с датчика энкодера положения агрегата, тут же, учитывая массу, люфты, дисбаланс и пр. тут же вовремя выдаёт напряжение на силовой мост двигла? А в самом агрегате нет ни одного мелкопроцессора?
Извините, я в это никогда не поверю.

> Вроде бы игрушки-открывашки для машин делаешь, а тут такой бред

несешь.

Игрушки я для себя делаю. А чтоб денег заработать - я делаю совсем другие вещи.
Бред - это делать motion control на винде. Вот это действительно БРЕД.

Сложно спорить с человеком, который не способен признавать что-то, что что ему не нравится. Как спорить, если для Вас «виндовс не ОС» - аксиома? Я же предпочитаю более не тратить время на бесполезное занятие.

> RTAI - hard RT на линуксе.

Это ни hard RT ни разу. На линаксе он в принципе невозможен.

В винде есть реалтайм?

Более 10ти лет как - есть. Почитай, специально для тебя - на русском, http://citforum.ru/operating_systems/rtx/index.shtml

4.2 опять же. Для motion control необходим hard realtime.

Нафиг не нужен. Шаговый движок, да.

>Бред - это делать motion control на винде. Вот это действительно БРЕД.

И чем это Линукс координально лучше Винды тут? Заюзай тот же гугль и убедись в том, что РТМ в Винде ХР есть еще с тех пор, как Линукс в консоли сидел.

> Заюзай тот же гугль и убедись в том, что РТМ в Винде ХР есть еще с тех пор, как Линукс в консоли сидел.

Вообще-то он там был со времен NT4, то есть более чем за 5 лет до выхода XP. и в XP его к слову не было - он был в embeddet nt.

Просто наш опонент говорит об ХР виндах, думая о том, что это и есть основной сервер управления.

> Сложно спорить с человеком, который не способен признавать что-то,

что что ему не нравится.

Угу. Мне не нравится, что убунта неправильно считает синус из-за ошибки в системной библиотеке. Тем не менее, об этом присутствующие узнали с моей помощью. При этом, видимо, как-то так получилось, что я не признал, что в убунте имеется ошибка в системе.

Что с логикой-то?

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

Может они для Вас невозможны в принципе. Я же продолжу лечить людей с помощью «в принципе невозможных» вещей.

> И чем это Линукс координально лучше Винды тут?

Тем, что для него есть RTAI. А для винды - нет.

РТМ в Винде

Это рекламная чушь, начиная с NT. Жёсткий реалтайм был возможен в Win95/98/ME. Правда, всё остальное при этом работать переставало.

>>>Жёсткий реалтайм был возможен в Win95/98/ME

Так, погуглил малость. http://b2blogger.com/pressroom/release/67030.html 2099 год, поддержка вин7, сервис пак 2...

Как оказалость, они делают сервис паки для " в принципе невозможных вещей, которых в виндовс нету". Учту на будущее.

>>>В винде есть реалтайм?

Жёсткий реалтайм был возможен в Win95/98/ME

Не противоречит ли один пост другому? В одном реалтайма нету, в другом он неожиданно есть. Как понимать?

Бла-бла-бла...
worst case latency где?
У меня с RTAI 5мкс. При полном доступе ко всему API.
А что там микрософт обещает?
Хотя бы без Win32 API?

Хм.. на топовых моделях GEC томографов стоит RedHat он же стоит на КТ И МРТ Siemens, хотя и не на всех..

Ага,его же 20 постов назад небыло? Откуда же «в принципе невозможная» вещь появилась?

> Не противоречит ли один пост другому? В одном реалтайма нету, в

другом он неожиданно есть. Как понимать?

Ну в Win95 и т.д. жёсткий реалтайм реализовывался тупо однозадачностью.
Сегодня это смешно.

У нас только на одном КТ сименсовом линух.на 32-срезовом. Остальное на винде. 64-срезовый на винде, он же в комплексе с ускорителем пашет.

worst case latency где?
И условия при которых оно возможно.

Когда-то на NT4 вроде бы когда-то кто-то аж 100 мкс добился, без сети и без Win32 API.
Извините, но это издевательство какое-то, а не хард реалтайм.

Не, может я чего не знаю, и нынче винда совершила некий прорыв в реалтайме, и теперь он юзабелен и даже обещают сносные latency.
Я давно не следил, что там происходит, расскажите, я порадуюсь за
винду.

Тогда о чем спор то ?.. К чему утверждение, что Linux'у не место на критичном к сбою железе и т.п. ?

>>>жёсткий реалтайм реализовывался тупо

недавно утверждали, что его нету вообще и он в принципе невозможен. Как определитесь, так и приходите.

> Жёсткий реалтайм был возможен в Win95/98/ME. Правда, всё остальное при этом работать переставало.

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

>>>Тогда о чем спор то ?.. К чему утверждение, что Linux'у не место на критичном к сбою железе и т.п. ?

Совсем не о том спор. Дело наоборот обстоит. Бывует утверждение, что Виндовсу не место на критичном к сбою железе.

>>>Тогда о чем спор то ?.. К чему утверждение, что Linux'у не место на критичном к сбою железе и т.п. ?

Да, соглашусь, некоторые посты можно вопринять двусмысленно. Я обеими руками за появлению оборудования на линухе. Еще бы программные комплексы сделали.

sin(43998769152.000000) = 0.951056516

Мда, анонимус уже не торт.

Реализация жесткого реалтима сильно упростилась с появлением многоядерных процессоров.

http://www.intervalzero.com/rtx.htm

http://www.intervalzero.com/imgs/rtx-2011.gif

>Бывует утверждение, что Виндовсу не место на критичном к сбою железе.

Бывует утверждение, что прыжкам без парашюта не место при экстренной эвакуации из самолёта.

Набор твоей аргументации несколько странен

Заплатил деньги - получил качественный, продукт с поддержкой

С этим согласно большенство вменяемых людей, но почему ты решил что это относится только к винде и всему закрытому, не общественному, не свободному? Навскидку: Red Hat, Oracle, - у них есть и отрытые коды под свободными лицензиями, и сообщество, при этом они продают качесвенную поддержку за деньги и предоставляют продукты высшего качества.

остается ос для роутеров, многоядерных серверов и игрушкой, якобы «для работы»

Это уже явный троллинг.

>>>Это уже явный троллинг.

Нет, не троллинг. Перебор - да. Прошу прощения.

Баги по этой проблеме нужно искать не в багзилле gcc, а в багзилле libc:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=10709
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3976

Прочёл таки пропущеные сообщения в теме.

Узрел... Ох?ел...

RTAI - hard RT на линуксе.

Это ни hard RT ни разу. На линаксе он в принципе невозможен.

Уважаемый коллега-анонимус. Я вынужден Вам заметить что Вы являетесь полным, конченным, хроническим идиотом. Ибо такое утверждение можно выдать либо по полной безграмотности (но тогда членали Вы здесь позабыли?) либо по причине клинического идиотизма.

Да будет Вам известно, что RTAI это как-раз таки интерфейс, шедьюлеры (их там не один) для как раз таки real-time в Linux. Правда, надо заметить, что вариантов построения real-time систем в Linux гораздо более одного. Здесь можно вспомнить и MontaVista и rtirq-patch от Bernhard Kuhn из Метроверкс. И ещё много чего и кого (того же Инго Молнира с его патчами -> http://www.kernel.org/pub/linux/kernel/projects/rt/ патчи здесь). RTAI на данный момент (и уже довольно давно) является наиболее известным и, пожалуй, наиболее удобным вариантом реализации. И именно он и есть тот самый hard RT, о невозможности коего Вы тут так сильно бредите (кстати, кто там поближе — вызовите парню санитаров, чтоли?).

Далее. Я Вас могу откровенно развеселить тем, что RTAI по своей сути предполагает исполнение кода в KERNEL space. Есть вариант для user space, но он распространён меньше — LXRT/NEWLXRT. Но оно зачастую медленнее само по себе, по этой причине на практике, если и используется, то сравнительно редко. Например, те же семафоры в kernel space обрабатываются намноооого быстрее.

Впрочем, здесь важнее другое. Механизм обработки прерываний и иных событий, при чём аппаратные прерывания имеют решающее значение может быть в RTAI как SOFT, так и HARD. И определяется реакция именно программистом. А RTAI просто предоставляет для этого необходимый набор механизмов. Но для _ВСЕГО_ ядра.

Если говорить о windows embedded (точнее всё-таки, wince), то да. По маркетинговым заверениям M$, оно с 3-й версии (где-то 2000г.) типа реал-тайм. Вроде как сейчас winxp embedded на дворе. Но система это отдельная, ветвь от общего дерева windows, а не то, что получено из стандартного варианта путём наложения патчей (как в случае с RTAI). Такой подход для винды невозможен в принципе, т.к. ядро (а патчится должно именно оно) закрыто, проприетарно и отправлено очень давно и очень далеко. Максимум, куда можно тут добраться это HAL. Но HAL это не ВСЁ ядро. Это просто одна из подсистем ядра винды.

Ладно. Продолжаем... Ща будет... :)))

Более 10ти лет как - есть. Почитай, специально для тебя - на русском,

ЛОЛШТО??? Много и глубоко уважаемый ЛОР, где вы этого тролля откопали?!? :)))))

Во-первых, я откровенно ржу от «авторства». ИПМ РАН это сильно... Это просто «альфа и омега» _практики_ embedding'а в России и ex-USSR et al. Но оставим этих болезных на голову в стороне... :))) Убогих, вообщем-то грешно бить.

Во-вторых. Позвольте осведомиться? Вы сами-то ту (как бы по-мягче) «херню», на которую здесь ссылаетесь читали? Судя по всему нет... Ибо тогда не могли бы не заметить следующего пассажика:

http://citforum.ru/operating_systems/rtx/gl_1.shtml#2

После установки RTX стандартная NT Workstation или Server превращается в операционную систему реального времени с жестким детерминизмом (hard real-time). Сама NT об этом, правда, не подозревает. Ни ядро, ни исполняющая подсистема NT не были изменены.

Всё. Занавес. Где Вы тут соизволили найти real-time на уровне системы (с планировщиками, т.к. от них охрененно много зависит) мне в упор не ясно. Не поясните, что ж это за real-time-то такой? Система by itself не реалтайм, но она превращается в операционную систему реального времени?

/* Нет. Я всегда знал что наши «жрецы науки», не имеющие ровным счётом ни какого практического опыта курят что-то явно не то, но я не подозревал что _настолько_ «не то». Или это были грибы? 8-| */

Нафиг не нужен.

Милейший, Ваш вывод относительно себя офигенно правильный. Вы — с таким уровнем «знаний» на фиг не нужны.

ДА, ты тупой, как валенок. Препроцессор не обладает возможностями вычисления тригонометрических (и других вообще) функций. Ещё раз слив.