Между другото същия ефект съм го виждал и при джава :0 така че не е rust специфично. Даже не е LLVM специфично.
Защо така ?
ФейкПрофил Между другото същия ефект съм го виждал и при джава :0 така че не е rust специфично. Даже не е LLVM специфично.
Четириелементен масив и махане на —-1 решава всички проблеми.
Дон Реба saruman Стига ве,и само заради branch prediction-а ли да прави такива разлики,забележи че долу ползва даже <= оператор,ако ползва само < още би трябвало да падне времето
да, само заради него е. обаче и на правец 16 дето няма конвеери мисля че "аритметичния" вариант ще е по-бърз, но няма да е с толкова много. ифа дори на платформа без конвеери монвеери е няколко операции и замяната му с аритметична операция (индексиране) още от фортранските времена си е била далавера. компилаторите от много отдавна като компилират switch гледат дали клоновете са последователни числа, и ако да компилират аритметично, без ифове.
Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
code2 Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
Сигурен ли си, че имаш идея за какво говориш? :)
| code2 Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
Сигурен ли си, че имаш идея за какво говориш? :)
Общо взето е прав. Навярно най голямо значени за "разпепеляване" на изпълнението ще има премахването на "prev".
janbird | code2 Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
Сигурен ли си, че имаш идея за какво говориш? :)
Общо взето е прав. Навярно най голямо значени за "разпепеляване" на изпълнението ще има премахването на "prev".
За кое е прав, че има "две интегрирани нишки"? :)
Нека не се хващаме за грешки в израза или терминологията. Идеята е ясна. По интересно е как да го разпишем така че да помегнем на компилатора да го "разпъне".
janbird Нека не се хващаме за грешки в израза или терминологията. Идеята е ясна. По интересно е как да го разпишем така че да помегнем на компилатора да го "разпъне".
Според мен много малко неща са по-малоумни от това да си променяш кода, че компилатора да го разбере по-добре.
| Според мен много малко неща са по-малоумни от това да си променяш кода, че компилатора да го разбере по-добре.
Любопитно, какви са другите по-малоуни неща. Сподели.
janbird | Според мен много малко неща са по-малоумни от това да си променяш кода, че компилатора да го разбере по-добре.
Любопитно, какви са другите по-малоуни неща. Сподели.
Ами например да "оптимизираш" кода без да има значение производителността му.
| janbird | Според мен много малко неща са по-малоумни от това да си променяш кода, че компилатора да го разбере по-добре.
Любопитно, какви са другите по-малоуни неща. Сподели.
Ами например да "оптимизираш" кода без да има значение производителността му.
that's the essence of being geek and you've just killed it
Щом относно даден код може да използва изразът "нужда от оптимизиране" то не означава ли това че наистина има нужда от такава?
По принцип от бизнез гледна точка и ако искаш да станеш хай левел менажер вероятно наистина няма време за такива глупости, но ако те кефи да програмираш, винаги искаш да го направиш по- добре и по- добре, което пък в някакъв процент води до обратното, зависи какви са ти приоритетите. Донякъде има право, но това е същината на гийкщината.
Courvoisier По принцип от бизнез гледна точка и ако искаш да станеш хай левел менажер вероятно наистина няма време за такива глупости, но ако те кефи да програмираш, винаги искаш да го направиш по- добре и по- добре, което пък в някакъв процент води до обратното, зависи какви са ти приоритетите. Донякъде има право, но това е същината на гийкщината.
Мда точно от "бизнес" гледна точка се говори за оптимизиране само ако наистина има нужда от такава за "бизнеса".
janbird Щом относно даден код може да използва изразът "нужда от оптимизиране" то не означава ли това че наистина има нужда от такава?
Не.
Courvoisier По принцип от бизнез гледна точка и ако искаш да станеш хай левел менажер вероятно наистина няма време за такива глупости, но ако те кефи да програмираш, винаги искаш да го направиш по- добре и по- добре, което пък в някакъв процент води до обратното, зависи какви са ти приоритетите. Донякъде има право, но това е същината на гийкщината.
Дори и да те "кефи" да програмираш, оптимизирането просто заради оптимизирането е малоумщина. Кодът се пише от хора за хора, а не от хора за компютри. Ако се пишеше за компютри щеше да изглежда съвсем различно. И, не, нямаше да е асемблер. Дори той се пише за хора. Доста странни хора, но все пак хора.
| Дори и да те "кефи" да програмираш, оптимизирането просто заради оптимизирането е малоумщина. Кодът се пише от хора за хора, а не от хора за компютри. ...
Това е твое мнение. На мен ми помага за еякулация, а това според мен е...
| code2 Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
Сигурен ли си, че имаш идея за какво говориш? :)
За сигурен съм сигурен че знам за какво говоря, но за изказът наистина съм забравил терминологиите. Работата е там, че процесорите са минали през няколко етапа на еволюция. Така например конвейерната обработка е една от технологиите, която мисля че е въведена с 386 процесорите. При пентиум процесорите нещата са с една принципна стъпка по-напред като някои операции се изпълняват паралелно, ако е възможно. Примерно ако имаме a=10 следвано от b=20 то вероятно се изпълняват едновременно. Тук не говорим за специални нови инструкции! Естествено говорим за assembler (и може би трябваше да представя нещата в такъв формат примерно "mov eax,#10").
По отношение на оптимизацията за да може да се ползва въпросното ускорение - това си е задача на компилатора, ако не пишеш на чист асемблер. Т. е. не променяш кода, а компилаторът ти го балансира сам. Примерно ако имаш a=10; b+=a; c=20; d+=c - то се изпълняват едновременно само тези команди: "b+=a; c=20;". Но ако разпределиш нещата така: a=10; c=20; b+=a; d+=c (което води до същия резултат), тогава първите две и следващите две команди си се изпълняват едновременно.
code2 | code2 Освен въпросния предикшън трябва да се отбележи, че още от времето на пентиумите изпълнението се разпаралелява в две интегрирани нишки където може. Точно if-овече е мястото, където не може да се разделя изпълнението на два вградени потока!
Сигурен ли си, че имаш идея за какво говориш? :)
За сигурен съм сигурен че знам за какво говоря, но за изказът наистина съм забравил терминологиите. Работата е там, че процесорите са минали през няколко етапа на еволюция. Така например конвейерната обработка е една от технологиите, която мисля че е въведена с 386 процесорите. При пентиум процесорите нещата са с една принципна стъпка по-напред като някои операции се изпълняват паралелно, ако е възможно. Примерно ако имаме a=10 следвано от b=20 то вероятно се изпълняват едновременно. Тук не говорим за специални нови инструкции! Естествено говорим за assembler (и може би трябваше да представя нещата в такъв формат примерно "mov eax,#10").
По отношение на оптимизацията за да може да се ползва въпросното ускорение - това си е задача на компилатора, ако не пишеш на чист асемблер. Т. е. не променяш кода, а компилаторът ти го балансира сам. Примерно ако имаш a=10; b+=a; c=20; d+=c - то се изпълняват едновременно само тези команди: "b+=a; c=20;". Но ако разпределиш нещата така: a=10; c=20; b+=a; d+=c (което води до същия резултат), тогава първите две и следващите две команди си се изпълняват едновременно.
Това, което описваш IBM го въвеждат още през 60-те с алгоритъма на Томасуло. И няма нищо общо с каквито и да е нишки.
janbird | Дори и да те "кефи" да програмираш, оптимизирането просто заради оптимизирането е малоумщина. Кодът се пише от хора за хора, а не от хора за компютри. ...
Това е твое мнение. На мен ми помага за еякулация, а това според мен е...
Говорехме за програмиране, а не за сексуални девиации.