بعد تشغيل مثال لأداء لعبة، سنستطرد الآن إلى حد ما ونقارن الأداء مع
عدد قليل من تطبيقات بايثون. لنقم أولاً بإعداد المسرح لإجراء العمليات الحسابية، وتوفير سطر الأوامر
قدرات البرنامج النصي بايثون.

import argparse
import time
import math
import numpy as np
import os
from numba import njit
from joblib import Parallel, delayed

parser = argparse.ArgumentParser()
parser.add_argument("--workers", type=int, default=8)
parser.add_argument("--arraysize", type=int, default=100_000_000)
args = parser.parse_args()
# Set the number of threads to 1 for different libraries
print("=" * 80)
print(
    f"\nStarting the benchmark for {args.arraysize} elements "
    f"using {args.workers} threads/workers\n"
)

# Generate the data structures for the benchmark
array0 = [np.random.rand() for _ in range(args.arraysize)]
array1 = array0.copy()
array2 = array0.copy()
array_in_np = np.array(array1)
array_in_np_copy = array_in_np.copy()

وهؤلاء المتسابقون لدينا:

• قاعدة بايثون

  for i in range(len(array0)):
    array0[i] = math.cos(math.sin(math.sqrt(array0[i])))

• نومبي (خيط واحد)

np.sqrt(array_in_np, out=array_in_np)
np.sin(array_in_np, out=array_in_np)
np.cos(array_in_np, out=array_in_np)

• Joblib (لاحظ أن هذا المثال ليس مثالًا حقيقيًا في مكانه، لكنني لم أتمكن من تشغيله باستخدام الوسيطات out)

def compute_inplace_with_joblib(chunk):
    return np.cos(np.sin(np.sqrt(chunk))) #parallel function for joblib

chunks = np.array_split(array1, args.workers)  # Split the array into chunks
numresults = Parallel(n_jobs=args.workers)(
        delayed(compute_inplace_with_joblib)(chunk) for chunk in chunks
    )# Process each chunk in a separate thread
array1 = np.concatenate(numresults)  # Concatenate the results

• نومبا

@njit
def compute_inplace_with_numba(array):
    np.sqrt(array,array)
    np.sin(array,array)
    np.cos(array,array)
    ## njit will compile this function to machine code
compute_inplace_with_numba(array_in_np_copy)

وإليك نتائج التوقيت:

In place in (  base Python): 11.42 seconds
In place in (Python Joblib): 4.59 seconds
In place in ( Python Numba): 2.62 seconds
In place in ( Python Numpy): 0.92 seconds

النومبا أبطأ بشكل مدهش!؟ هل يمكن أن يكون ذلك بسبب الحمل الزائد للتجميع كما أشار mohawk2 في تبادل IRC حول هذه المشكلة؟
لاختبار ذلك، يجب علينا استدعاء compute_inplace_with_numba مرة واحدة قبل تنفيذ المعيار. يؤدي القيام بذلك إلى إظهار أن Numba أصبح الآن أسرع من Numpy.

In place in (  base Python): 11.89 seconds
In place in (Python Joblib): 4.42 seconds
In place in ( Python Numpy): 0.93 seconds
In place in ( Python Numba): 0.49 seconds

أخيرًا، قررت استخدام قاعدة R للركوب في نفس المثال:

n



التي أسفرت عن نتيجة التوقيت التالية:



Time in base R: 1.30 seconds




بالمقارنة مع نتائج بيرل نلاحظ ما يلي حول هذا المثال:

• كانت العمليات الداخلية في قاعدة Python ~ 3.5 أبطأ من Perl
• أعطى PDL المفرد وnumpy نتائج متطابقة تقريبًا، يليهما عن كثب R الأساسي
• يؤدي الفشل في حساب عبء التحويل البرمجي لـ Numba إلى ظهور انطباع كاذب بأنه أبطأ من Numpy. عند حساب أعباء الترجمة، يكون Numba أسرع بمقدار 2x من Numpy
• تم تحسين الموازاة مع Joblib مقارنةً بقاعدة Python، ولكنها كانت لا تزال أقل شأناً من تطبيق Perl ذو الخيط الواحد
• PDL متعدد الخيوط (و OpenMP) سحق (لم يتعطل!) كل التطبيقات الأخرى في جميع اللغات). نأمل هذا المنصب يوفر بعض الطعام للتفكير فيه اللغة التي ستستخدمها في العملية التالية المكثفة للبيانات/الحوسبة. سيتناول الجزء التالي من هذه السلسلة نفس المثال باستخدام المصفوفات في لغة C. وستوفر هذه الدفعة الأخيرة (نأمل) بعض الأفكار حول تأثير موضع الذاكرة والحمل الزائد الناتج عن استخدام اللغات المكتوبة ديناميكيًا.