Ако приемем, че имаме ей тоя код:

int not_finished = 1;
while(no_finished) { blah; }

И not_finished може да стане 0 от друг тред, то има ли проблем? И ако мислите, че има, то какво е решението.

P.S И за тъпите путки, дето ще почнат да спорят за някакви детайли, изрично казвам, че този код ще бъде компилирам от optimising compiler.

Розова бе зората на битката като зашлевено дупе на девица

Редактирано от chichiman на 29.07.14 12:06.

Кви детайли бе, елементарни познания нямаш, ти еба неграмотното пишлеме ти еба! Само не казвай, че си булгар, че излагаш стотици хиляди други!

"Има ли проблем, и какво е решението" - все си мислех, че не можете да ме шашнете с малоумие! Решението е да си намериш работа като нощен пъдар!

п.с. ЩО СЕ УМЪЛЧАХТЕ С ДИФАЙНИТЕ, бе лайнар? Няколко теми напълнихте с мангусарник заради очевидно и елементарно нещо, и накрая ми мълчиш като затапен гъз бе! Боклуци! Да ме е срам да си кажа занаята заради арогантни недоносчета като вас

Съдържаниет е скрито
Влезте за да го видите

Редактирано от rabin на 29.07.14 12:13.

К'во да мълча, ти не можеш да си артикулираш мислите, диалог с теб е безсмислен. И по-полека да не burn out-неш...

Розова бе зората на битката като зашлевено дупе на девица

Редактирано от chichiman на 29.07.14 12:14.

Колко байта генерира в изходния файл един #define, бе нещастник? Последно колко останаха?
п.с. Улеснил съм ви като маймуни - интересува ме нула или различно от нула. Не конкретна стойност.

Редактирано от rabin на 29.07.14 12:17.

Ако няма какво да кажеш по _ТАЗИ_ тема, защо пишеш?

Розова бе зората на битката като зашлевено дупе на девица

Имам какво да кажа - такива междутредови взаимодействия стават през volatile променливи, говоря за език С. И няма проблем.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

И какво за volatile, обясни, хвърляш една дума и до там. Научи се да се изразяваш правилно.

Съдържаниет е скрито
Влезте за да го видите

Оф, забравих, че комуникирам с дебили.
Тоя "int" си го декларираш "volatile int" - и нямаш проблем.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Защо?

Розова бе зората на битката като зашлевено дупе на девица

Защото volatile е мислено за тия неща (не само). Не се подлага на оптимизациите на компилатора, за това е мислено, за каквото питаш.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Трудна ти е комуникацията с хората, виждам, дееееба боклика, връй яж на спиндерман спермоча

Съдържаниет е скрито
Влезте за да го видите

Трудна ми е комуникацията само с олигофрени!
Айде цалувай ръка и отивай на обяд, щото аз тоя "проблем" съм го имал и на най-елементарните процесори за 3 лева - AtTiny. Aко въобще са те пуснали до реален чип и компилатор.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

То зависи дали в блах имаш записи по тая променлива. Ако нямаш записи, практически няма проблем. Също зависи и как се става нула, дали е с присвояване или аритметизно. Теоретично ще има проблеми където нещата може да не се обновят съвсем навреме, обаче за такъв код - толкоз. Ако в блаха има писане, тогава и волатиле няма да те спаси.

Съдържаниет е скрито
Влезте за да го видите

и немаш грижи, иначе така както е дста вероятно ще цикли завинаги




NE SUTOR ULTRA CREPIDAM

Kомпилаторите по принцип избягват да кешират глобални променливи в регистри (gcc поне е доста консервативен в това отношение), та че може и да не зацикли. Ама не бих разчитал на това силно.

EOF

е мене ми е зацикляло, хич даже и не бих разчитал че била глобална.




NE SUTOR ULTRA CREPIDAM

абе бачка си и на интел и гцц. и се ползва, не е като да не се ползва.




NE SUTOR ULTRA CREPIDAM

Има една тенденция на дедо и агитка имбецили. Вероятно сте си го написали на герба. "Не е така, ама не знаем как е!"
Чичото на 2 пъти оспорва линкове, без да даде алтернатива.
Кво ли се учудвам?
п.с. Volatile работи на компилаторите, с които съм работил. Не знам да има и един за ембед, писан от М$. Може и да има, аз не съм чувал.

Редактирано от rabin на 29.07.14 14:40.

По принцип и аз този отговор очаквах, защото volatile в случаят казва на компилатора да не прави оптимизации в/у тая променлива. Тоест винаги да я fetch-ва от памета и да не я елиминира.

А точно пък за ICC не отварайте дума, защото реално това е benchmarking compiler (такъв, който е направен да блесва по разните бенчмаркове като SPEC), който има под 3% дал в реалният свят ;)

Розова бе зората на битката като зашлевено дупе на девица

Редактирано от chichiman на 29.07.14 14:43.

Няма спор, и аз не бих разчитал.

EOF

Не разбрах само.
Ти съгласен ли си с това, което съм написал или не си съгласен?

Ми то не е далеч от акъла - ако не беше така нямаше никой да се хаби да прави мутекси, семафори, кондварове и тем подобна синхронизационна сган дето отдолу работи с атомарни операции. Щеха да си циклят на някоя volatile променлива и всичко да е 6.

EOF

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




NE SUTOR ULTRA CREPIDAM

И не само атомарни ами и бариери

Розова бе зората на битката като зашлевено дупе на девица

Гледам чак до операционни системи сте го разпънали.
На мен ми върши работа за въшки с 200 байта рам и 2К флаш.
При по-дебели задачи с нарочена ОС - нещата седят според зависи.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

добре е да има едно static отпреде за да е в хийпа, щото некои системи имат навика да местят стекове.

И не правильно думать, что есть чьим-то богом обещанный рай...

статик нещата не одят точно у хийпа.

EOF

Сега що ме карате да измислям примери:

#include <stdio.h>

volatile int not_finished = 1;
int result = -1;

/* execute from another thread */
void set_finisned()
{
________result /= 100;
________not_finished = 0;
}

int main()
{
________while(not_finished) {
__________// blah
________}
________printf("%u\n", result);
________return 0;
}



Може да си мислите, че result е нещо много по-сложно.
Това ще работи ли под GCC -O2?

ВРЪЙ чети за .bss, че и ти си бетер рабинягата

Розова бе зората на битката като зашлевено дупе на девица

Само ти напомням, че последно тази сутрин ти сам разбра, че си неграмотен.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Тук volatile ти трябва, за да не реши компилатора направо да ти премахне not_finished и да го замести с константа. А иначе, ако пипаш result в //blah, то има race със set_finished.

Розова бе зората на битката като зашлевено дупе на девица

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

Розова бе зората на битката като зашлевено дупе на девица

И продължаваш да твърдиш, че #define A 10 генерира код за контролера? Това написа преди малко.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Пейстни кода

Съдържаниет е скрито
Влезте за да го видите

какво точно се очаква?
със сигурност ще излезе от цикъла, което е разумното очакване за да кажем че работи (не го заменя с регистър). предполагам очакваш освен всичко и result да се разпечата 0 а не -1, това вече няма гаранция.




NE SUTOR ULTRA CREPIDAM

Няма как компилатора да ми замести not_finished с 1 след като го сетвам на друго място в кода.

И в //blah не пипам result.

Напротив, когато имаш много нишки и не е очевадно за компилатора как точно сетваш тая променлива от нишка е напълно валидна трансформация.#

Даже още по-избочено:

Съдържаниет е скрито
Влезте за да го видите

Редактирано от chichiman на 29.07.14 16:18.

Моя компилатор генерира това:

00000000004004a0 <set_finisned>:
mov 2098202(%rip),%ecx # 6008c0 <result>
mov $0x51eb851f,%edx
movl $0x0,2098183(%rip) # 6008bc <not_finished>

mov %ecx,%eax
sar $0x1f,%ecx
imul %edx
sar $0x5,%edx
sub %ecx,%edx
mov %edx,2098169(%rip) # 6008c0 <result>
retq
nopl 0x0(%rax,%rax,1)


00000000004004d0 <main>:
sub $0x8,%rsp
mov 2098146(%rip),%eax # 6008bc <not_finished>
test %eax,%eax
jne 4004d4 <main+0x4>
mov 2098140(%rip),%esi # 6008c0 <result>
mov $0x4005f8,%edi
callq 400398 <printf@plt>
xor %eax,%eax
add $0x8,%rsp
retq

Кой е тоз, твоят компилатор? Пробвай без voaltile да видим дали пак ще джъмпваш при main+04, което трябва да е старта на лоопа ако не се лъжа aka постоянно цикли върху променливата за да види дали не е променена.

Розова бе зората на битката като зашлевено дупе на девица

Редактирано от chichiman на 29.07.14 16:36.

Що не би разчитал. Глобална променлива дори и да отиде в регистър евентуално се връща в паметта. Няма друг начин при тях. Ако зацикля това нещо няма да е заради регистър оптимизации, а заради корупция на някоя сметка.

Съдържаниет е скрито
Влезте за да го видите

Ми нека се записва в паметта, ама като няма кой да го зареди пак в регистъра, ще си цикли до откат.

EOF

Ти можеш да си го гарантираш без волатиле.
// Type your code here, or load an example.
#include <stdio.h>

int not_finished = 1;
int result = -1;

/* execute from another thread */
void set_finisned()
{
result /= 100;
not_finished = 0;
}

int main()
{
while(not_finished) {
not_finished=not_finished;
}
printf("%u\n", result);
return 0;
}

Съдържаниет е скрито
Влезте за да го видите

Не съм много убеден че това ще свърши работа. Според мен е по-вероятно компилаторът просто да го оптимизира това присвояване и да го отсвири. Ама знам ли...

EOF

ОК. Прав си.

Но въпреки това volatile не те спасява от out-of-order

Бе нещо подобно все ще свърши работа. Важното е да има писане.

Съдържаниет е скрито
Влезте за да го видите

а къде?

И не правильно думать, что есть чьим-то богом обещанный рай...

Зависи дали са инициализирани или не, но и в двата случая е някъде между хийпа и .text-а.

EOF

Къ ше бъде компилиран

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ся, пръво, както са казали малко по-горе, тва компилатора нема да го компилира до нищо, щото има печатна грешка.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Може да пробваш да пишеш и четеш глобалната променлива индиректно чрез указатели към нея, gcc-то поне много се бъгва от такива неща, чупи му великите предположения свързани с alias-ването и се сдухва със смелите оптимизации, та може и да го излъжеш да зарежда и да пише в паметта и без да е volatile. Ама това е от категорията "еба ли му майката", тъй де "квантова физика".

EOF

код сегмента обикновено е рийд-онли, пич.

Съдържаниет е скрито
Влезте за да го видите

Тъпишонка, думата "между" знаеш ли какво значи?

Розова бе зората на битката като зашлевено дупе на девица

Ей, тръгнало да обижда всичко живо по списък, а последно се дрисна днес, и то колосално, за елементарен въпрос.
Предпоследно се дрисна миналата седмица.
А всичко започна с това:
chichiman:
Не се нерви, аз ще си бия кура в устата ей така, за спорта :)

Съдържаниет е скрито
Влезте за да го видите

Събрали сте се един катун некадърници тук и връз един-друг гледате да изцепите по-голяма глупост. Само че тия номера не минават :)

Розова бе зората на битката като зашлевено дупе на девица

Отговори ми на въпроса, то се види кой е некадърника.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Хич недей разчита, ще зацикли от раз, включително с гцц.
Естествено, сега може да кажеш - пробвах и стана. Да, ако нямаш късмет ще изглежда, че работи, но е съвсем вероятно да те боли на по-късен етап.

Нещо не си убедителен - как така ще е 6, като яде от процесорното време на други нишки/процеси, освен това и харчи много ток?

Сложи в цикъла един usleep и няма да харчи толкова ток и да яде от процесорното време.

EOF

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




NE SUTOR ULTRA CREPIDAM

сега, направо ще ти го кажа, без volatile някои неща стават невъзможни, нищо че имаш мутекси и семафори и какво ли не, InterlockedIncrement не може да се замести с lock();i++;unlock().
забележи,

Съдържаниет е скрито
Влезте за да го видите

Няма да харчи _толкова_ ток и процесорно време. Ако спиш повече - ще реагира бавно. Т.е., в най-добрия случай ще трябва да тунинговаш времето за слийп.

Тая задачка я дават на кандидат-новобранци програмисти. Приеха ли те, как мина интервюто?

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Има и други похвати - могат да се ползват бариери вместо volatile.
Ето ти вариант на InterlockedIncrement без volatile, който също работи и е използваем, но трябва да внимаваш и например да сложиш бариери на правилните места, за да не настъпиш мотиката:

LONG ii2(LONG *x) { return InterlockedIncrement((volatile LONG *)x); }
...
бариера();
ii2(&alabala);
бариера();
...

като в дори в някои случаи ii2() ще има предимство пред InterlockedIncrement() - бариерите може да ги сложиш по-далеч и да оставиш компилатора да оптимизира това-онова.
В някои случаи може и да е и с недостатъци, но като цяло бариерите са по-мощни от volatile.

е не, ти много миришеш, чиче.

И на тебе ли персонално да цитирам какво изака чичомен оня ден? Дира се напълни с турбо неграмотници, нагли за сметка на това!
Дразни ли ви, бе, агитката на дебилчетата, че не всички са като вас?

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

не знам за кво говориш, просто миришеш.

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




NE SUTOR ULTRA CREPIDAM

Ходи на доктор, щом усещаш миризми от монитора си.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

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

Aз ли съм виновен, че сте неграмотни дебили?

Аз:
Колко байта генерира #define ENABLE_INTERRUPTS() asm volatile ("disi #0x0000")


чичомен:
Окей, ей сега хвърлих един поглед на ISA-та, инструкцията заема 24 бит-а, като opcode e variable length. Така че, пак ще изгенерира повече от 0 байта, както ти твърдиш ;)

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

неграмотни дебили, така е, но такива сме изгодни на корпорациите, само Партията дето я плюеш за концлагерите можеше и може да осигури истинско просвещение. кога ще се осъзнаеш рабине? кога ще откриеш истинското си аз, жадуващо да тика неграмотните дебили в концлагери?




NE SUTOR ULTRA CREPIDAM

Е то и рабинката е учил по комунистическо. Безплатно.

чети и дишай по-леко

Съдържаниет е скрито
Влезте за да го видите

Много сложна концепция му вкара, той лагер не зане що е, а за концлагер направо ще му прегрее цпу-то.

няма да прегрее - нали сам си е писал драйвера на препроцесор.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

не знам, не мога ти отговоря на тоя въпрос.

Tи що се буташ зорлем при дебилите, нямам наблюдения да си неграмотен като имбецилите на дедо.

Не съм искал да тикам никого в лагер.

Към останалите, дето продължавате да мърморите като бабка, пререждаща опашката пред личния лекар:
Мълчанието ви по техническите казуси говори само по себе си. Знаете си, че сте неграмотни, то се вижда, че го осъзнавате. Де да имаше сила да ви накара да спрете да цапате всички теми...

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

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

Съдържаниет е скрито
Влезте за да го видите

Да ти напомня кой се е дриснал. Не само ти, ами групичката ви дружно. Ако знам, че има грамотен да разчете изхода - ще ви пусна и логове от компилатор.
Що само дуднете, а тоя въпрос виси 3 дни като някаква черна магия?
Прав ли си или не си бе, ДА или НЕ?
Бабички!

Аз:
Колко байта генерира #define ENABLE_INTERRUPTS() asm volatile ("disi #0x0000")


чичомен:
Окей, ей сега хвърлих един поглед на ISA-та, инструкцията заема 24 бит-а, като opcode e variable length. Така че, пак ще изгенерира повече от 0 байта, както ти твърдиш ;)

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Редактирано от rabin на 30.07.14 15:19.

"логове от компилатор" ROFLMAO! Рабине, пак си закъснял мама му деееба, ние тук вече разучихме какво генерира gcc-то, подлога такава.

Розова бе зората на битката като зашлевено дупе на девица

Айде пусни output на компилатор по избор - какво генерира един #define в binary-то.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

рабинчо, детенце, ти стана по-комунист от комунистите и по-голям лъжец от лъжците.

рабинчо, защо пак лъжеш? защо лъжеш, че не си искал никого да пращаш на лагер?

Съдържаниет е скрито
Влезте за да го видите

Това кой го е писал?


рабин
За тая гад ако няма решетка или поне бодлива тел - се разпълзяват като хлебарки и идват за пропаганда. Събираме ги по островите по Дунава, и да почваме начисто. Тая паплач е най-големия проблем на БГ, всичко останало е следствие.

Съдържаниет е скрито
Влезте за да го видите

Аха, викаш NOP-овете не греят.

препроцесорът не грее - аз така съм си сложил вместо вентилатори-директиви на кутията.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

не е споменал думата "лагер".

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

Я, некадърникът още е впечатлен от новата думичка!

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

така е, но според него на Белене само лагери е имало

Съдържаниет е скрито
Влезте за да го видите

volatile не върши работата на бариера и трябва да се внимава, защото въпреки, че "то с интел си работи и с гцц", може пък да се окаже, че не винаги работи.
например:
volatile_var=1;
nonvolatile=5;
volatile_var=0;
макар обикновено да не се пренареждат не-волатилните присвоявания, това не винаги е вярно. правилно в случая е ползването на бариери или нещо от сорта:
volatile_var=1;
*const_cast<volatile Type *>(&nonvolatile)=5;
volatile_var=0;
обикновено с бариерите и генерираният код е по-ефективен, макар да допускам и обратния случай.

Всичкото спор около С идва от неосъзнаването на факта, че С е малък език и ОГРОМНАТА част от ежедневното програмиране на С попада в графата implementation defined (а често и undefined)

volatile е просто примитивен начин да кажеш на компилатора 'не пипай тука и не се прави на умен'. Нема тредове, бариери и прочие. Има само чесна дума, че компилатора нема да се прави на прекалено умен.

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

Бариерите никога не правят кода по-ефиктивен, дори напротив, тъй като зависи от бариерата различни може да се flush-нaт store buffer-а (sfence/x86) или пък load buffer-а да се изпразни (lfence/x86), а може и двете (mfence/x86). При ARM нещата са малко по-сложни тъй като там си имат и shareable-а домейни, защото вкараха дори coherency м/у процесор и видео карта. И в зависимост от домейна можеш да искаш да флъшнеш само CPU-тата или "всичко".

Розова бе зората на битката като зашлевено дупе на девица

не така, колега, това "не се прави на умен" не звучи академично а и не e вярно.
не ми се дълбае в стандарти и техните тълкования. грубо казано, но пак невярно е "не дръж 'дълго' време в регистър", но всъщност е ясно дефинирано, от къде до къде може да бъде стойността 'кеширана'. Примери:

volatile int v; // мазна глобалка
....
v=1; // 'глупав'
v=2; // 'глупав'
a=v; // 'глупав'
b=v; // 'глупав'
c=v+v+v; // тук на компилатора е разрешено да бъде "умен" и да чете v само веднъж, та дори да умножи по три, ако сметне за уместно

изобщо - черна магия е и "не бива" да се ползва за синхронизация, но не е и невъзможно

По-ефективен спрямо какво? Спрямо код без бариери - определено ще е по-бавен, иначе щяха да са по дефолт навсякъде.
ако не се лъжа, коректен код с volatile може да ти избълва същия или по-голям брой фенсета, като бонус с повече обръщения към паметта, така че продължавам да си мисля, че при правилен код бариерите са по-ефективни от volatile.

Верно бе, за кво цпу говоря, той е над тея неща.

Първо да се разберем - има compiler бариери, има и CPU/ARCH бариери.

Съдържаниет е скрито
Влезте за да го видите

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

Кой компилатор :) Примерно OpenCL компилаторите имат по-различно виждане за нещата. В точно този пример, понеже не е указано, v по дефолт ще е __private променлива съответно по дефиниция е в регистър и смисъла на volatile се губи. Обаче има един частен случай в който компилаторът не може да докара нещо дето ще се вмести в register pool-а и имаш register spills, т.е променливата всъщност да се пази в глобалната памет, вместо в регистър, понеже няма достатъчно регистри. Тогава въпреки че си я декларирал volatile, в първите няколко реда, пак ще се прави на умен - първото присвояване ще го оптимизира и разкара, а при третото и четвъртото директно ще присвои 2 без да чете от паметта.

Ако v беше __local или __global и съответно видима от всички workitem-и, тогава volatile ще се държи горе-долу както си описал, само че там ще имаш други забавни моменти - примерно ако решиш да циклиш на volatile __global променлива и си сигурен че някой workitem нейде в рамките на ndrange-а все ще я промени, много вероятно ще завършиш с GPU въртящо няколкостотин безкрайни цикъла паралелно и крашнал видеодрайвер. Това заради начина по който се schedule-ват и изпълняват wavefront-ите (или warp-овете според на nvidia терминологията).

EOF

зарежи, като разкараме неговите изцепки стана много приятна тема.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

синхронизация е широко понятие, аз ползвам волатиле за две неща, и двете могат да минат за синхронизация
1. канселиране
2. поредово акумулиране на резултат от много нишки
while(thread!=order);
acc+=thread_result;
order++;
според мен е много по-лесно да сбъркаш ако ползваш бариера, волатилето е по-разбираемо.




NE SUTOR ULTRA CREPIDAM

Не съм се изразил съвсем точно :)

Не съм убеден, че менталният ми модел е съвсем формално издържан (некой да ми влезе с ритници ако бъркам :), но в ситуациите 'глупав' от кода компилаторът не може да оптимизира понеже всеки стейтмънт е sequence point и трябва да достъпва v отново.
В ситуацията 'умен' единствен нов достъп удовлетворява volatile гаранцията (понеже няма междинен sequence point в израза) и наистина компилаторът може да прави квото си иска.

(Популярна грешка, която новобранки като наш Рабин правят е да се впускат да отговарят на въпроси от рода на какъв е редът на извикване на функциите в x = a() + b() * c(); аргументирайки се с приоритет и асоциативност, а редът е всъщност undefined)

На всичко отгоре volatile не означава atomic и с тредове е 'интересно'.

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

на мен ми изглежда съвсем легитимно така.
ф(а(),б(),ц()) е друг подобен случай, но не е добре да се замесват и разни плазмодии в схемата.

за старнадтен ц компилатор говорим, евентуално ц++.
в опенцл и джава може да е друго, в лисп може изобщо да няма жолатиле - това са други теми.

хмм, undefined?

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

ордер++ какво трявба да прави, не трябва ли interlocked increment в случая?
за acc+=thread_result ако ацц е volatile - interlocked add? щото и атомарни волатайли да са, ако от много нишки ги цъкаш така, може да се изтърве някоя друга бройка. ако само една пише, а други четат, ще си е ок.

абсолютно! c(), b(), а()/ а(), c(), b() - всичко е допустимо. и се случва от време на време.

зема си надраскам ся едно набързо да го видим, че не съм писал на с от години.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

нито едното нито другото имат нужда от локване, понеже само нишката цикли на while(thread!=order);
тоест, всеки си чака реда, налива каквото там е сметнал, после инкрементира реда за да пусне следващия.




NE SUTOR ULTRA CREPIDAM

само за && и || реда е строго от ляво на дясно. можеш да разчиташ че ако имаш а()&&б() а() ще се викне първо




NE SUTOR ULTRA CREPIDAM

Да, klapaucius и zaphod са ти отговорили, но да се разпростра :)

В рамките на спазването на правилата за приоритет и асоциативност, освен в най-тривиалните случаи има повече от един вариант за ред на извикване/достъп на операндите (не на самите операции) който дава коректен резултат и компилаторът може да избере който си иска и не е необходимо да документира това (иначе щеше да е implementation defined).

Същото е и при параметрите на функция (както спомена klapaucius) - компилаторът е напълно свободен да смята аргументите в къвто му дойде ред и после да викне функцията.

Ако не бъркам, извън реда на стейтмънтите, единствено има гаранция за реда на операндите на логическите && и ||, запетаята (но не като разделител в аргумент лист на функция, a примерно в израза return nuke_russia, MISSION_OK;) и тернарната чуденка (a) ? b : c.

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

Популярна грешка, която новобранки като наш Рабин
Нещо не познавам специалисти, пък да ги е срам от думите им още на следващия ден.
Не аз се отмятам от думите си, и не аз се хиля първоначално като дебил, и после да мълча като гъз.

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Чиба от сериозната тема бре, бомбе :)

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

Селски свирачо - едва преди седмица питА с кво е различно С от JS. Щото не знаеше.
Едва оня ден се хилихте по дебилски за турбо елементарни неща, като #define. Щото не знаеше.
От снощи се умълча като пръднал заек в люцерна. Щото вече знаеш!

Дейба некадърниците дейба. Тоя клуб попива всякакви безхаберници. Верно си тряя мод, не се трае вече!

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

Как бре да не знам?!?

C е английското име на нотата до и на гамата до мажор, а JS е серия Ibanez китарки на някои от които имам изключителното удоволствие да аматьорствам.

'Майсторе', нещо си се каздисал, я си наточи една кана кодец, от тоя качествения, с препроцесора без макросите и размишлявай върху наследствените връзки между обжс и с++ :)

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

малко на хвърляне на боб ми заприлича работата с това произволно определяне на реда, явно ще трябва да се чете.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

МислИ. В примерът x = a() + b() * c(); математически са добре дефинирани нещата, нали? - Първо става умножението и после събирането.

Това, което е абсолютно недефинирано е как компилаторът ще достигне до стойностите за умножение и събиране - може да викне първо а(), след тва c() и после b() и СЛЕД ТОВА по правилата да умножи и да събере резултатите. Има и други варианти и докато компилаторът гарантира, че крайният резултат спазва приоритет и асоциативност, изчисляването на ОТДЕЛНИТЕ ОПЕРАНДИ може да е в произволен ред.

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

имах предвид на къв принцип определя това "произволно" извикване, не нуждата от него.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

Е опенцл си е стандартно ц, горе-долу де, събсет на ц.

EOF

Е точно това е есенцията на undefined. Няма принцип. Това дава огромна свобода на писачите на компилатори да ги правят ефективни и гарантира на програматора, че ако не разчита на undefined behaviour и има читав компилатор нещата ще са ок.

Ся реалността я знаем ква е, но тва е положението минке - извън изрично упоменатите изключения и пазенето на правилата за приоритет и асоциативност, в С конкретният ред на изчисляване на операнди в израз е недефиниран :)

I have sold less books on sex than Stephen Hawking has on physics -- Madonna

Аз мангусарника знам, че го владееш. За сериозни неща те питам, и съм те улеснил до ДА или НЕ!
Некадърник!

Нали, той е като някаква черна магия! Федерер, Заплати, 18.10.13

очевидно не се изразявам ясно - ще трябва да погледна няколко компилатора как го имплементират, че ми стана интересно.

Изцяло на препроцесор се правят т.нар. драйвери за ембед. Макросите не са задължителни.

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

И трите статии са интересни.

Розова бе зората на битката като зашлевено дупе на девица

Всъщност, като се замисля, именно вземането-даването с опенцл е нещото което най-много ме е карало да се замислям за компилаторните оптимизации. Повечето имплементации (AMD и NVidia) ползват всъщност llvm, просто бекенда генерира машинен код за GPU. OpenCL kernel-ите са си чисто C, като opencl-специфичните неща са много малко на практика, а от C отсъстват предимно нещата свързани с наличието на стек, в GPU-тата няма стекове и следователно неща като рекурсия или function pointer-и няма, компилаторът се грижи да не ти ги позволи. function call-ове от гледна точка на C кода има, но иначе няма, на практика се inline-ват винаги. Та горе-долу това са разликите. Между другото, GPU disassembly-то е доста по-четливо и разбираемо от примерно x86 еквивалента (при AMD, Nvidia обикновено ти expose-ва само PTX-а, който е междинна интерпретация).

EOF

Начи....

За мен проблема с "умните" компилатори до нейде съвпада с проблема за изкуствения интелект.
А проблемът с изкуствения интелект е този, че за него обикновено се говори там, където няма естествен такъв*.

В конкретно цитирания случай, дебело подчертавам - в конкретно цитирания, е дефинирана променлива, чиято стойност се ползва в условие на цикъл.
Заебете мултитрейдинга.
Тази променлива може да се промени от прекъсване.
Тази променлива може да е дефинирана като хардуерен сигнал примерно (при някои микроконтролерски компилатори).
Варианти много.
Компилаторът няма право да оптимизира стойността й с константа, нито да я държи в регистър през цялото време.
Т.е.
int a=1;
while (a==1)
по никакъв начин не бива да се компилира като да е
while (1)

или пък да се компилира до изцяло регистрова операция примерно:

ld R1, a
L1: cmp R1, #1
bne L2
blah
blah
blah
jmp L1
L2: blah
......

(така де, некъф квази-асемблер)

освен ако същият този компилатор не ползва този регистър единствено и само за тази променлива и тя да не е разположена в паметта на системата, но всяка функция, която се обръща към нея, модифицира съдържанието на същия този регистър.
Т.е. ако правите разделно компилиране и едната ръка не знае какво прави другата, подобно нещо (оптимизиране) трябва да е забранено. Под заплаха от разстрел.

Няма и обикновена логика. Който иска да напише безкраен цикъл, ще го дефинира като такъв, а не с променлива.
В смисъл - освен ако не е пълен идиот де.

Още повече - какво ще спечелите от подобно "оптимизиране"?
Една операция достъп до паметта?
Ебаси печалбата!
Да де, ако цикъла само се върти без да има нищо в тялото му, ще имате огромно ускорение на изпълнението на безсмислен код.

Щом нещото е дефинирано като променлива, когато се прави сравнение на същото това нещо, то трябва да се извлича от там, където се намира, а не да се държи в регистър.

Мога да се съглася, ако е b=a+a+a; израза, че са възможни двусмислици и необходимости от указания към компилатора, или взимане на специални мерки в кода (примерно да кажем - ако а се променя от прекъсване, а ние искаме да съберем 3 пъти едно и също число, ще трябва да забраним прекъсването. Чиста глупост впрочем, вече и микроконтролерите правят умножение за един такт, ама нейсе!), обаче в цитирания случай е просто уникално зле да се компилира цикъла с проверка на променлива, която се държи в регистър.


Не можеш ли ти да пишеш оптимален код - надай се компилатора да ти го компилира като такъв.

Мораль: Умните компилатори са направени за ползване от глупави програмисти*.

-------------------------------------------------------------------------------------
*Направете напълно дуракоустойчива система, и само пълни глупаци ще поискат да я ползват.

Компилаторът няма право да оптимизира стойността й с константа, нито да я държи в регистър през цялото време.
Т.е.
int a=1;
while (a==1)
по никакъв начин не бива да се компилира като да е
while (1)

GCC 4.8 генерира точно такъв код при -O2. Гледал ли си ассембли-то на такъв код? Пуснах го при разговора с Dr. Who

Розова бе зората на битката като зашлевено дупе на девица

Да да, компилаторът трябва да не ти кешира нито една променлива в регистри защото някой interrupt handler може да ти я презапише. Това е валиден case в 99.999% от случаите особено като пишеш за нормална операционна система където има отделни адресни пространства и сегментацията се грижи за това да имаш кернелска част от адресното пространство и юзърспейска част.

Сега с празния цикъл съм съгласен, ама да презареждаш от паметта брояча на цикъла на всяка итерация е малоумно решение. Процесорните кешове може и да правят нещата по-безболезнени, но като цяло дори четенето от тях има огромна латентност. За същото време можеш да свършиш доооста ALU операции примерно, но не - ти трябва всеки път да четеш от паметта и да сереш на pipeline-а и да елиминираш всякакви евентуални оптимизации свързани с loop unrolling, щото няма как едновременно няколко четения от паметта да направиш, във time domain-а некой все ще запише нещо там.

Не го казвам с негативни чувства де, но според мен това което според теб е забранено под заплаха от разстрел е нормалния use-case в 99.999% от случаите.

EOF

ГЦЦ е.... сериозно име.
Не бих го оплюл директно, ако не разполагам с повече информация.
Макар че - нема да е първият компилатор, който оплювам.

Съдържаниет е скрито
Влезте за да го видите

ама да презареждаш от паметта брояча на цикъла на всяка итерация е малоумно решение.

Съгласих се.

Обаче.

Уайл цикълът по принцип не броячен. Това му е идеята. Според мен де.

Цикъл с брояч е фор цикълът и не случайно манипулирането на променливата в този цикъл - вътре в него или извън него е... признак на лош вкус - тъй да кажем. Пак разбира се изгъзици всякакви, и всеки си пише как иска, но ако имаш брояч - фор-ът някак си е предназначен за тая работа. Доколкото уайл е цикъл по логическо условие по принцип.

Я так думаю, както казваше арменеца на грузинеца в един стар совецки фильм за летене, шофьорлък и още нещо.

Съдържаниет е скрито
Влезте за да го видите

Дори while цикъла не мисля че "очаква" некой друг тред да му смени условието. В смисъл напълно признавам идиотския кейс с безкрайния цикъл, защото покрай тази тема видях колко лесно се получава. Ама не знам де, крайността с непазенето на итератори в цикли е малко страшна според мен, не е добро поведение. Не е добра идея да се презареждат от паметта всеки път, може би затова си има все пак volatile, ако имаш изричното желание да става.

Редактирано от gat3way на 01.08.14 02:34.

Е защо? Никъде не е казано, че променливата участваща в условието задължително се модифицира вътре в цикъла. Т.е., буквално преведено дори, условието е "докато едикаквоси". Това едикаквоси може да е всичко и навсякъде. Както вече казахме - може да иде от прекъсване, дори и да няма мултитрейдинг.

Не малка част от уайл циклите дето пиша разчитат на външна промяна. Вярно е, че напоследък пиша предимно за микроконтролери, ама и на вижуал студиото пак тъй процедирам общо взето. Брояч ли е - фор.

А и в дадения случай променливата не е итератор по смисъла си. Всъщност - нищо не го гарантира. До някъде, подобна "гаранция" като упътване за компилатора, би могла да се получи от типа на използвания цикъл. Само дето - както правилно е забелязал Евлампи-то - Ц-то е език в който има много неща дето са ъндифайн. Изобще - Ц-то е език за истински програмисти, а не за "индийци".

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

П.С. (за да не се коригирам, че мразя....)

Пробвай да го компилираш като отделен модул, до обектен код, без да стигаш до линкване.
Или пробвай да го компилираш, указвайки, че функцията, която променя стойността на променливата е прекъсване.
Или просто все пак я извикай тази функция в кода, а да не е само дефинирана.

Да видим дали тогава ще го замести с константа.

Ама не, то GCC като го прави това нещо е напълно валидно, аз не го оплювам. Просто явно не си наясно как работят съвременните компилатори ( и не, нямам предвид препроцесори, compilation units и така нататък) на ниво оптимизации. Имам цяла сурия колеги, които пишат GCC и всеки един от тях би се съгласил, че това е напълно валидна оптимизация, тъй като компилатора изобщо си и няма идея от multi threading (изключая OpenACC и нему подобните)

Розова бе зората на битката като зашлевено дупе на девица

Ами на ГЦЦ съм работил последно предиоколо 4-5 години, не го знам колко се е осъвременил от тогава до сега.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ти си малко biased с тези микроконтролери. В повечето "нормални" операционни системи няма вариант някой ISR да маже из адресното пространство на процеса или поне не би било особено приемливо такова нещо да се случи. Мултитрединга е валиден кейс, обаче регистрите са лимитиран ресурс - компилаторите така или иначе не могат да пазят много неща там, та с приоритет са променливи, които се четат и пишат често. Условията на разни кратки цикли са доста подходящ таргет за целта - защото се достъпват често. При while цикъла няма модификация на някакъв брояч, но четенето на променливата-условие си остава. x86 има прилично "дълбок" pipeline, има и прилично функциониращ branch prediction, та би било разхищение на енергия да не се утилизират. Ако условието на while цикъла е в регистър, няма толкова големи проблеми с утилизацията на pipeline-а, в идеалният вариант без misprediction, лошият случай ще настъпи само веднъж - когато излизаш от while цикъла. Четенето на променливата от паметта обаче е с порядъци по-бавно от четенето от регистър, дори да е в L1 кеша и това тотално съсипва цялата схема с branch prediction-а и утилизацията на pipeline-а, ще имаш прилично много процесорно време в което железарията стои idle докато чака нещо да и се достави.

Сега остава въпроса нормално ли е условието на цикъла да се променя от друг тред. Да - нормално е, но аз съм убеден че това се случва в много малък процент от случаите, което в крайна сметка оправдава такава оптимизация. В този много малък процент все пак можеш да ползваш volatile променлива.

EOF