Delphi & C

[vDelphi]

همه میدانیم که برنامه هائی که با زبانهای کامپایلری نوشته میشوند پس از یک بار کامپایل به ماشین کد تبدیل شده و پس از آن با سرعت یکسان اجرا میشوند. ولی سوالی که هست اینه که چرا برای نوشتن برنامه های سیستم و بازیهای سه بعدی همیشه زبان C به بقیه زبانها ترجیح داده میشود :roll: و چرا از Delphi استفاده نمیشود؟ (به حال برنامه های نوشته شده با Delphi هم با یک بار کامپایل به روتین های اسمبلی و ماشین کد تبدیل میشود!)

[Mohammad_Mnt]

کی گقته که نمی شه ؟
http://www.delphigamer.com

[vDelphi]

درسته که با Delphi هم میشه این کارا رو کرد. ولی هیچ وقت برای نوشتن بازیهائی مثل Quake یا Doom یا نوشتن برنامه های سطح پائین ؛ زبان Delphi به C ترجیح داده نمیشه! و اکثراً سرعت پائین تر Delphi رو مقصر میدونن! :(

[Mohammad_Mnt]

وقتی من PersianDoom رو با دلفی نوشتم ، نظرت عوض می شه :P

[Vahid_Nasiri]

در این مورد هیچ چیزی بهتر از نوشتن یک برنامه به زبانهای مختلف و مقایسه ی زمان اجرای آنها نیست.
برای مثال در یکی از مقالات به صورت زیر عمل شده بود:
زمان اجرای یک حلقه ی طولانی را در کامپایلرهای مختلف بررسی کرده اند که نمودار آن در شکل زیر آمده است:
همانطور که ملاحظه می کنید دلفی (متاسفانه شماره ی نگارش آن ذکر نشده بود) در طی 77 ثانیه این حلقه ی طولانی را به اتمام رسانده ولی ویژوال سی بسته به نگارش آن در طی زمانهایی بیشتر و یا بسیار کمتر .....

[vDelphi]

خب اگه این طوره پس چرا با Delphi هیچ پروژه ای در سطح بالا در حال کار نیست؟ مثلا یه سری به اینجاها بزنید:
http://www.plasmacode.com/
http://www.geocities.com/mrqzzz/
میتونید یه نسخه ساده و خلاصه از بازی Quake رو که با Delphi نوشته شده دانلود کنید!
ولی وقتی اجراش میکنید، حداکثر با 5FPS اجرا میشه! :(
حالا معلوم نیست چرا یه فایل exe که سورسش Delphi اینقدر کند اجرا میشه؟ :cry:

[Kambiz]

به نظر من به سه دلیل برنامه‌های سیستمی بیشتر با سی نوشته می‌شوند تا دلفی:

1. دلفی یک زبان سطح بالاست در صورتی که سی زبانی است سطح متوسط که برای نوشتن برنامه‌های ذکر شده مناسبتره.

2. عمر دلفی در مقایسه با سی خیلی کمه و به همین دلیل یک برنامه‌نویس سی می‌تونه منابع بیشتری برای انجام کارش در دسترس داشته باشه تا یک برنامه‌نویس دلفی.

3. این دلیل حقیقت ریشه در دو دلیل قبل داره. بیشتر کتابخانه‌های توابع که در سطح سیستم عمل می‌کنند به سی نوشته شده‌اند و از این رو استفاده از سی٬ بکارگیری این توابع را راحتتر می‌کنه چون که دیگه نیاز به ترجمه هدرها به دلفی نیست.

[vDelphi]

در زبانهائی که کامپایلری هستند دیگه معنی نداره که زبان سطح بالا باشه یا سطح پائین؟
چون نهایتاً همشون به روتین های اسمبلی تبدیل میشن! و همشون با سرعت یکسان اجرا میشن.

[Kambiz]

در زبانهائی که کامپایلری هستند دیگه معنی نداره که زبان سطح بالا باشه یا سطح پائین؟
چون نهایتاً همشون به روتین های اسمبلی تبدیل میشن! و همشون با سرعت یکسان اجرا میشن.

لطفا مطالب رجوع داده شده در زیر را بخوانید تا دلیل اینکه چرا سی یک زبان (و در واقع تنها زبان) سطح متوسط هست را بیابید.

Introduction to C Programming
Diatribe On Programming Language Design Features

بهتر بود پیش از رد صحبت من٬ می‌پرسیدید چرا. هدف به شراکت گذاشتن معلومات است نه نفی یکدیگر.

[vDelphi]

من حرف کسی رو رد نکردم! اتفاقاً خودم هم یکی از دلایل انتخاب C رو همین مسئله میدونم.(سطح پائین تر بودن C ).ولی سوالی که اینجا مطرح میشه اینه که چرا بعد از کامپایل( صرف نظر از مدت زمان کامپایل) ، بعد ار اینکه فایل exe ساخته شد، باز هم سرعت اجرای برنامه ای که سورسش C بوده، بیشتره؟؟
شاید بهتر بود جمله ام رو از اول به صورت سوالی مطرح می کردم تا سوء تفاهمی پیش نیاد. :(

[Mashatan]

برای فهمیدنش فقط کافیه یک Loop با شرط یکسان در Delphi و C درست کنید و EXE کنید و بعد
Trace کنید ببینید چه تفاوتهای دارند :)

اگر یک نفر زحمت بکشد و این کار رو کند من کار Trace شو بر عهده میگیرم :wink: ( C ندارم ! )

شاد زی
مشاطان

[Kambiz]

سوال اولیه در رابطه این بود که چرا از سی بیشتر استفاده می‌شه و من هم در پاسخ به اون پرسش مطلبم رو گفتم. در هر حال اگر عمل اشتباهی انجام داده‌ام می‌بخشید.

در مورد اون 5 فریم بر ثانیه بازی نوشته شده با دلفی نمیشه گناه رو گردن دلفی انداخت و منطقی‌تر به نظر میاد که مشکل رو از الگوریتم بکار رفته و همچنین عدم بهینه بودن کد نوشته شده توسط برنامه‌نویس بدونیم.

علی (مشاطان) جان٬ از اون کاری هم که گفتی نمی‌شه نتیجه نهایی رو گرفت. هر کامپایلری نقاط قوت و ضعف خودش رو داره و نمی‌شه تنها بامقایسه دو تا برنامه یک جور گفت که کدوم کامپایلر کد بهینه‌تری بیرون می‌ده. به عنوان مثال ممکنه یک کامپایلر در تولید کد برای آرایه‌ها بهترین باشه و از طرف دیگه تو تولید کد برای محاسبات عددی بدترین کد ممکن رو درست کنه.

دو نفر کار مقایسه‌ی سرعت و حافظه‌ى کد تولید شده توسط 48 کامپایلر مختلف رو با در نظر شرایط کاربردی گوناگون بطور مفصل انجام دادند. نتایج رو در آدرس زیر می‌تونید ببینید:
http://dada.perl.it/shootout
در پایین صفحه فهرست کامپایلرهایی هست که مورد آزمایش قرار گرفته‌اند. در سمت چپ هم فهرست الگوریتمهایی که تست روی اونها انجام شده و با کلیک کردن روی اونها نتیجه حاصل رو می‌بینید. سورس تمام برنامه‌ها به همه زبانها هم اونجا هست.

مشخصات کامپیوتر و سیستم عامل رو هم تو صفحه زیر پیدا می‌کنید:
http://dada.perl.it/shootout/platform_details.html

و از همه مهمتر نتیجه نهایی که با در نظر گرفتن وزن نوع تست انجام شده نسبت به اندازه کاربرد اون در نوشتن برنامه‌ها حاصل شده اینجاست:

سی پی یو: دلفی اوله
http://dada.perl.it/shootout/craps.html

حافظه: دلفی دومه ولی اولی سی نیست. :)
http://dada.perl.it/shootout/craps_mem.html

تعداد خطهای برنامه: تو این مورد مفسرها اومدند بالا و کامپایلرها ته لیست قرار دارند
http://dada.perl.it/shootout/craps_loc.html

سی پی یو و حافظه: بازم دلفی اوله
http://dada.perl.it/shootout/craps_cpumem.html

سی پی یو و حافظه و تعداد خطهای برنامه: اینجا دلفی هشتم هست و البته قبل از سی.
http://dada.perl.it/shootout/craps_cpumemloc.html

این نتایج نشون میده که کامپیلر سی هیچ نقشی تو استفاده اون برای کاربردهای سیستمی نداره.

[Vahid_Nasiri]

من دیروز این مطلب را در یک سایت دیدم . شاید یکی از دلایل روانی استفاده نکردن کردن از دلفی این موضوع زیر باشد:

There is a widely held misconception that Delphi is only capable of writing database applications. Most developers believe Delphi lacks the speed and flexibility to write a really great game, let alone a real-time, 3D game. Borland, the makers of Delphi, concentrate their business almost solely on database applications, which does not help Delphi's reputation as a boring, plodding language.

http://www.pythianproject.org/cgi-bi...rver.exe/About

به صورت خلاصه همه دلفی را به دیتابیس نویسی می شناسند (عمدتا).

[Kambiz]

من دیروز این مطلب را در یک سایت دیدم . شاید یکی از دلایل روانی استفاده نکردن کردن از دلفی این موضوع زیر باشد:

There is a widely held misconception that Delphi is only capable of writing database applications. Most developers believe Delphi lacks the speed and flexibility to write a really great game, let alone a real-time, 3D game. Borland, the makers of Delphi, concentrate their business almost solely on database applications, which does not help Delphi's reputation as a boring, plodding language.

http://www.pythianproject.org/cgi-bi...rver.exe/About

به صورت خلاصه همه دلفی را به دیتابیس نویسی می شناسند (عمدتا).

خود بورلند هم تو تبلیغاتش بیشتر رو برنامه‌نویسی دیتابیسی تاکید می‌کنه. شاید با مایکروسافت رو این زمینه توافقی دارند. :)

[vDelphi]

البته همه در مورد سرعت و بهینه بودن کامپایلر Delphi اتفاق نظر دارن! :)
ولی سوال من اینه که چرا وقتی فایل exe ساخته شد، باز هم سرعت اجرا مطرح میشه؟
سرعت اجرای فایل exe که ربطی به سورس اولیه نداره! چون فکر کنم سرعت اجرای ماشین کد به سخت افزار سیستم بستگی داره!

[Kambiz]

البته همه در مورد سرعت و بهینه بودن کامپایلر Delphi اتفاق نظر دارن! :)
ولی سوال من اینه که چرا وقتی فایل exe ساخته شد، باز هم سرعت اجرا مطرح میشه؟
سرعت اجرای فایل exe که ربطی به سورس اولیه نداره! چون فکر کنم سرعت اجرای ماشین کد به سخت افزار سیستم بستگی داره!

سرعت اجرا مربوط به ماشین کد تولید شده هست، وگرنه مترجم زبان که برنامه رو اجرا نمی‌کنه.

فرض کنید که ماشینی داریم که دو تا رجیستر A و B داره و فقط دستورات زیر براش تعریف شده باشند:

MOVE
دستور انتساب برای
- یک رجیستر به یک متغیر حافظه
- یک متغییر حافظه به یک رجیستر
- یک رجیستر به رجیستر دیگر
- یک عدد ثابت به یک رجیستر
* دقت کنید در این ماشین دستور انتساب به یک متغییر حافظه فقط از طریق یک رجیستر ممکن است.

ADD
به رجیستر یک مقدار ثابت را اضافه می‌کند.

SUB
از رجیستر یک مقدار ثابت را کم می‌کند.

JMP
مسیر اجرای برنامه را به آدرس تعیین شده منشعب می‌کند.

JMPEQ
مقدار یک رجیستر را با یک عدد ثابت مقایسه می‌کند و در صورت تساوی مسیر اجرای برنامه را به آدرس تعیین شده منشعب می‌کند.

این ماشینی که فرض کردیم کار زیادی نمی‌تونه انجام بده ولی برای مثالی که می‌خواهم بزنم کافی است.

کد زیر را در نظر بگیرید:

X := 0;

I := 100000;

while I <> 0 do

begin

  X := X + 5;

  I := I - 1;

end;

write(X)

اگر بخواهیم کد بالا را به زبان ماشینی خودمان ترجمه کنیم حاصل می‌تواند این چنین باشد:

    // X := 0

    MOVE   A, 0

    MOVE   X, A



    // I := 1000000

    MOVE   A, 1000000

    MOVE   I, A





LOOP:



    // WHILE I <> 0 do

    MOVE   A, I

    JMPEQ  A, 0, ENDLOOP

  

        // X := X + 5

        MOVE   A, X

        ADD    A, 5

        MOVE   X, A



        // I := I - 1

        MOVE   A, I

        SUB    A, 1

        MOVE   I, A



    JMP   LOOP



:ENDLOOP



// Write(X)

...

همانطور که حتما" متوجه شده‌اید٬ اگر کد ماشین کد بالا را نه برای ترجمه خط به خط بلکه برای رسیدن به جواب برنامه‌ای که نوشته‌ایم بنویسیم٬ کد حاصل بسیار بهینه‌تر خواهد بود:

    // X := 0

    MOVE   B, 0



    // I := 1000000

    MOVE   A, 100000



LOOP:



    // WHILE I <> 0 do

    JMPEQ A, 0, ENDLOOP

  

        // X := X + 5

        ADD    B, 5



        // I := I - 1

        SUB    A, 1



    JMP   LOOP



:ENDLOOP



MOVE   X, B

MOVE   I, A



// write(X)

...

با اینکه هر دو کد در خاتمه مقدار متغییر X و I را به درستی محاسبه و ذخیره می‌کنند٬ اما در کد دوم از حلقه‌ای که یک میلیون بار تکرار می‌شود 4 دستور العمل اضافه برداشته شده است. پس ماشین ما در اجرای کد دوم 4 میلیون دستورالعمل کمتر اجرا می‌کند.

در مثال بالا٬ ماشین و برنامه ثابت هستند ولی ترجمه برنامه به زبان ماشین متفاوت است و در نتیجه سرعت اجرا هم متفاوت خواهد بود.

حالتی که در این مثال پیش آمد در مورد کامپایلرهای زبانهای کامپیوتری هم اتفاق می‌افتد و به همین دلیل است که سرعت اجرای exe یک برنامه C که با <span dir=ltr>BC++‎Builder</span> کامپایل شده ممکن است با کامپایل شدن توسط <span dir=ltr>VC++‎</span> تغییر کند.

* در اخرین کد نام یک رجیستر اشتباه وارد شده بود که اصلاح شد. همیشه تو هر کدی حداقل یک دونه باگ پیدا میشه. :)

[vDelphi]

ممنون از جوابتون
پس باید منتظر بمونیم تا وقتی که بورلند کامپایلری ارائه بده که سرعت اجراش از کد C بیشتر باشه! :mrgreen: 8)

[Kambiz]

ممنون از جوابتون
پس باید منتظر بمونیم تا وقتی که بورلند کامپایلری ارائه بده که سرعت اجراش از کد C بیشتر باشه! :mrgreen: 8)

گویا به نتایج حاصل از مقایسه کامپایلرهای مختلف، که در یکی از پستهای قبلیم ذکر کردم دقت نکرده‌اید. از سالها قبل بهترین تکنولوژی کامپایلر در اختیار بورلند بوده و هست و در کامپایلر این شرکت در مقایسه با کامپایلرهای دیگر بهینه‌ترین کد را ارائه می‌دهد.

کد تولید شده توسط کامپایلرهای بورلند تا آن حد بهینه هستند که اگر کد حاصل از ترجمه دستی یک برنامه توسط فردی با دانش متوسط از زبان ماشین را با کد حاصل از کامپایلرهای بورلند مقایسه کنیم٬ کد حاصل از کامپایلر بهینه‌تر است.

توجه داشته باشید که صرفا با دیدن دو برنامه مشابه یکی با C و دیگری با Delphi نمی‌توان کندی یکی از برنامه‌ها را به گردن کامپایلر آن انداخت. تنها در صورتی چنین مقایسه‌ای درست است که هم الگوریتمها و هم میزان مهارت برنامه‌نویسهای هر دو برنامه مشابه باشند.

به عنوان مثال می‌توان یک برنامه مرتب سازی برای یک میلیون عدد را با الگوریتم Quick Sort با بیسیک نوشت و همان برنامه مرتب سازی را با الگوریتم Bubble Sort با سی داشت. ممکن است در این مثال برنامه بیسیک سریعتر به جواب برسد ولی این دلیل بر این نیست که بیسیک از سی سریعتر است.

[khafanovich]

من وظیفه خودم میدونم که ازدوست عزیزمون delphi area
تشکر کنم.بسیار عالی و جامع و کامل توضیح دادید.
بنظر من هم بورلند دلفی قویترین ابزار rad برای توسعه انواع برنامه هاست.

[vDelphi]

باز هم از جوابهای دوستان تشکر می کنم. :)
پس اگر کامپایلر Delphi کد بهینه تری را نسبت به VC تولید میکند(که حتماً هم می کنه!)پس دلیله اینکه برنامه های Delphi معمولاً کند تر اجرا میشه، تقصیره الگوریتم به کار رفته است؟ چون وقتی کد بهینه تر تولید میشه، پس کندی اجرا تقصیره الگوریتم برنامه نویسه! :oops: