C # में असुरक्षित जेनेरिक गणित

दुर्भाग्य से, रूसी में शुरू हुई कुरूपता के नाम का पर्याप्त रूप से अनुवाद करना आसान नहीं था। मुझे यह जानकर आश्चर्य हुआ कि आधिकारिक MSDN दस्तावेज़ीकरण "जेनरिक" "टेम्पलेट" ( C++ टेम्पलेट के समान, मुझे लगता है) कहता है। C# माध्यम से "CLR के चौथे संस्करण में C# जिसने मुझे मारा , पीटर द्वारा अनुवादित जेफरी रिक्टर , जेनेरिक को "सामान्यीकरण" कहा जाता है, जो अवधारणा के सार को बेहतर ढंग से दर्शाता है। यह लेख C# में असुरक्षित सामान्यीकृत गणितीय कार्यों के बारे में बात करेगा। यह देखते हुए कि C# उच्च-प्रदर्शन कंप्यूटिंग के लिए अभिप्रेत नहीं है (हालांकि, निश्चित रूप से, यह इसके लिए सक्षम है, लेकिन यह समान C/C++ साथ प्रतिस्पर्धा करने में सक्षम नहीं है), BCL में गणितीय कार्यों पर अधिक ध्यान नहीं दिया जाता है। आइए C# और CLR का उपयोग करके बुनियादी अंकगणितीय प्रकारों के साथ काम को सरल बनाने का प्रयास करें।

समस्या का बयान

डिस्क्लेमर : लेख में कई कोड अंश होंगे, जिनमें से कुछ मैं एंड्री शेकिन द्वारा अद्भुत संसाधन शार्पलैब ( Gi r tHub ) के लिंक के साथ चित्रित करूंगा ।

एक तरह से या किसी अन्य गणना में अधिकांश गणना बुनियादी कार्यों के लिए उबालती है। जोड़, घटाव (व्युत्क्रम, ऋणात्मक), गुणन और विभाजन को समानता के लिए तुलना और जाँच के संचालन द्वारा पूरक किया जा सकता है। बेशक, इन सभी कार्यों को आसानी से और किसी भी मूल अंकगणितीय प्रकार के C# चर पर किया जा सकता है। एकमात्र समस्या यह है कि C# को उस संकलन समय पर पता होना चाहिए कि संचालन विशिष्ट प्रकारों पर किया जाता है, और ऐसा लगता है कि एक विधि लिखना जो समान रूप से कुशलतापूर्वक (और पारदर्शी रूप से) दो पूर्णांक जोड़ता है और दो फ़्लोटिंग-पॉइंट नंबर असंभव है।

आइए कुछ साधारण गणितीय क्रिया करने वाले एक काल्पनिक सामान्यीकृत विधि के लिए हमारी इच्छाओं को निर्दिष्ट करें:

1. एक विधि में सामान्यीकृत प्रकार के प्रतिबंध होने चाहिए जो हमें दो मनमाने प्रकारों को जोड़ने (या गुणा, विभाजित करने) की कोशिश करने से बचाते हैं। हमें कुछ सामान्य प्रकार की बाधाओं की आवश्यकता है।
2. प्रयोग की शुद्धता के लिए, स्वीकृत और लौटे प्रकार समान होने चाहिए। उदाहरण के लिए, एक बाइनरी ऑपरेटर के पास फॉर्म (T, T) => T का हस्ताक्षर होना चाहिए (T, T) => T
3. विधि कम से कम आंशिक रूप से अनुकूलित होनी चाहिए। उदाहरण के लिए, सर्वव्यापी मुक्केबाजी अस्वीकार्य है।

और पड़ोसियों के बारे में क्या?

आइए F# । मैं F# में मजबूत नहीं हूं, लेकिन ज्यादातर C# प्रतिबंध CLR सीमाओं से तय होते हैं, जिसका मतलब है कि F# समान समस्याओं से ग्रस्त है। आप एक स्पष्ट सामान्यीकृत जोड़ विधि और सामान्य जोड़ विधि घोषित करने का प्रयास कर सकते हैं और देख सकते हैं कि F# प्रकार की अनुमान प्रणाली क्या कहती है:

 let add_gen (x : 'a) (y : 'a) = x + y let add xy = x + y add_gen 5.0 6.0 |> ignore add 5.0 6.0 |> ignore 

इस स्थिति में, दोनों विधियाँ गैर-सामान्यीकृत हो जाएंगी, और उत्पन्न कोड समान होगा। F# प्रकार प्रणाली की कठोरता को देखते हुए, जहां फार्म के कोई निहित रूपांतरण नहीं हैं int -> double , इन विधियों के पहले कॉल के बाद double प्रकार के मापदंडों के साथ ( C# शर्तों में), अन्य तरीकों के मापदंडों के साथ कॉल विधियों (यहां तक ​​कि टाइप रूपांतरण के कारण सटीकता की संभावित हानि के साथ) अधिक असफल हो जाएगा।

यह ध्यान देने योग्य है कि यदि आप + ऑपरेटर को समानता ऑपरेटर = बदलते हैं, तो चित्र थोड़ा अलग हो जाता है : दोनों विधियाँ सामान्यीकृत ( C# के दृष्टिकोण से) में बदल जाती हैं, और F# में उपलब्ध एक विशेष सहायक विधि, को तुलना करने के लिए कहा जाता है।

 let eq_gen (x : 'a) (y : 'a) = x = y let eq xy = x = y eq_gen 5.0 6.0 |> ignore eq_gen 5 6 |> ignore eq 5.0 6.0 |> ignore eq 5 6 |> ignore 

Java बारे में क्या?

मेरे लिए Java बारे में बात करना कठिन है, लेकिन जहाँ तक मैं बता सकता हूँ, महत्वपूर्ण प्रकार हमारे लिए सामान्य रूप में नहीं हैं, लेकिन अभी भी आदिम प्रकार हैं। Java में प्रिमिटिव के साथ काम करने के लिए, रैपर हैं (उदाहरण के लिए, प्रिमिटिव बाय-वैल्यू Long लिए एक संदर्भ Long ), जिसमें एक सामान्य बेस क्लास Number । इस प्रकार, आप Number का उपयोग करके संचालन को सामान्य रूप से सामान्य कर सकते हैं, लेकिन यह एक संदर्भ प्रकार है, जिसके प्रदर्शन पर सकारात्मक प्रभाव होने की संभावना नहीं है।

अगर मैं गलत हूं तो मुझे सुधारो।

C++ ?

C++ चेटर्स के लिए एक भाषा है।
C++ उन सुविधाओं के लिए मार्ग प्रशस्त करता है जो कुछ मानते हैं ... अप्राकृतिक ।
सामान्य ज्ञान (जेनरिक) के विपरीत टेम्प्लेट (उर्फ टेम्प्लेट), शाब्दिक अर्थों में, टेम्प्लेट हैं । टेम्पलेट की घोषणा करते समय, आप स्पष्ट रूप से उन प्रकारों को प्रतिबंधित कर सकते हैं जिनके लिए यह टेम्पलेट उपलब्ध है। इस कारण से, C++ , उदाहरण के लिए, निम्न कोड मान्य है:

 #include <iostream> template<typename T, std::enable_if_t<std::is_arithmetic<T>::value>* = nullptr> T Add (T left, T right) { return left + right; } int main() { std::cout << Add(5, 6) << std::endl; std::cout << Add(5.0, 6.0) << std::endl; // std::cout << Add("a", "b") << std::endl; Does not compile } 

is_arithmetic , दुर्भाग्यवश, char और bool दोनों को पैरामीटर के रूप में अनुमति देता है। दूसरी ओर, C# शब्दावली में char बराबर हो सकता है, हालांकि पूर्णांक प्रकार के वास्तविक आकार प्लेटफॉर्म / कंपाइलर / मून चरण पर निर्भर करते हैं।

गतिशील टाइपिंग भाषाएँ

अंत में, गणना द्वारा धारित, गतिशील रूप से टाइप की गई (और व्याख्या की गई ) भाषाओं के एक जोड़े पर विचार करें। ऐसी भाषाओं में, आमतौर पर गणना के सामान्यीकरण से समस्याएं पैदा नहीं होती हैं: यदि मापदंडों का प्रकार निष्पादन के लिए उपयुक्त है, सशर्त रूप से, इसके अलावा, तो ऑपरेशन किया जाएगा, अन्यथा यह एक त्रुटि के साथ विफल हो जाएगा।

Python (3.7.3 x64):

 def add (x, y): return x + y type(add(5, 6)) # <class 'int'> type(add(5.0, 6.0)) # <class 'float'> type(add('a', 'b') # <class 'str'> 

R (3.6.1 x64)

 add <- function(x, y) x + y # Or typeof() vctrs::vec_ptype_show(add(5, 6)) # Prototype: double vctrs::vec_ptype_show(add(5L, 6L)) # Prototype: integer vctrs::vec_ptype_show(add("5", "6")) # Error in x + y : non-numeric argument to binary operator 

इसके विपरीत, C # दुनिया में: हम गणितीय प्रकार के सामान्यीकृत प्रकार को प्रतिबंधित करते हैं

दुर्भाग्य से, हम ऐसा नहीं कर सकते। C# आदिम प्रकार के मूल्य प्रकार हैं, अर्थात्। संरचनाएँ, जो कि System.Object (और System.ValueType ) से विरासत में मिली हैं, उनमें बहुत कुछ नहीं है। एक प्राकृतिक और तार्किक सीमा है where T : struct । C# 7.3 साथ शुरू होने पर C# 7.3 हमारे पास where T : unmanaged बाधा है, जिसका अर्थ है कि T एक , null । आदिम अंकगणितीय प्रकारों के अतिरिक्त जिनकी हमें आवश्यकता होती है, char , bool , decimal , कोई भी Enum और कोई भी संरचना जिनके सभी क्षेत्रों में एक ही unmanaged प्रकार होता है, इन आवश्यकताओं को पूरा करते हैं। यानी यह प्रकार परीक्षा पास करेगा:

 public struct Coords<T> where T : unmanaged { public TX; public TY; } 

इस प्रकार, हम एक सामान्यीकृत फ़ंक्शन नहीं लिख सकते हैं जो केवल वांछित अंकगणित प्रकारों को स्वीकार करता है। इसलिए लेख के शीर्षक में Unsafe - हमें अपने कोड का उपयोग करके प्रोग्रामर पर भरोसा करना होगा। एक काल्पनिक सामान्यीकृत विधि को कॉल करने का प्रयास T Add<T>(T left, T right) where T : unmanaged अप्रत्याशित परिणाम का नेतृत्व करेगा यदि प्रोग्रामर तर्क के रूप में असंगत प्रकार की वस्तुओं को पास करता है।

पहला प्रयोग, भोला: dynamic

dynamic पहला और स्पष्ट उपकरण है जो हमारी समस्या को हल करने में हमारी मदद कर सकता है। बेशक, गणना के लिए dynamic का उपयोग करना बिल्कुल बेकार है - dynamic object बराबर है, और dynamic चर वाले तरीकों को संकलक द्वारा एक राक्षसी प्रतिबिंब में बदल दिया जाता है। एक बोनस के रूप में - हमारे बाय-वैल्यू प्रकारों की पैकिंग / अनपैकिंग। यहाँ एक उदाहरण है :

 public class Class { public static void Method() { var x = Add(5, 6); var y = Add(5.0, 6.0); } private static dynamic Add(dynamic left, dynamic right) => left + right; } 

बस Method विधि के IL :

 .method public hidebysig static void Method () cil managed { // Method begins at RVA 0x2050 // Code size 53 (0x35) .maxstack 8 IL_0000: ldc.i4.5 IL_0001: box [System.Private.CoreLib]System.Int32 IL_0006: ldc.i4.6 IL_0007: box [System.Private.CoreLib]System.Int32 IL_000c: call object Class::Add(object, object) IL_0011: pop IL_0012: ldc.r8 5 IL_001b: box [System.Private.CoreLib]System.Double IL_0020: ldc.r8 6 IL_0029: box [System.Private.CoreLib]System.Double IL_002e: call object Class::Add(object, object) IL_0033: pop IL_0034: ret } // end of method Class::Method 

भरी हुई 5 , भरी हुई, भरी हुई 6 , भरी हुई, जिसे object Add(object, object) कहा जाता है।
विकल्प स्पष्ट रूप से हमें शोभा नहीं देता।

दूसरा प्रयोग, "माथे में"

वैसे, dynamic हमारे लिए नहीं है, लेकिन हमारे प्रकारों की संख्या परिमित है, और वे पहले से ही जाने जाते हैं। चलो अपने आप को एक शाखा मुकुट के साथ बांधा और इसे लिखें: यदि हमारा प्रकार है , तो कुछ की गणना करें, अन्यथा - यहां अपवाद है।

 public static T Add<T>(T left, T right) where T : unmanaged { if(left is int i32Left && right is int i32Right) { // ??? } // ... throw new NotSupportedException(); } 

III, यहाँ हम एक समस्या को देखते हैं। यदि आप समझते हैं कि हम किस प्रकार के साथ काम कर रहे हैं, तो आप अभी भी उन पर भी ऑपरेशन लागू कर सकते हैं, तो परिणामी सशर्त int को एक अज्ञात प्रकार T बदलने की आवश्यकता है और यह बहुत सरल नहीं है। return (T)(i32Left + i32Right) संकलन नहीं करता है - कोई गारंटी नहीं है कि T int (भले ही हम जानते हैं कि यह है)। आप डबल रूपांतरण return (T)(object)(i32Left + i32Right) । सबसे पहले, राशि पैक की जाती है, फिर इसे T में अनपैक किया जाता है T यह तभी काम करेगा जब प्रकार पैकेजिंग से पहले और पैकेजिंग के बाद मेल खाते हों । आप int पैक नहीं कर सकते हैं, लेकिन इसे double में अनपैक करें, भले ही एक अंतर्निहित रूपांतरण int -> double । इस कोड के साथ समस्या यह है कि विशाल शाखाएं और अनपैकिंग पैकेजों की बहुतायत, भले if स्थितियों में हो। यह विकल्प भी अच्छा नहीं है।

परावर्तन और मेटाडेटा

खैर, खेलते हैं और यही काफी है। हर कोई जानता है कि C# में ऑपरेटर हैं जिन्हें ओवरराइड किया जा सकता है। वहां, + , - , == != और इतने पर हैं। हमें बस इतना करना होगा कि ऑपरेटर के अनुरूप एक प्रकार की T स्टेटिक विधि निकालनी चाहिए, उदाहरण के लिए, परिवर्धन - बस इतना ही। ठीक है, हाँ, फिर से एक दो पैकेज, लेकिन कोई शाखा और कोई समस्या नहीं। पूरी चीज को टाइप T द्वारा कैश किया जा सकता है और आम तौर पर हर तरह से प्रक्रिया को गति प्रदान करता है, एक एकल प्रतिबिंब विधि को कॉल करने के लिए एक गणितीय ऑपरेशन को कम करता है। खैर, कुछ इस तरह से:

 public static T Add<T>(T left, T right) where T : unmanaged { // Simple example without cache. var method = typeof(T) .GetMethod(@"op_Addition", new [] {typeof(T), typeof(T)}) ?.CreateDelegate(typeof(Func<T, T, T>)) as Func<T, T, T>; return method?.Invoke(left, right) ?? throw new InvalidOperationException(); } 

दुर्भाग्य से यह काम नहीं करता है । तथ्य यह है कि अंकगणितीय प्रकार (लेकिन decimal नहीं) में ऐसी कोई स्थिर विधि नहीं है। सभी ऑपरेशन IL संचालन के माध्यम से कार्यान्वित किए जाते हैं, जैसे add । सामान्य प्रतिबिंब हमारी समस्या का समाधान नहीं करता है।

System.Linq.Expressions

Expressions आधारित समाधान जॉन स्कीट के ब्लॉग पर यहां (मार्क ग्रेवेल द्वारा) वर्णित है।
विचार बहुत सरल है। मान लीजिए कि हमारे पास एक टाइप T जो ऑपरेशन + का समर्थन करता है। आइए इस तरह से एक अभिव्यक्ति बनाएं:

 (x, y) => x + y; 

उसके बाद, कैश होने के बाद, हम इसका उपयोग करेंगे। ऐसी अभिव्यक्ति का निर्माण बहुत आसान है। हमें दो मापदंडों और एक ऑपरेशन की आवश्यकता है। तो चलिए लिखते हैं।

 private static readonly Dictionary<(Type Type, string Op), Delegate> Cache = new Dictionary<(Type Type, string Op), Delegate>(); public static T Add<T>(T left, T right) where T : unmanaged { var t = typeof(T); // If op is cached by type and function name, use cached version if (Cache.TryGetValue((t, nameof(Add)), out var del)) return del is Func<T, T, T> specificFunc ? specificFunc(left, right) : throw new InvalidOperationException(nameof(Add)); var leftPar = Expression.Parameter(t, nameof(left)); var rightPar = Expression.Parameter(t, nameof(right)); var body = Expression.Add(leftPar, rightPar); var func = Expression.Lambda<Func<T, T, T>>(body, leftPar, rightPar).Compile(); Cache[(t, nameof(Add))] = func; return func(left, right); } 

हब पर अभिव्यक्ति पेड़ों और प्रतिनिधियों के बारे में उपयोगी जानकारी प्रकाशित की गई थी

तकनीकी रूप से, भाव हमें अपनी सभी समस्याओं को हल करने की अनुमति देते हैं - किसी भी सामान्य ऑपरेशन को सामान्यीकृत विधि कहकर कम किया जा सकता है। अधिक जटिल अभिव्यक्तियों का उपयोग करके किसी भी अधिक जटिल ऑपरेशन को उसी तरह लिखा जा सकता है। यह लगभग पर्याप्त है।

हम सारे नियम तोड़ देते हैं

क्या CLR/C# की शक्ति का उपयोग करके कुछ और हासिल करना संभव है? आइए देखें कि विभिन्न प्रकारों के लिए कोड किस विधि से उत्पन्न होता है:

 public class Class { public static double Add(double x, double y) => x + y; public static int Add(int x, int y) => x + y; // Decimal only to show difference public static decimal Add(decimal x, decimal y) => x + y; } 

संबंधित IL कोड में निर्देशों का एक ही सेट होता है:

 ldarg.0 ldarg.1 add ret 

यह बहुत ही add ऑप कोड है जिसमें अंकगणित आदिम प्रकारों को जोड़ा जाता है। इस स्थान पर decimal को static decimal decimal.op_Addition(decimal, decimal) कहता है। लेकिन क्या होगा अगर हम एक ऐसी विधि लिखते हैं जो सामान्यीकृत होगी, लेकिन इसमें वास्तव में यह IL कोड होगा? खैर, जॉन स्कीट ने चेतावनी दी है कि यह इसके लायक नहीं है । अपने मामले में, वह सभी प्रकारों ( decimal सहित), साथ ही साथ उनके nullable एनालॉग्स पर विचार करता है। यह काफी nontrivial IL संचालन की आवश्यकता होगी और जरूरी एक त्रुटि के लिए नेतृत्व करेंगे। लेकिन हम अभी भी बुनियादी कार्यों को लागू करने की कोशिश कर सकते हैं।

मेरे आश्चर्य के लिए, Visual Studio IL प्रोजेक्ट्स और IL फ़ाइलों के लिए टेम्प्लेट नहीं हैं। आप केवल IL में कोड का हिस्सा नहीं ले सकते हैं और उसका वर्णन नहीं कर सकते हैं और इसे अपनी विधानसभा में शामिल कर सकते हैं। स्वाभाविक रूप से, खुला स्रोत हमारी सहायता के लिए आता है। ILSupport प्रोजेक्ट में IL प्रोजेक्ट्स के लिए टेम्प्लेट हैं, साथ ही निर्देशों का एक सेट है जो प्रोजेक्ट में IL कोड को शामिल करने के लिए *.csproj जोड़ा जा सकता है। बेशक, IL में सब कुछ का वर्णन करना काफी मुश्किल है, इसलिए परियोजना के लेखक ForwardRef फ्लैग के साथ बिल्ट-इन MethodImpl विशेषता का उपयोग करते हैं। यह विशेषता आपको विधि को extern घोषित करने की अनुमति देती है और विधि के शरीर का वर्णन नहीं करती है। यह कुछ इस तरह दिखता है:

 [MethodImpl(MethodImplOptions.ForwardRef)] public static extern T Add<T>(T left, T right) where T : unmanaged; 

अगला चरण *.il फ़ाइल में विधि के कार्यान्वयन को IL कोड के साथ लिखना है:

 .method public static hidebysig !!T Add<valuetype .ctor (class [mscorlib]System.ValueType modreq ([mscorlib]System.Runtime.InteropServices.UnmanagedType)) T>(!!T left, !!T right) cil managed { .param type [1] .custom instance void System.Runtime.CompilerServices.IsUnmanagedAttribute::.ctor() = (01 00 00 00 ) ldarg.0 ldarg.1 add ret } 

स्पष्ट रूप से टाइप करने के लिए कहीं भी !!T , हम CLR को दो तर्क जोड़ने और परिणाम वापस करने का सुझाव देते हैं। किसी भी प्रकार की जांच नहीं होती है, और सब कुछ डेवलपर के विवेक पर है। हैरानी की बात है, यह काम करता है, और अपेक्षाकृत जल्दी।

थोड़ा सा बेंचमार्क

संभवतः, एक ईमानदार बेंचमार्क कुछ जटिल अभिव्यक्ति पर बनाया जाएगा, जिसकी गणना "हेड-ऑन" इन खतरनाक IL विधियों के साथ की जाएगी। मैंने एक सरल एल्गोरिथ्म लिखा है जो पहले से गणना की गई संख्याओं के वर्गों को दोहराता है और एक double सरणी में संग्रहीत किया जाता है और संख्याओं की संख्या से अंतिम राशि को विभाजित करता है। ऑपरेशन करने के लिए, मैंने C# ऑपरेटरों + , * और / , जैसा कि स्वस्थ लोग करते हैं, Expressions और IL फ़ंक्शन के साथ निर्मित कार्य करते हैं।

 BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362 Intel Core i7-2700K CPU 3.50GHz (Sandy Bridge), 1 CPU, 8 logical and 4 physical cores .NET Core SDK=3.1.100 [Host] : .NET Core 3.1.0 (CoreCLR 4.700.19.56402, CoreFX 4.700.19.56404), X64 RyuJIT Job-POXTAH : .NET Core 3.1.0 (CoreCLR 4.700.19.56402, CoreFX 4.700.19.56404), X64 RyuJIT Runtime=.NET Core 3.1 

हमारा असुरक्षित कोड लगभग 2.5 गुना धीमा है (एक ऑपरेशन के संदर्भ में)। इसे इस तथ्य के लिए जिम्मेदार ठहराया जा सकता है कि "माथे" की गणना के मामले में, कंपाइलर add ऑप कोड में a + b संकलित करता a + b , और एक असुरक्षित विधि के मामले में, एक स्थिर फ़ंक्शन कहा जाता है, जो स्वाभाविक रूप से धीमा है।

समापन के बजाय: जब true != true

कुछ दिनों पहले, मैं जेरेड पार्सन्स के इस तरह के एक ट्वीट पर आया था:

ऐसे मामले हैं जहां निम्नलिखित "गलत" छापेंगे
बूल ब = ...
if (b) कंसोल.ट्राइटलाइन (b.IsTrue ());

यह इस प्रविष्टि का उत्तर था, जो true के लिए bool सत्यापन कोड दिखाता true , जो कुछ इस तरह दिखता है:

 public static bool IsTrue(this bool b) { if (b == true) return true; else if (b == false) return false; else return !true && !false; } 

चेक बेमानी लगते हैं, है ना? जारेड एक प्रतिरूप देता है जो bool व्यवहार की कुछ विशेषताओं को प्रदर्शित करता है । विचार यह है कि bool byte ( sizeof(bool) == 1 ) है, जबकि false 0 और true 1 मैच। जब तक आप पॉइंटर्स को स्विंग नहीं करते हैं, bool स्पष्ट रूप से और अनुमानित रूप से व्यवहार करता है। हालांकि, जैसा कि जेरेड ने दिखाया है, आप प्रारंभिक मूल्य के रूप में 2 का उपयोग करके एक bool बना सकते हैं, और चेकों का हिस्सा सही ढंग से विफल हो जाएगा:

 bool b = false; byte* ptr = (byte*)&b; *ptr = 2; 

हम अपने असुरक्षित गणितीय कार्यों का उपयोग करके एक समान प्रभाव प्राप्त कर सकते हैं (यह Expressions साथ काम नहीं करता है):

 var fakeTrue = Subtract<bool>(false, true); var val = *(byte*)&fakeTrue; if(fakeTrue) Assert.AreNotEqual(fakeTrue, true); else Assert.Fail("Clause not entered."); 

हां, हां, हम true शाखा के अंदर जांचते हैं कि क्या स्थिति true , और हम उम्मीद करते हैं कि वास्तव में यह true नहीं true । ऐसा क्यों है? यदि आप चेक के बिना 0 ( =false ) 1 ( =true ) से घटाते हैं, तो byte यह 255 बराबर होगा। स्वाभाविक रूप से, 255 (हमारे fakeTrue ) 1 (वास्तविक true ) नहीं है, इसलिए fakeTrue निष्पादित किया जाता है। ब्रांचिंग अलग तरीके से काम करती है।

if उलटा होता है: एक सशर्त शाखा डाली जाती है; यदि स्थिति झूठी है , तो बिंदु के लिए एक संक्रमण if ब्लॉक के अंत के बाद होता है। सत्यापन brfalse / brfalse_S द्वारा किया जाता है। यह स्टैक पर अंतिम मान की तुलना शून्य के साथ करता है । यदि मान शून्य है, तो यह false , हम if ब्लॉक पर कदम रखते हैं। हमारे मामले में, fakeTrue सिर्फ शून्य के बराबर नहीं है, इसलिए चेक पास और निष्पादन fakeBool ब्लॉक के अंदर जारी रहता है, जहाँ हम fakeBool मूल्य की तुलना सच्चे मूल्य से करते हैं और नकारात्मक परिणाम प्राप्त करते हैं।

UPD01:
Shai_hulud और blowin के साथ टिप्पणियों में चर्चा करने के बाद, मैंने बेंचमार्क में एक और तरीका जोड़ा है जो एक शाखा को लागू करता है जैसे if(typeof(T) == typeof(int)) return (T)(object)((int)(object)left + (int)(object)right); । इस तथ्य के बावजूद कि JIT को चेक का अनुकूलन करना चाहिए, कम से कम जब T एक struct , तो इस तरह के तरीके अभी भी परिमाण धीमी के एक आदेश का काम करते हैं। यह स्पष्ट नहीं है कि क्या रूपांतरण T -> int -> T अनुकूलित हैं, या बॉक्सिंग / अनबॉक्सिंग का उपयोग किया जाता है या नहीं। बेंचमार्क के परिणाम MethodImpl झंडे से काफी प्रभावित MethodImpl होते हैं।

UPD02:
टिप्पणियों में xXxVano ने टाइप करके डाली जाने वाली T का उपयोग करने का एक उदाहरण दिखाया <<> Unsafe.As<TFrom, TTo>() का उपयोग करते हुए एक विशिष्ट प्रकार। object माध्यम से सामान्य ब्रांचिंग और कस्टम के अनुरूप, मैंने सभी अंकगणितीय प्रकारों के लिए ब्रांचिंग के साथ तीन ऑपरेशन (इसके अलावा, गुणा और भाग) लिखा, जिसके बाद मैंने एक और बेंचमार्क ( UnsafeBranchSum ) जोड़ा। इस तथ्य के बावजूद कि सभी विधियाँ (भावों को छोड़कर) लगभग समान एस एम कोड उत्पन्न करती हैं (जहाँ तक असेंबली के मेरे सीमित ज्ञान से मुझे न्याय करने की अनुमति मिलती है), किसी अज्ञात कारण से, ब्रांचिंग के साथ दोनों विधियाँ दोनों सीधे DirectSum ( DirectSum ) की तुलना में बहुत धीमी हैं जेनरिक और IL कोड का उपयोग करना। इस प्रभाव के लिए मेरे पास कोई स्पष्टीकरण नहीं है, तथ्य यह है कि समय व्यतीत करने के लिए समानुपातिक रूप से N इंगित करता है कि JIT सभी जादू के बावजूद, प्रत्येक ऑपरेशन के लिए किसी प्रकार का निरंतर ओवरहेड है। यह ओवरहेड विधियों के IL संस्करण से गायब है। , IL - , / / , 100% ( , ).
, , - .