آيا کدهاي BCB به Delphi تبديل مي شن؟

[a_mzadeh]

سلام
راستش قديما زمانيکه ما با Borland C++‎ Builder 6 برنامه مي نوشتيم، کدهاي نوشته شده، قبل از کامپايل به کد دلفي تبديل مي شدن (البته پنهان از ديد برنامه نويس). مي خواستم بدونم آيا در نسخه هاي جديد هم وضع به همين صورت هست.
اگر در نسخه هاي جديد هم به اين صورت عمل ميشه که کد نوشته شده تبديل به کد دلفي ميشه، آيا بهتر نيست که از خود دلفي استفاده بشه؟

با تشکر

[amiin1364]

سلام خیر
میشه کد هاشونو لینک کرد اما تبدیل نمیشه کامپایلر مجزا دارن
application های دلفی خیلی کند تر هستند

[vcldeveloper]

application های دلفی خیلی کند تر هستند

همچین حرفی هیچ جنبه فنی نداره. برنامه های کامپایل شده با C++‎ Builder و حتی برنامه های کامپایل شده با Visual C++‎ برتری خاصی نسبت به برنامه های کامپایل شده با دلفی از نظر سرعت ندارند.

قبل از کامپايل به کد دلفي تبديل مي شدن (البته پنهان از ديد برنامه نويس). مي خواستم بدونم آيا در نسخه هاي جديد هم وضع به همين صورت هست.

از آنجایی که در C++‎ Builder امکان استفاده از کتابخانه VCL وجود داره، و VCL با دلفی نوشته شده، C++‎ Builder برای کامپایل کدهای VCL و لینک آنها به خروجی از یک کامپایلر داخلی دلفی استفاده میکنه.

[amiin1364]

delphi:
var
Form1: TForm1;
t,i,r:longint;

implementation
{$R *.dfm}
............
...........
...........
procedure TForm1.Button1Click(Sender: TObject);
begin
r:=0;
t:=GetTickCount();
while r<10000000 do
r:=r+1;
t:=GetTickCount()-t;
ShowMessage(IntToStr(t)+','+IntToStr(r));
end;
end.


/////////////////////////////////////////////
c builder:
long int i=0,r=0,t;
void __fastcall TForm1::Button1Click(TObject *Sender)
{

t=GetTickCount();
while (r<10000000)
r++;
t=GetTickCount()-t;
ShowMessage(IntToStr(t)+","+IntToStr(r));
}


////////////////////////////////////////////////
شما که میگید:همچین حرفی هیچ جنبه فنی نداره. برنامه های کامپایل شده با C++‎ Builder و حتی برنامه های کامپایل شده با Visual C++‎ برتری خاصی نسبت به برنامه های کامپایل شده با دلفی از نظر سرعت ندارند.

توی فرم فقط button.

این دو تا رو با هم مقایسه کنید ! کد فرقی میکنه؟حتی data type هم یکی است.

حالا چند بار روی button کنید

زمان محاسبه برای دلفی 120تا 130

130 تا 0 برای cbuilder !

حالا باز بگید جنبه فنی... !!!. زمان محاسبه بسته به systemعوض میشه.اما اختلافش نه

[vcldeveloper]

اتفاقا برخلاف ادعای شما، من کد را روی هر دو کامپایلر آزمایش کردم، و در دفعات تکرار مختلف، نتایج بدست آمده به هم نزدیک بودند.

برای اینکه سایر کاربران هم بتونند بررسی کنند، من سورس کد استفاده شده و فایل های EXE تولید شده را اینجا قرار میدم. همچنین برای اینکه بیشتر متوجه اشتباه خودتون بشید، کد Disassemble شده این دو را هم براتون میزارم، تا ببینید کامپایلر C++‎ Builder و دلفی چه کد ماشینی تولید کردند، و این کدهای ماشین چقدر به شباهت دارند:

Delphi vs C++‎ Builder.gif

همانطور که در تصویر هم مشخص هست، کدهای تولید شده بسیار مشابه هم هستند. یک تفاوت این هست که C++‎ Builder در مقداردهی اولیه متغیرهای محلی 3 خط کد اضافه تولید کرده، در حالی که کامپایلر دلفی در صورت نوشتن عبارت t := 0 در سورس کد، آن را به عنوان کد غیرضروری در نظر میگیره، و براش کد ماشینی تولید نمیکنه. تفاوت دوم هم در این هست که کامپایلر دلفی استفاده بیشتری از رجیسترهای CPU میکنه.


کامپایلرهای استفاده شده در تست:

برای انجام این تست ها از Delphi 2009 و C++‎ Builder 2009 بدون نصب هیچ آپدیتی استفاده شده. همچنین Build Configuration برای هر دو پروژه بر روی Release تنظیم شده بود.

مشخصات سیستم اجرا کننده تست:

• AMD Phenom II 940 X4 3.0 Ghz
• 4 GB of DDR2 1066 RAM
• Vista 64bit Service Pack 2

تغییرات کد نسبت به کدی که در پست شماره 4 تاپیک قرار داده شده:

1. حذف متغیر زاید i از کد.
2. تغییر نوع داده متغیرها در هر دو کد به DWord.
3. تعریف متغیرها بصورت Local بجای تعریف متغیرها به عنوان فیلد کلاس در دلفی و متغیرهای Global در ++C
4. استفاده از Inc در کد دلفی بجای عبارت r := r + 1 چون Inc در دلفی معادل ++r در ++C است. البته در دلفی 2009 امکان استفاده از ++r وجود داشت، ولی برای سازگاری با کامپایلرهای قدیمی از Inc استفاده شد.
5. به دلیل سریع بودن سیستم انجام دهنده تست، و برای واضح تر شدن نتایج، تعداد تکرار حلقه 10 برابر شد.

نتایج تست در پنج بار اجرا:

دلفی:

1. 187
2. 250
3. 219
4. 188
5. 202

میانگین = 209.2

C++‎ Builder:

1. 187
2. 202
3. 219
4. 203
5. 265

میانگین = 215.2

سورس کدها و فایل های اجرایی تولید شده:

https://barnamenevis.org/downlo...?do=file&id=20


نکته مهم:
دوستان توجه کنند که عملکرد یک کامپایلر در یک Tight loop، مثل کد مورد آزمایش در اینجا، لزوما نشان دهنده سرعت بیشتر یک کامپایلر نسبت به کامپایلر دیگر نیست، و باید حالت های مختلف را برای این منظور بررسی کرد.

[amiin1364]

سلام
دوست عزیز نتیجه کار شما هم درسته اما شما از compiler optimize استفاده

نکردید این generate fastest code: optimize است که این دو تا رو از هم جدا میکنه اگر

استفاده کنید نتیجه همونه که گفتم.من مثل شما زود قضاوت نمیکنم . اگر شما این گزینه رو

توی delphi دیدید

به ما هم بگید . درضمن از پست های خوبتون ممنون

[vcldeveloper]

اما شما از compiler optimize استفاده

نکردید این generate fastest code: optimize است که این دو تا رو از هم جدا میکنه اگر

استفاده کنید نتیجه همونه که گفتم.من مثل شما زود قضاوت نمیکنم . اگر شما این گزینه رو

توی delphi دیدید

به ما هم بگید .

وقتی میگم حرفتون غیر فنی هست، بخاطر همین اظهار نظرها ست. اگر به کدهای ماشین تولید شده دقت می کردید، همچین اظهار نظری که ناشی از عدم شناخت خودتان از دلفی و C++‎ Builder هست، نمی کردید. شما فکر می کنید کامپایلر غیر از تولید کد ماشین، معجزه دیگه ایی میکنه؟!

اولا Compiler Optimization در دلفی وجود داره، و بطور پیش فرض هم فعال هست. ثانیا، در پست قبل گفته شد که Build Configuration برای هر دو کامپایلر بر روی Release تنظیم شد. اگر می رفتید و تنظیمات پروژه در C++‎ Builder را برای حالت Release چک می کردید، می دیدید که گزینه Generate fastest code فعال شده. اگر سورس کد پیوست شده را دانلود می کردید، و به تنظیمات پروژه دقت می کردید هم می توانستید ببینید که این گزینه فعال هست. حتی در صورت فعال کردن سایر Optimization های مربوطه (مثل استفاده از رجیسترهای CPU و غیره) باز تفاوت فاحشی بوجود نخواهد آمد.

[amiin1364]

اولا Compiler Optimization در دلفی وجود داره، و بطور پیش فرض هم فعال هست

1:من که نگفتم نیست گفتم گزینه Generate fastest code رو تو delphi ندیدم

قتی میگم حرفتون غیر فنی هست، بخاطر همین اظهار نظرها ست. اگر به کدهای ماشین تولید شده دقت می کردید، همچین اظهار نظری که ناشی از عدم شناخت خودتان از دلفی و C++‎ Builder
هست، نمی کردید. شما فکر می کنید کامپایلر غیر از تولید کد ماشین، معجزه دیگه ایی میکنه؟!

2.من که نتیجه گرفتم کد شما رو دانلود کنم؟دانلود نکرده از کجا ببینم ؟شما که آشنایی دارید باید احتمال بدید که version کامپایلر من فرق کنه !؟اینم که گفتم option من بدون option نتیجه مشابه گرفته بودم

3.بهتره که آدم روی چیزی تعصب نداشته باشه !من که کد گذاشتم test کردم وگر نه بیمار نیستم که و cbuilder رو هم من ننوشتم که ازش دفاع کنم.اگه دنبال علت باشیم بهتره .منم نگفتم شما اشتباه میکنید ولی ....تازه اگه همه چیز بلد بودم توی شرکت microsoft کار میکردم.
/////////////////////////////////////////////////////
الان که برنامه شما رو دیدم یه تفاوت دیدم که گفته بودید:
دلیل اصلی همینه: تعریف متغیرها بصورت Local بجای تعریف متغیرها به عنوان فیلد کلاس در دلفی و متغیرهای Global در ++C
الان دلفی سریعتره اما اگه همون جوری بشه global نتیجه بد جوری بر عکسه
test کنید اگه همینجور بود و اگه میدونید علت رو لطفا توضیح بدید .
ممنون

[vcldeveloper]

من که نگفتم نیست گفتم گزینه Generate fastest code رو تو delphi ندیدم

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

بهتره که آدم روی چیزی تعصب نداشته باشه !من که کد گذاشتم test کردم وگر نه بیمار نیستم که و cbuilder رو هم من ننوشتم که ازش دفاع کنم.

خب، اینو باید برای خودتون تکرار کنید. کاری که کامپایلر میکنه اینه که کد ماشین تولید کنه. اگر نوع دستورات یا تعداد دستوراتی که کامپایلر ++C شما برای کد مربوطه تولید کرد با چیزی که من اینچا گذاشتم فرق داشت، اون وقت می تونید اظهار نظر کنید که فلان کامپایلر از کامپایلر دیگه کد سریعتر یا کندتری تولید میکنه. دستورات ماشین هم برای CPU فقط یک مفهوم دارند. اینطور نیست که مثلا MOVایی که یک کامپایلر تولید میکنه سریعتر از MOVایی باشه که یک کامپایلر دیگه تولید میکنه، بلکه برای CPU یک دستور ماشین MOV همیشه یک چیز هست. پس در یک سیستم سخت افزاری ثابت، کدهای ماشین یکسان عملکردهای یکسانی تولید می کنند.

الان که برنامه شما رو دیدم یه تفاوت دیدم که گفته بودید:
دلیل اصلی همینه: تعریف متغیرها بصورت Local بجای تعریف متغیرها به عنوان فیلد کلاس در دلفی و متغیرهای Global در ++C
الان دلفی سریعتره اما اگه همون جوری بشه global نتیجه بد جوری بر عکسه
test کنید اگه همینجور بود و اگه میدونید علت رو لطفا توضیح بدید .

در یک مقایسه شما باید شرایط یکسانی را برای هر دو طرف بوجود بیارید. در کد دلفی شما، r به عنوان یک فیلد از یک کلاس تعریف شد، در حالی که در کد ++C شما، r به عنوان یک متغیر Global تعریف شد. یک متغیر Global با یک فیلد کلاس تفاوت داره، شما یا باید هر در هر دو کد متغیر را به عنوان فیلد تعریف می کردید، یا به عنوان متغیر Global، ولی برای همچین کدی، بهترین حالت استفاده از متغیر محلی بود که من در هر دو کد ازش استفاده کردم.
حتی اگر شما متغیرهای هر دو کد را تبدیل به فیلد کلاس کنید، یا متغیرهای هر دو کد را تبدیل به متغیر Global کنید هم هر چند سرعت هر دو کد کاهش پیدا می کند، ولی نسبت نتایج در همین محدوده باقی می ماند. اگر در یکی از کدها متغیر را به عنوان فیلد کلاس و در دیگری به عنوان متغیر Global تعریف کنید، آن وقت آن کدی که از فیلد کلاس استفاده می کند مقداری کندتر از کدی که از متغیر Global استفاده می کند، خواهد شد. علتش هم این هست که وقتی متغیر را به عنوان فیلد کلاس تعریف می کنید، تعداد دستورات ماشینی که برای دسترسی به مقدار متغیر یا تغییر مقدار آن تولید می شود، بیشتر از حالتی است که متغیر را بصورت متغیر محلی یا Global تعریف می کنید.

اینم که گفتم option من بدون option نتیجه مشابه گرفته بودم

Options یک پروژه با همون پروژه ذخیره میشه، و ارتباطی با تنظیماتی که شما بر روی IDE خودتان انجام دادید، نداره.

شما که آشنایی دارید باید احتمال بدید که version کامپایلر من فرق کنه !؟

شما باید نسخه های هم سنگ هم را با هم مقایسه کنید، مثلا مقایسه C++‎ Builder 2009 با Delphi 4 کار درستی نیست، بلکه وقتی دارید جدیدترین نسخه یک کامپایلر را بررسی می کنید، برای کامپایلر دیگه هم باید جدیدترین نسخه را استفاده کنید.

[amiin1364]

شما باید نسخه های هم سنگ هم را با هم مقایسه کنید

هر دو تا توی borland develope studio 2006 بودن

یک پروژه با همون پروژه ذخیره میشه، و ارتباطی با تنظیماتی که شما بر روی IDE خودتان انجام دادید، نداره.

این که مشخص بود فکر نمی کردم باید این موضوع ساده رو توضیح بدم

در یک مقایسه شما باید شرایط یکسانی را برای هر دو طرف بوجود بیارید. در کد دلفی شما، r به عنوان یک فیلد از یک کلاس تعریف شد، در حالی که در کد ++C شما، r به عنوان یک متغیر Global تعریف شد.

قبل از این که بگید یه نگاه به پست بندازین وهر دو gobal هستند

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

در cbuilder سه گزینه مجزا شده speed , disable, small code پس احتمالا منظور شما اینه که
توی delphi که تنها optimize رو داره این دو تا رو با هم انجام میده

////////////////////////
به هر حال این نتیجه ای است که گرفتم تحت این شرایط شاید مربوط به این نسخه borland باشه و شاید هم نه شاید باید بیشتر دقت کرد تا علت رو فهمید آخه توی نتیجه ی خود شما هم نتیجه delphi بهتر بوده
که نتیجه من هم وقتی هر دو local بودن اینجوری شد.که اگه دستور مثلا move برای هر دو یکی است که هست پس علت چیه؟
ممنون

[vcldeveloper]

پس علت چیه؟

یک علت میتونه این باشه که دلفی بهتر از رجیسترهای CPU استفاده میکنه.

[1485159]

من یکمی فهمیدم
یعنی برنامه ای که ما مینویسیم به دلفی تبدیل میشن و بعد اجرا میشن؟