Java: "GAME OVER!"

MMM da - mnogo interesno - az polzwam Delphi - samo edno ne moga da razbera (moze bi ot towa 4e pro4etoh testa otgore otgore) zasto e polzwan Delphi 3 - kato istinskite optimizacii na Delphi kompilatora zapo4naha ot 4 nagore - daje be polzwan i Delphi 1 - ako cifrite ozna4awat wersiata

4esno kazano kato gledam predstawianeto - nisto koj znae kakwo ne wizdam kato skorost za C# i Java - pri istinski algoritmi - towa 4e izwikwaneto na funcia bez nisto w neia e naj barzo pri C# - ami ne e li malko bezmislen slu4aia da se razglezda.
Po nadolu ima i izwikwane na realna funcia - pedstawianeto na "normalni" compilatori - w slu4aia Delphi e naj- dobro e ne winagi - no kato gledam ima dosta sredno polozenie - za razlika ot C# Java - koito tu sa na warha tu na opashkata - za nestastie poslednoto w wazni (pone za men) situacii

Ej - ne se zaiazdam - prosto se opitwam da talkuwam towa koeto wizdam. A kolkoto do barzodejstwieto - poniakoga neskoposania algoritam moze da zadrasti i naj dobria i optimiziran compilator

---
Е т'ва е живот!

Ne ponyakoga, a vinagi. Vse oshte kompilatorite ne optimizirat po vremeva ili prostranstvena slojnost :-)))

Ето още един тест, дето в началото се обясняват некои неща за Делфи:

[линк]

а после сравняват по производителност GNU C++ 2.95.3-7 (Windows - mingw), Borland C++ 5.5 и VC.Net (v 7.0) beta 2.

Истински оптимизации на Делфи компилатора практически няма. Е има де, но отстъпва много от оптимизацията в C-езиците (което е много странно). Аз си падам малко експерт по reverse engeneering и обичам да се ровя от вътре в програмите. И мога да заявя, че кода, които генерира Делфи 6 например много отрсъпва (по оптимизация която прави компилатора) от кода, генериран от Borland C++ 5 например, и още повече от кода на VC++ 6. Не сравнявам с компилатора на Watcom, щото той е връх в оптимизацията (е, той си има други трески за дялане).
А за C# и Java, за които е разговора - целта ми беше да покажа че са сходни езици и по възможности, и по скорост и няма защо да се противопоставят един на друг. Какво може да се очаква от един език, който минава през междинен код и прилича на C++? Разликите идват (в момента) основно от това, че ги правят различни екипи. И сега стойте та гледайте - тъй като става дума за пазар и много пари, ще се повтори историята с MS Explorer и Netscape. Екипите ще гледат един от друг и ще вграждат бързо противниковите възможности. Плюс калните номера на Майкрософт да нарушат всички стандарти в своя полза.

Е, аз имам избор на какви езици да пиша, така че това засега не ме касае. Засега...

Eto link ([линк]) s becnchmark na .NET vs. J2EE, rezultata e smazvasht .NET e 28 puti po burz!

Pri C++ vs. C# moje da se ochakva pri niakoi programi koito rabotiat intezivno s pametta (new/delete) C# da e po burz zaradi organizaciata na heap-a. Pri .NET heap-a e lineen i 'new' predstavliava prosto uvelichenie na ukazatelia kum svobodnoto prostranstvo sus suotvetnia razmer na obekta, dokato C++ heap-a e dosta po slojen.

1. verno na MS im "kopaiat groba", no ne opredeleno ne smiatam, che skoro shte umrat. Daje ne mi se i iska da stava - vse pak sa dali mnogo na industriata i ima oshte mnogo da dadat.
2. ne se kachva 40MB VM, verno che praga e niakude okolo 12 MB (i ot tam zapochva da raste spored goleminata na programata), no suglasi se edna programa na Delphi ne zaema po-malko
3. Visual Studio e naistina dobra sreda za programirane (daje moga da kaja nai-dobrata) rabotia kato programist i pishem za Win32/Linux/QnX/Solaris i opredeleno razvoinite sredstva, s koito razpolaga edin programist pod Windows sa s puti po-dobri ot vsichko koeto mojesh da se setish za drugite OS.

btw programiram osnovno na C/C++ no ne otkazvam da se zapoznavam i s ostanalite ezici za programirane i opredeleno Java e edna ot liubimite mi alternativi, vse poveche neshta, koito iskam da stanat burzo gi pisha na Java - prosto Class bibliotekata, koiato e chast ot VM e dobra, pulna i ima pochti vsichko, koeto moje da ti potriabva. kolkoto do C# - ami chesno kazano na pruv pogled si izglejda kato Java sus smeneni niakoi kliuchovi dumi, koeto opredeleno ne go pravi "razlichen" ezik ... imam sumnenia, che sled deloto, spored koeto se zabrani na MS da razvivat i poddurjat JVM v Windows - te prosto sa reshili da napraviat neshto "podobno" Rezultata ? rano e da se kaje! no za vseki ezik i programist ima miasto pod slunceto, a istinski dobrite izobshto ne se interesuvat "na kakvo" pishat, stiga ezika da im predostavia nujnite sredstva. A povecheto go praviat. Vsichko e vupros na algoritmichno mislene i poznavane na niakakuv sintaksis. Kato imash purvoto - vtoroto se uchi (pri tova ne osobeno trudno)

Do Skiv: Dark Lord / MoRDoR

i kakwo stava kato osvobodish pamet koiato ne e w kraia na heap-a?

памет не се освобождава динамично (няма операция като delete). гарбидж колектора сам решава кога и какво да освободи. обикновено това става, ако е получена заявка за заделяне на памет, а такава няма налична. освобождаването започва от поколение 0 (обикновено L2 cache), ако освободената там не е достатъчна - с поколение 1. поколение 2 са тежките обекти - с много данни, които се предполага, че съществуват най-дълго, затова там паметта се освобождава само в много краен случай, обикновено при терминиране на приложението. освобождават се само тези обекти, към които не сочат валидни референси.
с две думи - гарбидж колектора сам решава кое да освободи и как да реорганизира хийпа така че свободното пространство пак да си е непрекъснато "поле".

stoj, ta gledaj

Всъщност обесението за разликата в оптимизацията м/у Delphi и CBuilder(C като цяло) е проста се състои в използването на Compiled Unit - tpu, dcu и така нататък. Просто при С имаме изцяло компилиране на програмата от 0 (e по4ти де) - докато такова нещо при Pascal няма - използването на модули тук е на първо място. Посто разли4на стратегия която има предимства и недостатъци.

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

Колкото до скоростта - ами преди време гледах сравнение между Delphi VCL библиотеката и MFC библиотекта (в тази си 4аст за Win programing) - трябва да ти кажа 4е резултатите като скорост при Borland бяха зашемтяващи.

---
Е т'ва е живот!

Значи модулите дето се ползват в Делфи някога са били компилирани, нали?
А и в С нормално е да се ползват готови библиотеки.
Става дума за кода, който генерира компилатора. Заемането на паметта се прави с библиотечни функции, и при Делфи те са по-добри. При С заемането на памет ползва директно работа с API функциите, а от там стърчат забравени ръце от Майкрософт... :))
Също така какво са натворили Майкрософт в MFC - не ми се говори.
Просто думата ми е за чистия код: цикли, преходи, повикване на функции, работа с масиви и стрингове, обекти: оптимизацията в този код при С е значително по-добра - и по скорост, и по размер. Виж, не съм се ровил в програми на CBuilder и не мога да кажа за оптимизацията там.
Ако се сравняват основните библиотеки по скорост - там най-вероятно ще спечели Watcom - и никога Майкрософт.

Може, ако при Java не е ползуван jit (just-in-time compiler) :))
тва е все едно да сравняваш VB3 и С...
А и не трябва да се вярва на тестове, спонсорирани или правени от Майкрософт: това е като оная реклама дето се смяхме навремето, че Майкрософт SQL сървер е 8 пъти по-бърз от Oracle :)) И не разбрахме при каква ситуация е по-бърз.

А heap-a в 32-битов модел е винаги линеен. Проблемите на езиците с паметта тръгват тогава, когато той трябва да порасне (защото по начало той не е безкраен!) и когато се нацвъка като цедка със заети и празни блокове, как да се оптимизира свободната памет. При VC++ нещата са плачевни: и new, и malloc ползват едни стари алгоритми от време оно, които скъпернически отделят памет и затова са бавни. А увеличаването на heap-a се прави пак на малки порции с API-функции, които са още по-бавни. И доста програмисти ползуват други библиотеки за работа с паметта, ако приложението е такова.
При Делфи и С Builder нещата са други - Борланд там си е направил доста по-оптимална система (и затова по-бърза!) за работа с паметта.
При С# и Java-та пък нещата стоят по трети начин - тъй като там паметта не се освобождава директно, се ползва "събирането на боклук" от време на време - процедура, позната още от времето на Лисп (ама вие си ги знаете тези неща). И не е толкова очевидно дали заемането на памет е по-бързо отколкото при С - както казах по-горе, всичко зависи как се подхожда при разширяването на heap-a. А това вече не зависи от езика, а от производителя му.

НО: докато в езици като С# управляването на heap-a не е достъпно за програмиста, то при С и С++ всеки може да си вземе от други библиотеки (и сорсове по Интернет бол) нови функции за заемане на памет, и по-бързи от С#, и подхождащи на задачата, която се решава ако е лимитирана от скорост.
:)))

Pametta ne ia osvobojdavash ti, a garbage collector-a. Ako ot heap-a ne moje da se zadeli block s daden razmer se vkluchva GC i toi go compresira t.e. maha dupkite.

Mejdu drugoto pri C++ heap-a susto ima faza na GC :))). Kogato heap-a se fragmentira dostatuchno mnogo se subirat vsichki malki svobodni blokcheta v edin goliam. Ne mislia che ima mnogo razlichni nachini za razshiriavane na heap-a taka che skorostta osnovno zavisi ot algorituma za new/delete.

Не съм наблюдавал досега алгоритъм от типа на GC в С-езиците. При освобождаване на памет се гледа дали околните блокове са свободни, и веднага се окрупняват. Поне при Майкрософтските компилатори е така.

Но истината е че скороста на new-delete не зависи от езика, а от производителя на основната библиотека на езика.

Извинявай, грешката е моя. При освобождаване на паметта блока само се маркира като свободен. При заемане на памет по един много странен (и бавен) алгоритъм се определя най-подходящия свободен блок и другите свободни около него се обединяват. И ако пак не стига памет, се обръща към free heap за нов блок. Затова Майкрософт С-тата са много неефективни при заемане на памет.

ami probwah go
a moje bi sym go probwal oste predi tebe...
... .NET studio-to beshe oste niakwa beta versia....
E TWA OPREDELENO NE ME NAKEFI!

В C++ може да се постигне много стабилно ускорение на операциите по заделяне/освобождаване на памет, ако вместо new/delete се използват STL алокатори. Разбира се, скоростта тогава зависи от съответната имплементация на STL, а Майкрософтската не е нито от най-стандартните, нито от най-бързите. Който обаче е опитвал STLport, има идея за какво ускорение говоря

abe pich ostavi decata da se kefiat :)
nali i nie taka se kefihme na vrmeto na JAVA kato prohozdashe , pyk moia starshi dev na vremto se kefiil na COBOL-a ...
deca sa, ste porabotiat v niakoia dobra firma i ste im doide akyla v glavata znaesh kak e vrme i rabota tribva ...

ta kato spomenavash GSM, e dobre da mi pokazesh .NET kartite za GSM?
zastoto ima 100K prodadeni ot 9.2001 do 30.Jan.2002 JAVA carti ot GemPlus
[линк]

Я аз да питам, че явно тука има хора дето по го разбират този език - има ли в Ц# аналог на friend, и ако не - защо мама му стара?! Че както чета по диагоналния метод с загуба на информация може да съм изтървал няколкото бита по въпроса

Reality is for people who can't face the Science Fiction!

A ti otvorko kakuv ezik znaesh ?