Cilk дава гаранции само за програми, които не използват locks. Най-често се използват divide-and-conqueror алгоритми за разпределянето на задачите. Типичен пример са quick & merge sort, на които може да получиш линеен speedup с добавянето на още ядра. Тъй като Cilk е базирано на рандомизиран work-stealing scheduler имаш гаранции за пълното използване на всички ядра независимо от размера на различните задачи. Ето една статия по темата за изчисляването броя на cache misses при multithreaded програми използващи Cilk http://strumpen.net/tocs08.pdf

Всъщност има голяма вероятност Cilk да извади по-добри резултати от твоя ръчно написан код с pthreads. Cilk дава гаранции за брой cache misses при n на брой процесори и m на брой задачи за изпълнение. Проблемът с false sharing обикновено се получава при ръчно ползване на threads, а не на неща като Cilk. Дори да стане, може да се използва sheriff за отстраняването му. Cilk е модел за nested data parallelism разработван повече от 10 години, наистина ли мислиш, че твоя scheduler ще е по-добър от неговия? И последно да спомена, че всички модерни frameworks като .NET TPL, Java fork/join, Intel TBB са базирани на Cilk.

Не видях дали става въпрос за shared memory или за независими таскове. Ако са независими може да пробваш решения базирани на work-stealing queues като
http://software.intel.com/en-us/articles/intel-cilk-plus/
http://supertech.csail.mit.edu/cilk/

Дават много добри гаранции за performance и се работи супер лесно с тях. Intel TBB и .NET TPL работят на същия принцип.

Щях да правя нещо подобно, но го намерих наготово -> Java vs. C++: The Performance Showdown
за да не си чешем езиците.

Всъщност за малко да се хвана да тествам, но ме домързя да тегля и слагам JDK.

Тези тестове са безсмислени, авторът няма идея какво прави. JIT работи per method invocation, java methods по default са virtual за разлика от тези на C++ и още много. За да тестваш VM-to първо трябва да направиш dry-run итерации, за да може profilera да събере достатъчно данни.

Аз само цитирах противоречието между мненията ти. Веднъж казваш че модерните JIT компилатори генерират по-добър код от останалите, а после казваш че „в *някои* случаи JIT кодът е по-добър“. Лично аз съм съгалсен с второто твърдение, но не и с първото. Понеже и двете си ги писал ти, не мога да кажа че съм съгласен с теб А и темата е за Java, а не по принцип за JIT срещу нормални компилатори.

Логиката че щом се пишат много игри за малките телефони на Java ME, значи платформата е добра е като логиката че щом повечето GUI софтуер по света ползва MFC, значи това е добър GUI framework.

Почвам да се съмнявам дали има смисъл да отговарям. Никъде не става въпрос колко игри се пишат като брой, твърдението беше, че Java е бавна и не става. Е щом се пишат игри за телефони (и то колко) явно е достатъчно бърза. JIT кодът винаги е по-добър, при наличието на достатъчно данни, това си е факт, практически няма начин да генерираш по-добър код с обикновен компилатор. Проблемът е, че писането на JIT компилатор е изключително трудно, особено за език като Java, затова не винаги е ефективно. Това беше цялата идея с "някои" - кодът винаги е по-добър, а тези случаи, когато не е, просто са свързани с това, че опитът е много по-малък. Въпреки това резултатите се виждат:

 - http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
 - http://lambda-the-ultimate.org/node/3851

Темата не знам дали е за Java, тъй като Java като език не представлява нищо. Всичко идва от платформата. Нещата отидоха в посоката на JIT, за да разберат някои хора, че модерните VM-та не са това, което бяха през 90-те.

Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери.

Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Само на мен ли ми се струва че не си спомняш какво си написал вчера?
Minecraft е частен случай. Ако не го осъзнаваш проблема си е твой. Не всяка игра е FPS. Очевидно никой не пише на Java и стратегии, дори и походови, където не е толкова важна производителността. Там „по-лесното писане“ би трябвало да помага.

Много обичам да гледам как Java феновете се отказват от думите си колко е производителна любимата им платформа и започват да говорят за стабилност като им зададеш един прост въпрос.

То май и ти не си спомняш, защото в първото изречение съм написал още, че смятам C++/Java за пълен провал. Толкова беше с Java "феновете". След изключването на игрите за телефони (защото явно и те са частен случай) няма какво повече да коментираме. Виждам обаче, че явно си съгласен за динамичното компилиране, ако не е така, prove me wrong.

Всъщност често където се търси голяма производителност в код на C и C++ не се ползва malloc или new, а собствен memory pool. Например в рънтайм библиотеките на Apache (apr) и Mozilla (nspr).

Сега очаквам lkr да даде списък с популярни игри написани на Java, заради по-високата производителност и по-лесното писане в сравнение със C++. Може и Web сървъри (без да включваме неща като Tomcat и GlasFish) или браузъри. Единствените Java браузъри използвани в момента са в малките мобилни телефони, но това не е заради по-високата производителност.

Minecraft добър пример ли е ? Или това не е достатъчно успяла игра. Вярно е че Java все още не може да се сравнява с RAW performance, но това че била бавна е абсурдно твърдение. Никъде не съм написал, че има по-висока производителност, а че в *някои* случаи JIT кодът е по-добър от този генериран от обикновен компилатор. Съответно това не е безплатно, има runtime overhead, а и трябва profiler-a да "загрее" преди да прави каквото и да е. Това е недопустимо при FPS игри, където latecy-то е от изключително значение. Да не говорим за неща като autoboxing, nondeterministic GC, reference types, virtual function inlining & co.  Факт е обаче, че Java за application/web programming е значително стабилна, дори и за server-side неща като Cassandra, Flock, etc.

Ами всъщност - да, може да генерира по-добър код. Има оптимизации, които не могат да се направят в compile-time. Много прост пример:

d = a*b + c;

Ако стойностите на а и/или b не са ти известни в compile-time (демек не са константи), това ще се компилира до MUL и ADD инструкция. JIT компилатора обаче може да вземе предвид че a или b ти е равно на 0 и да ти спести умножението и събирането. Примерът е доста прост, но предполагам го илюстрира.

Това е най-малкото, което може да направи. Въпреки това няма да спечелиш много, освен ако не си в tight nested loop, което пак ще бъде hoisted. Ето една интересна статия JIT based interpreter (LuaJIT) http://article.gmane.org/gmane.comp.lang.lua.general/75426.

А GC-то е generational, рядко трябва да се обхожда целия heap. В повечето случаи мястото за short living objects се преизползва и чистенето става изключително бързо заради доброто locality на датата.

Аре стига глупости, на всички им стана ясно, че Java haters говорят от гъза си тука. Никой няма идея за какво иде реч. С това че C++/Java са едни от най-големите изцепки като езици на програмиране съм напълно съгласен (особено за първия), обаче това че Java е тромаво е крайно време да престане.

Java е било тромаво едно време, когато още е нямало JIT и VM-то е било крайно неефективно. В момента обаче JVM е една от най-стабилните индустриални платформи с повече от 15 години опит. JIT кодът в много от случаите се компилира до по-бърз от този на C++, тъй като има много повече информация от C++ компилатора. Който не е съгласен с това твърдение е напълно некомпетентен по темата и няма нужда да противоречи. Java е единствено бавна при GUI приложенията, защото не използва native widgets на операционната система, ами свои собствени. Това че Java била бавна, защото се изпълнява на VM е някакъв мит от 90те. Модерните JIT компилатори са изключително ефективни, генериращи код по-добър от обикновен компилатор. Да не говорим за GC, който в много случаи е по-бърз от ръчен malloc/free! Има доста материали по темата, който не вярва може да провери. Java има други проблеми като non-value types и locality на данните, което го прави значително по-неефективно за multicore performance в сравнение с F# примерно.

...
Истината е, че, за да стане наистина добър (в смисъл на велик), ще му трябват познания както по процедурно и системно програмиране, така и по ООП и уеб, както по архитектури и мрежи, така и по алгоритми, функционално програмиране, shell scripting и още много. Но в първите си стъпки човек може само да се мотивира и да си набелязва какво да научи, а само времето ще покаже докъде ще стигне и кои области ще му харесат най-много.

Иначе това, което аз мога да споделя, е, че със сигурност в началото езиците трябва да ги кара един по един - след като опознае добре възможностите и духа на единия, след като види какво може да постигне с него, чак тогава да мине на друг, за да не се получи ситуацията "аз знам синтаксиса на 10 езика, обаче с никой от тях не мога да направя нищо яко". И да не пренебрегва съпътстващата IT теория, защото рано или късно ще му потрябва.

Напълно съм съгласен с bop_bop_mara. За всичко. Просто си избери един от най-популярните в момента езици и започни с него. Аз лично май не познавам хора, които са учили само 1 език и си дълбаят в него с години. Може и да има де. Най-вероятно след време ще ти се изясни какво ти е интересно и с какво искаш да се занимаваш.
Ровене и четене

Напълно съм несъгласен с bop_bop_mara. За всичко. Това за shell scripting особено беше доста добро. Тези съвети малко приличат на: "Учи алгоритми, езикът няма значение, те навсякъде са еднакви". Езикът обикновено няма значение, тъй като той е само инструмент за изразяване. Както се казва - ако имаш само чук, всичко изглежда като пирон.

Хубавото на многото езици е да се запознаеш с различни парадигми и най-вече да разбереш какво са направили грешно, че да не повтаряш същите грешки и ти. Пример за това какво да не правиш са C++, Java, PHP. Започването с Python е добра идея, въпреки че и той не е особено известен с добрия си дизайн.

Искам на haskell !!!

Код

GeSHi (C):
fac :: Int -> Int
fac 0 = 1
fac n = n * fac (n - 1)
 
sin' :: Float -> Int -> Float
sin' x p =
    sum [ ((-1 ^^ i) * x ^^ (2 * i + 1)) / (fromIntegral $ fac (2*i+1)) | i <- [0..p] ]
 
 

Айде малко офтопик - кой ще го напише на Scheme/Lisp? 

Код

GeSHi (Scheme):
 

Това set, кога го правиш, като отвориш файла или след това? Във ~/.vimrc сложи

Код

GeSHi (Bash):
set encoding=utf-8
set fileencoding=utf-8

Флаш не се подържа само в "малките" устройства на Apple - iPod, iPhone, iPad.
То там няма и нужда де - кой ще тръгне да гледа видео на телефона примерно???
Това за Джава е пълн глупост. Може би Мак и Соларис са единствените системи, които имат така да се каже - native подръжка на Джава...
Youtube казваш... ми хората минават на HTML5. И то не заради Apple, а защото това е бъдещето. Флаш умира.

Flash умира викаш? http://labs.adobe.com/technologies/flash/molehill/

Ти май не разбра въпроса на backtolife - защо решението да не сумира и наобратно.
Иначе той си каза, че кодът му е ясно какво прави.

Изобщо не му е ясно какво прави, също така тук няма никакви процедури като параметри. Въпросът доколкото виждам е защо искаме 'а' > 'b', даже е объркал като е написал: Не разбирам за какво искаме a да е по-малко от b? - трябва да е по-голямо, не по-малко