ثابت نبودن زمان اجرای یک کد C

[abedzadeh]

سلام دوستان
من یک برنامه‌ی ساده C دارم که به صورت زیر عمل میکنه :

در ابتدای کار یک آرایه‌ی 1,000,000 تایی رو با اعداد رندم پر میکنه (پ.ن ۱)
سپس توسط تابع merge sort (و یا quick sort) که توسط خودم نوشته شده (از توابع آماده استفاده نشده) آرایه مرتب میشه
قبل از اینکه بخش مرتب سازی شروع بشه با استفاده از

کد: [انتخاب]

clock_t start = clock();زمان شروع رو تعیین میکنه (پ.ن ۲)
و پس از مرتب سازی با استفاده از

کد: [انتخاب]

clock_t stop = clock();زمان پایان رو تعیین میکنه
حالا تفاضل این دو رو پرینت کنه که در واقع میشه زمان اجرای برنامه

چندین بار برنامه رو روی سیستم خودم و سیستم دانشگاه اجرا کردم و نتایج برام عجیب بود
خروجی‌ها روی سیستم خودم (پ.ن ۳) بین 200ms تا 400ms متغییره و هربار نتیجه در این بازه تغییر میکنه
اما خروجی روی سیستم‌ دانشگاه که یک توزیع لایو (پ.ن ۳) روی اون‌ اجرا شده بود تغیرات زمانی بسیار بسیار کم و قابل چشم پوشی داشت در حدود 300ms بود

سوال‌های‌ بنده اینه :
۱. چرا برنامه‌ای که فقط یک کار ثابت رو انجام میده ، هر بار در زمان متفاوتی اجرا میشه (منظورم روی سیستم خودم هست) ؟ آیا من جایی اشتباه کردم و یا به دلیل دیگری این اتفاق می‌افتد؟
۲. آیا این تفاوت در سیستم خودم مربوط به سیستم‌عامل هست و یا زبان برنامه‌نویسی ؟ و اینکه آیا قابل حل هست یا خیر ؟
پ.ن ۱:
در ابتدای برنامه از

کد: [انتخاب]

srand(0);استفاده کردم که هر بار اعداد ثابتی توسط تابع رندوم تولید بشه . بنظرم این کار باعث میشه شرایط برابرتر باشه برای هربار اجرا

پ.ن ۲:
در مورد نحوه‌ی کار تابع clock و عملیاتی که انجام میده دقیق مطلع نیستم. اما ظاهرا تعداد کلاک‌های اشغالی توسط برنامه رو میشماره و در نهایت توسط

کد: [انتخاب]

double time = (double)(stop - start) * 1000 / CLOCKS_PER_SEC;قابل محاسبه هست

پ.ن ۳:
مشخصات سیستم خودم : یک لپ‌تاپ اوبونتو ۱۶.۰۴ - ۶گیگابایت رم و پردازنده intel core i7
مشخصات سیستم دانشگاه : یک پی‌سی با لوبونتو ۱۶.۰۴ که به صورت لایو بالا اومده - ۴ گیگابایت رم

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

ضمیمه ۱ : نتیجه‌ روی سیستم خودم
ضمیمه ۲ : merge sort
ضمیمه ۳ : quick sort

عذرخواهی میکنم که طولانی شد
با تشکر

[مجتبی باغبان]

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

[abedzadeh]

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

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

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

[Geek]

آزمایشت کنترل شده نیست
روی سیستم خودت لوبونتو رو لایو بیار بالا و تست کن.

[abedzadeh]

آزمایشت کنترل شده نیست
روی سیستم خودت لوبونتو رو لایو بیار بالا و تست کن.

والا زیاد در مورد کنترل کردن آزمایش‌های اینچنینی اطلاعی ندارم 
ولی تست کردم و نتیجه شد مثل اوبونتوی خودم ، یعنی تغییرات قابل توجه هست

[احمد حقیقی]

مشخصات پردازنده ات (مثلا فرکانس) و سایر برنامه هایی که در حال اجرا هستند تاثیر گذاره روش
درضمن سیستم عامل هم موثره هست که در اینجا چون از یک سیستم عامل استفاده میکنید،‌فرقی نداره به نظرم

[فاروق]

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