- About C++.. - 1 Update
- More about FreePascal and Delphi and C# and Java - 1 Update
- About C# and Java - 1 Update
- CPU Hierarchy 2018: Intel and AMD Processors Ranked - 1 Update
| Sky89 <Sky89@sky68.com>: Jun 26 03:55PM -0400 Hello, About C++.. I said before that type-safety of C++ is not good by default: Here is my proof: look at this library that is "trying"(But it is not yet sufficient) to improve the type-safety of C++: Improve Type Safety in Your C++ Program With the type_safe Library "Features provided by the type_safe library include improved built-in types (ts::integer, ts::floating_point, and ts::boolean) which prevent dangerous implicit operations like signed-to-unsigned promotion." Read more here: https://embeddedartistry.com/blog/2018/5/24/improve-type-safety-in-your-c-program-with-the-typesafe-library This is why i said before the following: Also I will not waste my time with C++, because from the start C++ was handicaped, because it has inherited the deficiencies of C, i think C is "not" a good programming language because it is "too" weakly typed and it allows implicit type conversions that are bad for reliability etc. and this looks like the mess of assembler, because C was "too" low level for reliability, and since C++ has inherited from C, C++ has inherited this too low level parts that are not good for reliability, so i will not waste my time with C++ or with C, and i will continu to code in "modern" Object Pascal of Delphi and FreePascal that is more conservative because it has a "decent" reliability and a "decent" performance, and those Delphi and FreePascal compilers are "powerful" today. And i will also work with "Java", because Mono is not following fast the developement of C# and it is not as portable as Java. And here is what i wrote about C++ and Delphi and FreePascal and ADA: Energy efficiency isn't just a hardware problem. Your programming language choices can have serious effects on the efficiency of your energy consumption. We dive deep into what makes a programming language energy efficient. As the researchers discovered, the CPU-based energy consumption always represents the majority of the energy consumed. What Pereira et. al. found wasn't entirely surprising: speed does not always equate energy efficiency. Compiled languages like C, C++, Rust, and Ada ranked as some of the most energy efficient languages out there. Read more here: https://jaxenter.com/energy-efficient-programming-languages-137264.html RAM is still expensive and slow, relative to CPUs And "memory" usage efficiency is important for mobile devices. So Delphi and FreePascal compilers are also still "useful" for mobile devices, because Delphi and FreePascal are good if you are considering time and memory or energy and memory, and the following pascal benchmark was done with FreePascal, and the benchmark shows that C, Go and Pascal do rather better if you're considering languages based on time and memory or energy and memory. Read again here to notice it: https://jaxenter.com/energy-efficient-programming-languages-137264.html Also Delphi is still better for many things, and you have to get more "technical" to understand it, this is why you have to look at this following video about Delphi that is more technical: Why are C# Developers choosing Delphi to create Mobile applications https://www.youtube.com/watch?v=m8ToSr4zOVQ And I think there is still a "big" problem with C++ and C.. Look at C++ explicit conversion functions, they were introduced in C++11, but this doesn't come by "default" in C++, like in modern Object Pascal of Delphi and FreePascal and like in ADA , because in C++ you have to write explicit conversion functions etc., so this is not good for reliability in C++, and C++ doesn't by "default" come with range checking and Run-time checks that catch conversion from negative signed to unsigned and arithmetic overflow , you have for example to add and use SafeInt library for that, and C++ doesn't by "default" catch out-of-bounds indices of dynamic and static arrays this is why C++ is not good for reliability. But Delphi and FreePascal like ADA come with range checking and Run-time checks that catch conversion from negative signed to unsigned , and catch out-of-bounds indices of dynamic and static arrays and catch arithmetic overflow etc. and you can also dynamically catch this exception of ERangeError etc. and they do not allow those bad implicit type conversions of C++ that are not good for reliability. And you can carefully read the following, it is very important: https://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/ And about Escher C++ Verifier, read carefully: "Escher C Verifier enables the development of formally-verifiable software in a subset of C (based on MISRA-C 2012)." Read here: http://www.eschertech.com/products/index.php So it verifies just a "subset" of C, so that's not good for C++ because for other applications that are not a subset of C , it can not do for example Run-time checks, so we are again into this problem again that C++ and C don't have range checking and many Run-time checks, so that's not good in C++ and C because it is not good for reliability and it is not good for safety-critical systems. So for all the reasons above , i think i will stop coding in C++ and i will quit C++. Thank you, Amine Moulay Ramdane. |
| Sky89 <Sky89@sky68.com>: Jun 26 03:15PM -0400 Hello.. More about FreePascal and Delphi and C# and Java, read all the following: C#, is a slightly higher level language than C++ or Delphi or FreePascal. Its requirement of managed runtime environment means that you wont be able to write an operating system, or even a device driver, in it. This sort of area is typically known as systems programming(with C++ or Delphi or FreePascal etc.). And what about garbage collection? Read what said Chris Lattner: "One thing that I don't think is debatable is that the heap compaction behavior of a GC (which is what provides the heap fragmentation win) is incredibly hostile for cache (because it cycles the entire memory space of the process) and performance predictability." "Not relying on GC enables Swift to be used in domains that don't want it - think boot loaders, kernels, real time systems like audio processing, etc." "GC also has several *huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted *much* more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you'll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life)." Read more here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html Here is Chris Lattner's Homepage: http://nondot.org/sabre/ And here is Chris Lattner's resume: http://nondot.org/sabre/Resume.html#Tesla Also I will not waste my time with C++, because from the start C++ was handicaped, because it has inherited the deficiencies of C, i think C is "not" a good programming language because it is "too" weakly typed and it allows implicit type conversions that are bad for reliability etc. and this looks like the mess of assembler, because C was "too" low level for reliability, and since C++ has inherited from C, C++ has inherited this too low level parts that are not good for reliability, so i will not waste my time with C++ or with C, and i will continu to code in "modern" Object Pascal of Delphi and FreePascal that is more conservative because it has a "decent" reliability and a "decent" performance, and those Delphi and FreePascal compilers are "powerful" today. And i will also work with "Java", because Mono is not following fast the developement of C# and it is not as portable as Java. And here is what i wrote about C++ and Delphi and FreePascal and ADA: Energy efficiency isn't just a hardware problem. Your programming language choices can have serious effects on the efficiency of your energy consumption. We dive deep into what makes a programming language energy efficient. As the researchers discovered, the CPU-based energy consumption always represents the majority of the energy consumed. What Pereira et. al. found wasn't entirely surprising: speed does not always equate energy efficiency. Compiled languages like C, C++, Rust, and Ada ranked as some of the most energy efficient languages out there. Read more here: https://jaxenter.com/energy-efficient-programming-languages-137264.html RAM is still expensive and slow, relative to CPUs And "memory" usage efficiency is important for mobile devices. So Delphi and FreePascal compilers are also still "useful" for mobile devices, because Delphi and FreePascal are good if you are considering time and memory or energy and memory, and the following pascal benchmark was done with FreePascal, and the benchmark shows that C, Go and Pascal do rather better if you're considering languages based on time and memory or energy and memory. Read again here to notice it: https://jaxenter.com/energy-efficient-programming-languages-137264.html Also Delphi is still better for many things, and you have to get more "technical" to understand it, this is why you have to look at this following video about Delphi that is more technical: Why are C# Developers choosing Delphi to create Mobile applications https://www.youtube.com/watch?v=m8ToSr4zOVQ And I think there is still a "big" problem with C++ and C.. Look at C++ explicit conversion functions, they were introduced in C++11, but this doesn't come by "default" in C++, like in modern Object Pascal of Delphi and FreePascal and like in ADA , because in C++ you have to write explicit conversion functions etc., so this is not good for reliability in C++, and C++ doesn't by "default" come with range checking and Run-time checks that catch conversion from negative signed to unsigned and arithmetic overflow , you have for example to add and use SafeInt library for that, and C++ doesn't by "default" catch out-of-bounds indices of dynamic and static arrays this is why C++ is not good for reliability. But Delphi and FreePascal like ADA come with range checking and Run-time checks that catch conversion from negative signed to unsigned , and catch out-of-bounds indices of dynamic and static arrays and catch arithmetic overflow etc. and you can also dynamically catch this exception of ERangeError etc. and they do not allow those bad implicit type conversions of C++ that are not good for reliability. And you can carefully read the following, it is very important: https://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/ And about Escher C++ Verifier, read carefully: "Escher C Verifier enables the development of formally-verifiable software in a subset of C (based on MISRA-C 2012)." Read here: http://www.eschertech.com/products/index.php So it verifies just a "subset" of C, so that's not good for C++ because for other applications that are not a subset of C , it can not do for example Run-time checks, so we are again into this problem again that C++ and C don't have range checking and many Run-time checks, so that's not good in C++ and C because it is not good for reliability and it is not good for safety-critical systems. So for all the reasons above , i think i will stop coding in C++ and i will quit C++. Thank you, Amine Moulay Ramdane. |
| Sky89 <Sky89@sky68.com>: Jun 26 03:06PM -0400 Hello.. About C# and Java C#, is a slightly higher level language than C++ or Delphi. Its requirement of managed runtime environment means that you wont be able to write an operating system, or even a device driver, in it. This sort of area is typically known as systems programming(with C++ or Delphi etc.). And what about garbage collection? Read what said Chris Lattner: "One thing that I don't think is debatable is that the heap compaction behavior of a GC (which is what provides the heap fragmentation win) is incredibly hostile for cache (because it cycles the entire memory space of the process) and performance predictability." "Not relying on GC enables Swift to be used in domains that don't want it - think boot loaders, kernels, real time systems like audio processing, etc." "GC also has several *huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted *much* more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you'll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life)." Read more here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html Here is Chris Lattner's Homepage: http://nondot.org/sabre/ And here is Chris Lattner's resume: http://nondot.org/sabre/Resume.html#Tesla Thank you, Amine Moulay Ramdane. |
| gameroegaming@gmail.com: Jun 26 08:36AM -0700 On Monday, June 4, 2018 at 1:01:53 AM UTC+8, Sky89 wrote: > Hello.. >CPU Hierarchy: 5 Tiers Of Great War >Part 1- CPU hierarchy 2018: 5 tier: Tier 1: The Absolute Best > Tier 2: The CPU that has a superb performance Tier 3 – Good Performance at Reasonable Prices Tier 4 – It is a great value for those on a budget Tier 5 – Affordable Solutions for the Less Demanding Gamer Part #2 Desktop & Laptop CPU Hierarchy Lists (Updated) Desktop CPU hierarchy: Laptop CPU hierarchy > Read more here: > https://www.gameroe.com/cpu-hierarchy > If you want to see the GPU hierarchy,Please see https://www.gameroe.com/gpu-hierarchy |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com. |
No comments:
Post a Comment