- Why i choose Delphi - 1 Update
- I have worked with... - 1 Update
- Here is a beautiful song - 1 Update
- Read the following paper - 1 Update
| Intelli2 <intelli2@mama.com>: Dec 20 06:23PM -0500 Hello, Here is a smarter webpage that explains: Why i choose Delphi https://csvelocity.wordpress.com/2017/07/27/why-i-choose-delphi/ Thank you, Amine Moulay Ramdane. |
| Intelli2 <intelli2@mama.com>: Dec 20 05:35PM -0500 Hello... I have worked with Delphi compiler and with FreePascal compiler, because they are modern Object Pascal that is beautiful , because they are excellent on readability and they are good on productivity, believe me i have more experience now, but i have worked also with C++ and it is excellent, it is why i am working with both , with modern Object Pascal and with C++, why i am not working with Java and C# ? because forcing garbage collection is also not good because it is also not optimally efficient, i have posted on that before, please read again here: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf And i am now extending Delphi and FreePascal to support scalable datastructures and more scalable compression libraries etc. but what is good is that you can use my Delphi libraries from C++Builder because C++Builder is compatible with Delphi. Thank you, Amine Moulay Ramdane. |
| Intelli2 <intelli2@mama.com>: Dec 20 05:09PM -0500 Hello.. Here is a beautiful song, it is as beautiful as the Delphi compiler, so, long life to Delphi and to FreePascal and to Lazarus and to also C++ ! https://www.youtube.com/watch?v=FCf23ZTFaDM Thank you, Amine Moulay Ramdane. |
| Intelli2 <intelli2@mama.com>: Dec 20 04:43PM -0500 Hello.. Read the following paper, because i have read it and it is interesting, this is why i have posted here: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management " Conclusion This paper presents a tracing and simulation-based experimental methodology that executes unaltered Java programs as if they used explicit memory management. We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection's performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management. We believe these results will be useful both for practitioners and researchers. Practitioners can use these results to guide their choice of explicitly-managed languages like C or C++, or garbage-collected languages like Java or C#. If their applications will be deployed on systems with at least three times as much RAM as needed, then garbage collection should provide reasonable performance. However, if the deployed systems will have less RAM, or if their applications will have to compete with other processes for memory, then practitioners should expect garbage collection to exact a substantial performance cost. This cost will be especially pronounced for applications whose performance is tied to their efficient use of memory, such as in-memory databases and search engines. " Read more here: https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Thank you, Amine Moulay Ramdane. |
| 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