Data.table: هل تستخدم gcc على macOS كمترجم افتراضي؟

تم إنشاؤها على ٣١ أكتوبر ٢٠١٩ · 5تعليقات · مصدر: Rdatatable/data.table

بعد قراءة تعليمات المترجم وتجربتها لنظام macOS ، كنت أتساءل عما إذا كان gcc من homebrew سيكون بديلاً أفضل من llvm .

كما هو مذكور في wiki ، يتسبب برنامج التحويل البرمجي الذي تم تمكينه من خلال openmp في حدوث مشكلات مع الحزم الأخرى. من المرهق للغاية التعليق على مترجم llvm طوال الوقت إذا كان المرء يريد تجميع حزم أخرى.

أستخدم حاليًا الإعداد التالي مع تثبيت gcc عبر brew install gcc . لا توجد مشاكل حتى الآن لأية حزم.

CXX_STD = CXX14

CC=ccache /usr/local/bin/gcc-9
CC11=ccache /usr/local/bin/gcc-9
CC14=ccache /usr/local/bin/gcc-9
CXX=ccache /usr/local/bin/g++-9
CXX11=ccache /usr/local/bin/g++-9
CXX14=ccache /usr/local/bin/g++-9
## -O3 should be faster than -O2 (default) level optimisation ..
CFLAGS=-g -O3 -Wall -pedantic -std=gnu99 -mtune=native -pipe
CXXFLAGS=-g -O3 -Wall -pedantic -std=c++11 -mtune=native -pipe

بالإضافة إلى ذلك ، أنا أستخدم ccache كما ترى. بالاقتران مع إعدادات ~/.ccache/ccache.conf أدناه ، لديّ إعداد مترجم C قوي يدعم التخزين المؤقت.

max_size = 5.0G
# important for R CMD INSTALL *.tar.gz as tarballs are expanded freshly -> fresh ctime
sloppiness = include_file_ctime
# also important as the (temp.) directory name will differ
hash_dir = false

(تم أخذ الجزء ccache من هذا المنشور بواسطة Dirk.)

install platform-specific question

مصدر

pat-s

التعليق الأكثر فائدة

أنا أستخدم الطريقة المقترحة على https://github.com/rmacoslib/r-macos-rtools . أستخدم clang7 المتوفرة على https://cloud.r-project.org/bin/macosx/tools ويجب فقط تحديد ما يلي بـ ~/.R/Makevars :

CC=/usr/local/clang7/bin/clang
CXX=/usr/local/clang7/bin/clang++
CXX1X=/usr/local/clang7/bin/clang++
CXX11=/usr/local/clang7/bin/clang++
CXX14=/usr/local/clang7/bin/clang++
CXX17=/usr/local/clang7/bin/clang++
LDFLAGS=-L/usr/local/clang7/lib

وكل شيء يعمل بسلاسة وثبات.

لست متأكدًا من سبب تعقيد تعليمات macOS ، مما سيجعل المستخدمين المبتدئين الذين يستخدمون macOS يواجهون صعوبة حتى في تثبيت أحدث data.table من المصدر.

renkun-ken في ٣١ أكتوبر ٢٠١٩

👍2

ال 5 كومينتر

CC=/usr/local/clang7/bin/clang
CXX=/usr/local/clang7/bin/clang++
CXX1X=/usr/local/clang7/bin/clang++
CXX11=/usr/local/clang7/bin/clang++
CXX14=/usr/local/clang7/bin/clang++
CXX17=/usr/local/clang7/bin/clang++
LDFLAGS=-L/usr/local/clang7/lib

وكل شيء يعمل بسلاسة وثبات.

renkun-ken في ٣١ أكتوبر ٢٠١٩

👍2

بالنسبة لي ، فإن طريقة gcc هي الطريقة الأسرع والأكثر استقرارًا حتى الآن.
لست متأكدًا من التحذيرات الأخرى التي قد يقدمها هذا على macOS. 🤔

jangorecki من المسؤول عن الجزء المتعلق بـ C في {data.table} أو قد يكون لديه المزيد من المعرفة المتعمقة حول ما يجري وراء الكواليس؟

gcc هو المترجم المستخدم في جميع توزيعات Linux الرئيسية ، فهل هناك أي شيء يمنعه من تعيينه كإعداد افتراضي على macOS؟

pat-s في ٢ يناير ٢٠٢٠

👍1

لا يوجد شخص واحد مسؤول عن الجزء C من DT. كتب مات وآرون معظم مواد سي. AFAIRarunsrinivasan موجود على نظام macOS لذا قد تكون آرائه حول هذه المشكلة مفيدة للغاية.

jangorecki في ٣ يناير ٢٠٢٠

أنا أفضل استخدام دول مجلس التعاون الخليجي بنفسي أيضًا ، ولكن يحدث أن clang هو الخيار الافتراضي على MacOS. ستؤدي محاولة تغيير المترجم الافتراضي عالميًا لمستخدمي Mac إلى حدوث مشكلات أكثر مما يحلها. لذلك لا أعتقد أن تغيير التخلف عن السداد هو السبيل للذهاب.
الآن بعد أن تم دمج https://github.com/Rdatatable/data.table/pull/4735 (وتم نشره بالفعل على CRAN كـ 1.13.2) ، يجب أن يكون المستخدمون قادرين على تخصيص بنية البيانات الخاصة بهم بسهولة أكبر. لذلك يجب أن تتناول حالة الاستخدام الخاصة بك. إذا لم يكن الأمر كذلك ، فيرجى إخبارنا بذلك.

jangorecki في ٢٣ نوفمبر ٢٠٢٠

مرحبًا @ pat-s. شكرا لمساهمتك هنا. أود فقط أن أضيف أنه إذا كان من الممكن تبسيط تعليمات MacOS على صفحة التثبيت الخاصة بنا ، فسيكون ذلك موضع ترحيب كبير. يرجى المضي قدمًا وإجراء التغييرات مباشرة على الويكي. لا توجد أذونات مطلوبة لتغيير الويكي ، وهذا هو السبب في أننا جعلناه ويكيًا.