Energy consumption for different programming languages - Page 1
Forum section: electronics / general

author: Tation
author_rank: Regular Contributor
timestamp: March 27, 2025, 10:53:11 pm
content: Recently arrived at thispaper. I found it interesting, it's is a comparison of different programming languages according to their energy consumption, time to completion and memory usage.Although, maybe, there may be some issues with the methodology: uses programs from the Computer Language Benchmarks Game, I think that direct translation from language X to language Y may produce clearly sub-optimal Y-code if both languages are not quite similar, but CLBG has many examples of programs written this way. In any case, interesting.In spite of the country flag below my username, I do not have any affiliation with the institutions of the authors nor know them.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 27, 2025, 10:57:20 pm
content: I had already seen those results. Sure the relevance can always be questioned regarding real-life use cases, but I think they did a relatively balanced benchmarking here, and I'm not surprised in the least by the results.Curious: is anyone surprised here?

author: tggzzz
author_rank: Super Contributor
timestamp: March 27, 2025, 11:05:29 pm
content: For many (most?) purposes, dominant considerations are the architecture, algorithms, and for embedded systems knowing how to use the specific processor's hardware efficiently.

author: brucehoult
author_rank: Super Contributor
timestamp: March 28, 2025, 12:23:14 am
content: Quote from: SiliconWizard on March 27, 2025, 10:57:20 pmNot surprised in the least.I don't think it's very helpful to analyse by language as much as by individual program, regardless of the language. Within one language you can write many of these programs in many different ways, with different levels of inherent parallelism and different memory access patterns.Also, sometimes a particular task in a "slow" language will be a perfect fit to a library function written in C, or even hand-coded SIMD.They appear to be using wall clock time here, while I'd think that user+system time would correlate better to energy usage -- ESPECIALLY if multiple processes are used, which could be explicit in C or implicit in a "scripting" language, especially if shell scripts were included (they aren't here).It would also have been good for them to measure IPC or a proxy such as number of instructions retired, and correlate with that too.The Lisp, Racket, C#, F#, and Pascal results in Binary Trees need investigation. They use 2.5x to 3x more time than programs with similar energy use.Pascal!!I can only imagine that they hit some particularly bad cache or TLB thrashing and a different algorithm would have done better. They didn't use excessive amounts of RAM and in fact all used less than Java (faster than them) and Hack (in the middle).

author: Bud
author_rank: Super Contributor
timestamp: March 28, 2025, 01:36:59 am
content: Responsible woke companies should tie their programmers' bonuses to their carbon footprint, based on the programming languages used.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 28, 2025, 01:46:27 am
content: Quote from: Bud on March 28, 2025, 01:36:59 amWhile I don't like the "carbon footprint" frenzy, *this* would certainly be interesting. This would completely turn around the software industry.

author: brucehoult
author_rank: Super Contributor
timestamp: March 28, 2025, 02:06:18 am
content: Quote from: SiliconWizard on March 28, 2025, 01:46:27 amI disagree.To a pretty good approximation -- about as good as the speed/energy correlations in this paper -- the "carbon footprint" of anything is proportional to its cost (even without carbon taxes).It makes perfect sense for people working on Android or GCC or the Linux kernel to spend infinite amounts of time shaving off clock cycles and picojoules.But for something that is going to be used by only one person or a small company you should be more worried about the programmer's salary / housing / food / transport than about the number of CPU cycles used. Especially when a computer using 5W of electricity got you 0.25 8 bit MIPS in the 1970s (for $500 1970s dollars) and 20,000 64 bit MIPS now (for $50).It makes much more sense to simply add up the costs of salary and equipment and consumables and minimise that for a given amount of useful stuff done.

author: eugene
author_rank: Frequent Contributor
timestamp: March 28, 2025, 04:35:53 pm
content: Quote from: Bud on March 28, 2025, 01:36:59 amI can improve this:Responsible  companies should tie their programmers' bonuses to their , based on the  used.Simply fill in the s to create any cheap, throw-away political joke desired.

author: radiolistener
author_rank: Super Contributor
timestamp: March 28, 2025, 06:09:34 pm
content: something wrong with these results, it shows C# time execution 10797 in comarison with C time execution 1125. Which is 960% differenceThis obviously shows that there is mistake in C# test code or with C test code. There can't be such a huge difference between C and C#.According to my tests with FIR filter implementation, good C# optimized code is just about 15-20% slower than highly optimized SIMD implementation in C when running on ARM aarch64 platform.In my opinion, the very idea of comparing programming languages based on energy consumption is fundamentally flawed. Energy usage is influenced far more by the choice of algorithm and its implementation than by the programming language itself.Moreover, lower energy consumption does not necessarily indicate efficiency. It may result from a suboptimal implementation that runs more slowly, thereby utilizing the processor's computational units less intensively. As a result, such lower energy consumption would lead to significantly lower efficiency, resulting in higher electricity costs for performing the same amount of work due to longer computation times.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 28, 2025, 07:00:38 pm
content: Quote from: tggzzz on March 27, 2025, 11:05:29 pmQuote from: radiolistener on March 28, 2025, 06:09:34 pmThis is a ridiculous argument. Those algorithms have to be implemented in some language. The issues are mostly orthogonal: choice of poor algorithm, or poor language, can both lead to inefficiency, it's not like choosing better algorithm somehow negates the need of fast/energy efficient languages. Choice of poor algorithm AND poor language leads to devastatingly bad performance, which can be seen in projects written in Python, utilizing inefficient brute-forcing loops with no decent use of libraries (written in C).And on the other hand, I have solved a few very interesting problems where my data analyst / mathematician skills were not sufficient to design a smart algorithm finding complex and hard-to-predict interactions, by writing a brute force solver implemented in low-level efficient C implementation. Efficient languages make this kind of stuff possible.NN / AI is the ultimate example of running extremely inefficient algorithms on extremely micro-optimized languages/architectures.So of course comparing performance of languages makes sense. Not always, but reducing the discussion to some kind of "just make a better algorithm" is stupid. The world is full of examples where the algorithm already is designed for maximum performance possible.Try to re-implement a modern video codec say h.264 in Python and see what happens.brucehoult, on the other hand, as always, is right: sometimes performance simply does not matter.

author: madires
author_rank: Super Contributor
timestamp: March 28, 2025, 07:28:17 pm
content: Quote from: SiliconWizard on March 27, 2025, 10:57:20 pmNope, is to be expected. BTW, current Python versions should perform better to some extend.

author: radiolistener
author_rank: Super Contributor
timestamp: March 28, 2025, 09:28:59 pm
content: Quote from: Siwastaja on March 28, 2025, 07:00:38 pmI disagree with the idea that its stupid to improve an algorithm instead the choice of programming language to get better efficiency. While I can't speak in detail about Python, as I rarely use it, based on my experience with languages like C, C++, C#, JS, MATLAB, R, Lua, and other, I seriously doubt that switching programming languages will yield the same performance boost as improving the algorithm. Modern JIT technologies have made programming languages relatively similar in performance. Of course, each language has its pros and cons that affect performance and resource consumption, but overall, the difference today is not as significant as the one caused by choosing a more efficient versus a less efficient algorithm, where the performance gap can be orders of magnitude.I want to emphasize that this difference is far smaller than the difference caused by a poor algorithm choice. Therefore, it makes much more sense to focus more on selecting more efficient algorithms than on the language itself. This is fairly obvious, as simply changing the algorithm can easily improve performance and reduce energy consumption by several orders of magnitude. The principle of optimization suggests that one should first optimize the areas that offer the greatest potential for efficiency gains, rather than focusing on marginal improvements that have minimal impact, like optimizing the language choice. Prioritizing algorithmic efficiency leads to more significant and tangible improvements in both performance and energy usage.That said, the choice of language does significantly affect other important factors, such as maintainability, portability, debugging ease, and code readability. Thus, language selection should also be given proper consideration, but energy efficiency, in my opinion, definitely should not be the primary concern when choosing a language.After all, in my opinion, attempting to choose a language for optimizing energy consumption is akin to the old joke about saving on matches - it's a misguided focus on trivial savings instead of addressing more impactful areas.Quote from: Siwastaja on March 28, 2025, 07:00:38 pmI don’t see the need to re-implement h.264 in Python, as Python doesn't prevent you from calling highly optimized implementations written in other languages. The same can be said for any other language. I'm sure, with the right approach, the Python code can process h.264 stream almost the same fast as highly optimized code in C.On another hand, it’s possible to write inefficient, slow, and energy-consuming code in C as well. This doesn't mean that C is a bad language - it's about how the code is written and optimized.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 01:18:29 am
content: Quote from: radiolistener on March 28, 2025, 06:09:34 pmYou are confusing W (power consumption) and J (or Ws kWh etc) (energy consumption).You are talking as if they measured W. They actually measured J which makes your argument nonsensical.It is possible on many modern machines to reduce J by artificially limiting W and accepting a longer run time, but that is a minor factor, and independent of language and algorithm.For example on my 24 core i9-13900HX laptop, I can build a defconfig Linux kernel in 1m3s at full power, with about 210W used for the first 50 seconds, then 160W after that. Or, I can limit it to 2.2 GHz (there is even a BIOS keystroke Fn-Q to switch these modes on the fly) and then it takes 2m3s but never uses more than 60W.The former uses around 6Wh for the build (0.2c), the latter 3Wh (0.1c), while my time is worth more than 0.1c/min ($0.06 per hour) -- in fact let's say 1000x more than that -- so I don't bother with the power saving setting unless I'm running on battery and don't expect to find a socket soon.

author: radiolistener
author_rank: Super Contributor
timestamp: March 29, 2025, 01:56:13 am
content: Quote from: brucehoult on March 29, 2025, 01:18:29 amNo, I’m not talking about W (Watts) or Wh (Watt-Hours).You are confusing energy consumption with energy efficiency.I’m talking about energy efficiency measured in Wh per FLOPS.Consider the following example with two CPUs:- CPU 1: Runs for 1 hour with a power consumption of 1 W and achieves 1 GFLOPS.- CPU 2: Runs for 1 hour with a power consumption of 2 W and achieves 10 GFLOPS.As you can see, the second CPU consumes twice as much energy over the same period, but it performs ten times more work.This demonstrates that despite the first CPU consuming less total energy, it is actually less energy-efficient than the second one.Efficiency is not about minimizing absolute energy consumption - it’s about maximizing the amount of work done per unit of energy.Quote from: brucehoult on March 29, 2025, 01:18:29 amWould it be fair to compare compilation efficiency by running a single-threaded build (make -j1) on both a single-core processor and a 24-core processor, where the 24-core processor performs only slightly worse in terms of time and energy consumption?

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 02:05:06 am
content: Quote from: radiolistener on March 29, 2025, 01:56:13 amI am not confusing anything.QuoteGood.Assuming we are even talking about floating point, which is not the case in most of these tasks.QuoteYou are missing the fundamental assumption here that each benchmark is performing the same amount of useful work i.e. solving the same problem.Assuming CPU 1 is solving a given problem, CPU 2 will run for 6 minutes, not 1 hour.QuoteThe 2nd CPU uses 0.2 Wh to solve the same problem as the 1st CPU solves in 1 hour.QuoteThose are the same thing when all machines and programs are performing the same task, as is the fundamental assumption here.

author: radiolistener
author_rank: Super Contributor
timestamp: March 29, 2025, 02:21:45 am
content: Quote from: brucehoult on March 29, 2025, 02:05:06 amI used FLOPS simply as an example of meaningful computational work. If you prefer, you can replace it with MIPS or any other relevant metric - the point remains the same.Quote from: brucehoult on March 29, 2025, 02:05:06 amNo, it seems that you are the one missing the fundamental assumption. The same task (for example, single-threaded compilation) can be used to measure computational efficiency across different execution environments. It’s important to consider that your 24-core processor is capable of running 24 tasks simultaneously, unlike a single-core processor that can handle only one.When comparing the results of single-threaded compilation on a single-core and a 24-core processor, this difference must be taken into account. If your 24-core processor delivers worse results in a single-threaded scenario, it doesn’t necessarily means that it is less computationally efficient. Maybe it could perform 20 times more work for the same time period while consuming just 1.5 times more energy.And in this scenario 24-core processor will be much more computation-efficient, despite the fact that it shows worse result for a single threaded task. Isn't it?Quote from: brucehoult on March 29, 2025, 02:05:06 amAs the compilation example illustrates, if the same task (such as single-threaded compilation) takes longer to complete on a 24-core processor than on a single-core processor, it does not necessarily imply that the 24-core processor is less computation-efficient. Performance in a single-threaded scenario doesn't reflect the full capabilities of a multi-core processor, which is designed to excel in parallel workloads.Isn't it?The same principle applies to programming languages. Many times I have seen cases where a minor syntax adjustment in the code led to a tenfold slowdown in execution time, even though both versions were entirely correct and valid according to the language's rules.This is why, when comparing two programming languages, it is essential to take such factors into account. It is easy to end up with results where one language appears to perform ten times worse, while in reality, it is capable of delivering ten times better performance. Ultimately, it all comes down to code implementation and optimization.This is precisely why I emphasize that selecting the right algorithm and implementing it effectively is several orders of magnitude more important than the choice of programming language used to solve the task.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 02:41:33 am
content: Quote from: brucehoult on March 29, 2025, 01:18:29 amA more precise (though still very slightly simplified) accounting of the CPU MHz during that run.Code:2s 2x 5400 30x 80010s 12x 4400 20x 35008s 12x 4300 20x 350016s 12x 4100 20x 34007s 12x 4000 20x 33009s 12x 3600 20x 30001s 8x 4200 12x 3400 12@ 8009s 2x 5400 30x 800The mystery I have is that I have 8 P cores with 2 threads each, and 16 E cores but the breakdown is 12 threads at the higher MHz and 20 at the lower one, suggesting that two of my P cores only like to clock like E cores when the machine is fully loaded. Sometimes it's actually 16 threads (16 E cores) at the lower speed listed above and 4 threads (presumably 2 P cores) 100 MHz faster. But often all 20 are the same.Using taskset to run my primes benchmark on each logical CPU in turn one at a time...Code:$(./primes;./primes) >/dev/null;for X in `seq 0 31`;do echo -n "$X ";taskset -c $X ./primes | grep found;done0 3713160 primes found in 2038 ms1 3713160 primes found in 2041 ms2 3713160 primes found in 2032 ms3 3713160 primes found in 2032 ms4 3713160 primes found in 2031 ms5 3713160 primes found in 2032 ms6 3713160 primes found in 2031 ms7 3713160 primes found in 2033 ms8 3713160 primes found in 1959 ms9 3713160 primes found in 1959 ms10 3713160 primes found in 1957 ms11 3713160 primes found in 1955 ms12 3713160 primes found in 2031 ms13 3713160 primes found in 2033 ms14 3713160 primes found in 2031 ms15 3713160 primes found in 2031 ms16 3713160 primes found in 3473 ms17 3713160 primes found in 3473 ms18 3713160 primes found in 3472 ms19 3713160 primes found in 3474 ms20 3713160 primes found in 3472 ms21 3713160 primes found in 3473 ms22 3713160 primes found in 3469 ms23 3713160 primes found in 3475 ms24 3713160 primes found in 3474 ms25 3713160 primes found in 3473 ms26 3713160 primes found in 3473 ms27 3713160 primes found in 3481 ms28 3713160 primes found in 3474 ms29 3713160 primes found in 3473 ms30 3713160 primes found in 3473 ms31 3713160 primes found in 3472 msSo somehow logical cores 8-11 (physical cores 4&5) are significantly faster than the others, doing the full rated 5.4 GHz, while the other P cores all only do 5.2 GHz, and the E cores while reporting 3.9 GHz actually do the equivalent work of a P core at 3.05 GHz due to their simpler µarch.

author: radiolistener
author_rank: Super Contributor
timestamp: March 29, 2025, 02:45:20 am
content: What immediately raised concerns for me about this article is the fact that the results in the table show C# performing ten times worse than C. In my experience, having frequently implemented the same algorithms in both languages, the actual performance difference is typically around 15–30%, and not always in favor of C.When it comes to the performance of a multi-core machine, it is influenced not only by the processor but also by factors such as memory size, memory frequency, disk speed, and other system parameters. Therefore, straightforward tests of this nature are likely to yield misleading results.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 03:00:22 am
content: Quote from: radiolistener on March 29, 2025, 02:21:45 am"single-threaded compilation" is not a task. Compilation of given source code is the task.Choosing different machines, different MHz, different numbers of parallel threads are implementations of that task, just as choice of programming language and algorithm is.Quotewow.QuoteWhich has not been discussed, as yet.QuoteNo it doesn't.Measure the time. Measure the Watts. Multiply (more precisely: integrate). That's all.The machine, MHz, number of threads, programming language, algorithm are all mere descriptive text.QuoteThe assumption is that programmers in each language are trying as hard and doing an equally good job. Going back to the original paper, there are often a dozen or so different programs in each language, and the authors chose the fastest one.QuoteIt is not a choice between a good algorithm or a good language. If something is important enough to care about efficiency in the first place then you should use the good algorithm no matter which language you use.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: March 29, 2025, 03:15:37 am
content: The results certainly surprised me. Maybe it is just my ignorance, but I see no intrinsic reason why FORTRAN should be four times slower than C and hence four times worse on energy. The only reason I can come up with is that FORTRAN has lost popularity (for a variety of reasons, both good and bad) and thus the compilers do not receive the attention that currently popular languages receive. If that is indeed the case it means that the noble goals of this paper weren't achieved. Or perhaps were, but it wasn't really more than a confirmation. The best languages are those that are being actively developed and widely used.The differences in performance between the most popular current languages were minor and probably well within the error bars of the methodology.

author: radiolistener
author_rank: Super Contributor
timestamp: March 29, 2025, 03:19:18 am
content: Quote from: brucehoult on March 29, 2025, 03:00:22 amWhile it's true that using a good algorithm is essential, it's important to acknowledge that we can never be entirely certain that we are using the most efficient algorithm. In most cases, there is always room for improvement - whether through better optimization, fine-tuning, or alternative approaches. Efficiency is often a process of iteration, and even small adjustments to an algorithm can lead to significant performance gains. Moreover, you might not even realize how much you could improve the efficiency of your code by adopting a different approach or technique that you may not be familiar with.While it's a reasonable assumption that programmers in each language are putting in equal effort, the reality is that different languages offer varying levels of abstraction, performance characteristics, and tooling that can influence how efficiently a task is executed. Even if the authors in the paper chose the fastest implementation for each language (I remain skeptical of the results, as the article shows an unrealistically large performance difference between the languages, which I have not observed in practice), the overall performance can still be affected by factors such as language-specific optimizations, selected compiler and options, runtime overhead, or how well the language interacts with the underlying hardware. Additionally, a given implementation might not be the most optimal solution for every use case, and there's always potential for improvements in areas such as memory management, parallelization, vectorization, or algorithmic optimizations.

author: Tation
author_rank: Regular Contributor
timestamp: March 29, 2025, 08:49:29 am
content: Quote from: CatalinaWOW on March 29, 2025, 03:15:37 amWell, the differences between C/C++ and Python were, definitely, not minor.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 09:49:57 am
content: Quote from: Tation on March 29, 2025, 08:49:29 amIt's about 50x if you actually write your algorithm in Python, and don't call out to a library written in C.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 10:25:41 am
content: I don't know if anyone cares, but ...Quote from: brucehoult on March 29, 2025, 02:41:33 amhmm.I just re-ran and this time it was always a 16:16 split of virtual cores, with the P cores settling near the end to 3600 MHz and the E cores to 3000, not the 12:20 split I previously saw.Tried another run and virtual cores 4-7 ran at the E core MHz or 100 MHz more, right from the start.Another run, and now it's 2,3,6,7 running slow.QuoteI compared notes with someone with an i9-14900K desktop.Code:i9-14900K0 3713160 primes found in 1856 ms1 3713160 primes found in 1853 ms2 3713160 primes found in 1850 ms3 3713160 primes found in 1849 ms4 3713160 primes found in 1849 ms5 3713160 primes found in 1849 ms6 3713160 primes found in 1851 ms7 3713160 primes found in 1852 ms8 3713160 primes found in 1816 ms9 3713160 primes found in 1824 ms10 3713160 primes found in 1835 ms11 3713160 primes found in 1808 ms12 3713160 primes found in 1849 ms13 3713160 primes found in 1850 ms14 3713160 primes found in 1849 ms15 3713160 primes found in 1849 ms16 3713160 primes found in 3066 ms17 3713160 primes found in 3073 ms18 3713160 primes found in 3071 ms19 3713160 primes found in 3071 ms20 3713160 primes found in 3071 ms21 3713160 primes found in 3067 ms22 3713160 primes found in 3066 ms23 3713160 primes found in 3080 ms24 3713160 primes found in 3071 ms25 3713160 primes found in 3075 ms26 3713160 primes found in 3067 ms27 3713160 primes found in 3072 ms28 3713160 primes found in 3075 ms29 3713160 primes found in 3076 ms30 3713160 primes found in 3072 ms31 3713160 primes found in 3070 msAgain, his cores 8-11 are faster than the rest.BUT, while the other 12 P cores work out to 5.7 GHz, the faster 4 are only 5.8 GHz not the expected 6.0.AND, he pointed out to me the `-e` flag on `lscpu`, which I didn't previously know.Code:hd@i9:/tmp $ lscpu -eCPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ MHZ0 0 0 0 0:0:0:0 yes 5700.0000 800.0000 1100.00001 0 0 0 0:0:0:0 yes 5700.0000 800.0000 1553.14002 0 0 1 4:4:1:0 yes 5700.0000 800.0000 1100.00003 0 0 1 4:4:1:0 yes 5700.0000 800.0000 800.00004 0 0 2 8:8:2:0 yes 5700.0000 800.0000 800.00005 0 0 2 8:8:2:0 yes 5700.0000 800.0000 800.00006 0 0 3 12:12:3:0 yes 5700.0000 800.0000 1100.00007 0 0 3 12:12:3:0 yes 5700.0000 800.0000 800.00008 0 0 4 16:16:4:0 yes 6000.0000 800.0000 1100.04309 0 0 4 16:16:4:0 yes 6000.0000 800.0000 800.000010 0 0 5 20:20:5:0 yes 6000.0000 800.0000 1099.988011 0 0 5 20:20:5:0 yes 6000.0000 800.0000 800.000012 0 0 6 24:24:6:0 yes 5700.0000 800.0000 800.000013 0 0 6 24:24:6:0 yes 5700.0000 800.0000 800.000014 0 0 7 28:28:7:0 yes 5700.0000 800.0000 961.645015 0 0 7 28:28:7:0 yes 5700.0000 800.0000 800.000016 0 0 8 32:32:8:0 yes 4400.0000 800.0000 800.000017 0 0 9 33:33:8:0 yes 4400.0000 800.0000 1100.004018 0 0 10 34:34:8:0 yes 4400.0000 800.0000 800.000019 0 0 11 35:35:8:0 yes 4400.0000 800.0000 800.000020 0 0 12 36:36:9:0 yes 4400.0000 800.0000 1099.457021 0 0 13 37:37:9:0 yes 4400.0000 800.0000 800.000022 0 0 14 38:38:9:0 yes 4400.0000 800.0000 800.000023 0 0 15 39:39:9:0 yes 4400.0000 800.0000 1102.001024 0 0 16 40:40:10:0 yes 4400.0000 800.0000 1099.330025 0 0 17 41:41:10:0 yes 4400.0000 800.0000 800.000026 0 0 18 42:42:10:0 yes 4400.0000 800.0000 800.000027 0 0 19 43:43:10:0 yes 4400.0000 800.0000 800.000028 0 0 20 44:44:11:0 yes 4400.0000 800.0000 800.000029 0 0 21 45:45:11:0 yes 4400.0000 800.0000 800.000030 0 0 22 46:46:11:0 yes 4400.0000 800.0000 800.000031 0 0 23 47:47:11:0 yes 4400.0000 800.0000 800.0000So it's somehow official that only 4 of the virtual cores are capable of 6.0 GHz and the rest of the P cores are limited to 5.7 GHz, and E to 4.4 GHz. And similarly on my i9-1300HX it's 4 cores with 5.4 GHz, 12 with 5.2 GHz, and the E cores with 3.9 GHz.Except he's not actually getting 6.0 GHz on the single-threaded primes program, only 5.8. Curious. Why? Voltage? Cooling?

author: Siwastaja
author_rank: Super Contributor
timestamp: March 29, 2025, 10:43:17 am
content: Quote from: Tation on March 29, 2025, 08:49:29 amAnd totally obvious to anyone who ever tries to write something like an iterative or, say, image processing algorithm looping millions of times, in non-performance oriented interpreted language like Python, vs. C. The difference is two orders of magnitude.

author: tszaboo
author_rank: Super Contributor
timestamp: March 29, 2025, 10:54:55 am
content: Quote from: CatalinaWOW on March 29, 2025, 03:15:37 amAll these papers prove that programmers still don't know how to use these languages properly.In case of python, I'm yet to see a competent programmers comparison of the language. Those programmers know that the correct way to optimize python is to use one of the core optimized libraries, like numpy or numba or cyton. Once you did that, you can move the calculations to a video card or any other vector processor accelerator, for the fraction of the effort than the C code, and have it faster and more energy efficient than C.All these people claiming that pure python is slow, writing the same for loop as they would do in C, only prove that they have no idea what they are doing.And I'm sure the same goes for other languages that have optimized libraries. I'm not saying that most of them do.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 11:29:17 am
content: Quote from: tszaboo on March 29, 2025, 10:54:55 amNope. Python using numpy (etc) can NEVER be faster and more energy efficient for the machine than C, because numpy can also be used from C.The most you can claim from using Python is that it reduces the amount of programmer time and effort to write a given sequencing of wrappers around numpy calls.That's not news. Reducing programmer time has always been the reason for shell scripts that call C programs, SAS and R and SmallTalk and Lisp calling C/asm libraries etc.Reducing the solution for problems to "wrap numpy" for every programming language makes the entire exercise of comparing languages on the basis of execution time, energy use, memory use COMPLETELY pointless. They're all the same. By definition.QuoteNot at all.The point of this exercise is to find out which languages are suitable for WRITING THOSE LIBRARIES.Some people only use libraries. But SOMEONE has to write them. That someone is often me, or Siwastaja or SiliconWizard or tggzzz or some of the others posting in this thread.If you are someone who uses libraries but doesn't write them then that's great, amazing, I'm happy for you.But this post is not for you.

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2025, 12:25:22 pm
content: Quote from: brucehoult on March 29, 2025, 11:29:17 amThat will reduce the energy required. Shorter time implies fewer meals and less heating/cooling/etcGotta be holisticQuoteAreason, notthereason. I would like to think that correctness and concise expression of the solution are important considerations. I wish I could find a reference to the quote to the effect that "If I realised that the program didn't have to be correct, then I could have written it much sooner and it would execute much faster".Smalltalk is interesting because direct descendents (e.g Squeak Smalltalk) have contained the Smalltalk interpreter/VM written in Smalltalk. It also contains a Smalltalk->C converter sufficiently comprehensive for only that task. The Kyoto Common LISP compiler was similar.QuoteYes and no. When I want to drain a swamp, it is silly to suggest forging the nails, seasoning timber and the like.Efficiency is often a case of using the right tool for the job. Arguing whether nails or screws are better is frequently silly, especially if one person has a hammer and the other a screwdriver.Except in limited cases, the same is true of the whole premise of this thread

author: DiTBho
author_rank: Super Contributor
timestamp: March 29, 2025, 12:40:57 pm
content: Take a battery meter, two Casio gx calculators supported by a C SDK (Casio SH2), and able to run ucPython, then implement a nice matrix Algo (e.g. system of linear equations), iterate for a semesterA) SDK C/89 on calculator #1B) ucPython on calculator #2See the difference in term of time spent for the calculation, and battery energy

author: tszaboo
author_rank: Super Contributor
timestamp: March 29, 2025, 12:47:44 pm
content: Quote from: brucehoult on March 29, 2025, 11:29:17 amUsual arrogance aside, you would be right.Except this is a research paper, where they explicitly say what's their point at making this paper:QuoteDid they say that this paper is:"to find out which languages are suitable for WRITING THOSE LIBRARIES."No they didn't.So no, using the language incorrectly is a big issue.

author: shapirus
author_rank: Super Contributor
timestamp: March 29, 2025, 01:17:56 pm
content: There is a difference between using a language to implement an algorithm and using a language to call functions from a library where this algorithm was implemented in some other language (which is typically C).The test, therefore, was legit: the authors aimed specifically at comparing apples to apples, that is, comparing the different languages' inherent power efficiency, and therefore the results provide a useful practical knowledge. Comparing the speed of a C implementation of an algorithm with the same C implementation, only wrapped in some other language serving purely to call the library function, would obviously be pointless.What can be legitimately questioned, however, is whether specific algorithms measured in this research were implemented as efficiently as possible with regards to each specific language's features. I personally have some doubts regarding this. Fortran results, for instance, look strange, as do some others.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2025, 01:49:38 pm
content: Quote from: tszaboo on March 29, 2025, 10:54:55 amCome on. Either you're trolling, or you're precisely missing the point of comparisons. The efficient parts of numpy are written in C, so when using it, you're effectively "running" C code.But even so, it's obvious that whatever is run as "pure" python in between calls to C libraries will be less efficient than if it were all pure C. End of the story.Whether you, or whoever manages your work, decide that it doesn't matter and that's it's good because it's more productive is another matter entirely.And if you argue that reducing development costs/resources (when it actually achieves that on a large scale, which is not even fully proven) more than makes up for it, see my other coming reply.

author: brucehoult
author_rank: Super Contributor
timestamp: March 29, 2025, 01:52:10 pm
content: Quote from: tszaboo on March 29, 2025, 12:47:44 pmThey are analysing results from "The Computer Language Benchmarks Game" which does not allow the use of external libraries but only what the language implementation comes with.See e.g. Issue 292 "Usage of numeric libraries for interpreted languages"-----Is usage of numeric libraries for languages like python (NumPy and installation instructions) or lua (torch) permitted?-----Isaac Gouy @igouy-guest 5 years ago OwnerPython is as-fast-as-C when it is C.No. (Once-upon-a-time we used to show a couple of NumPy programs separately.)-----https://salsa.debian.org/benchmarksgame-team/benchmarksgame/-/issues/292

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 29, 2025, 02:29:46 pm
content: Quote from: tggzzz on March 29, 2025, 12:25:22 pmGotta look at the big picture for sure to be relevant (something that is rarely done anyway, even and in particular when talking about "carbon footprint").But there's something fundamentally flawed in considering the above (energy requirement for development) as a significant contributor compared to the energy required to *use* the software.This flawed argument is a basic economic misconception, in particular since we (at least I with my first post) are talking about the "software industry", so whatever develops software for commercial use. In the big picture, development costs can't be higher, or even comparable, to the costs of runinng said software in the field. Otherwise we have a fundamental economic problem. This problem is not completely obvious though, it really takes looking at the big picture. It's not dissimilar to the concept of "green growth", at least the part that would claim we can have economic growth while not growing our global energy consumption. It just doesn't physically work, but it looks cute.In practice, only for niche software can development costs and energy consumption be significant compared to those of exploiting said software. Otherwise, that's never the case. And it's only rational to consider that anything niche can pretty much be done any way that looks convenient as it has close to zero impact on a large scale.Widely used software, OTOH, is a definite problem in terms of efficiency. Any piece of software that runs on a large scale and that could be made, say, 2x more efficient in terms of resources needed (memory/storage) and in terms of execution (energy consumption), requires twice what it could. Period. Claiming that it has no impact would be dishonest. Especially considering how software has become ubiquitous.Now this has to be approached rationally, of course. Again, when developing "niche" software, there's no need to even bother. Although there can still be benefits if said niche software can be a bottleneck: say some in-house software used as a production tool - if you can make the same tool twice as fast, you'll have a direct impact. And sometimes it's a lot more than twice that could be achieved, and no amount of faster hardware would make up for it.For widely used software, the impacts can be drastic. Interestingly, but quite logically, software development, compared to hardware, is one activity for which only the cost of development matters, as this is the only direct cost for the organization developing it and the only direct impact on its operating margin, whereas with hardware, the cost of production is a major thing, which pushed companies to make more efficient designs in terms of parts cost and ease of production.What I find also interesting but also not surprising is how the thought of developing more efficient software seems to offend quite a few people. Generally speaking, when we think we're already doing our best, whether individually or as a group, then we are usually most definitely not. Sometimes just mentioning it seems to trigger reactions in the vein of "don't touch my toys".Niklaus Wirth was already deploring the increasing bloat of software more than 30 years ago, for instance in his "A plea for lean sofware" - 1995, and a lot of others before, and after him. It's not a matter of any particular programming language, it's a more general issue. The bottom line is that companies have absolutely no incentive to make software more efficient - as long as they more or less fit the purpose even if they require a comparatively absurd amount of resources to run, and all incentives to solely focus on convenience of development, so the end result can't be anything else.And I'm not for making laws to force companies to do things differently, but I also don't see any other workable way other than customers actually demanding more efficient software. So far, they are not. Just a thought.

author: Tation
author_rank: Regular Contributor
timestamp: March 29, 2025, 02:38:56 pm
content: Quote from: Siwastaja on March 29, 2025, 10:43:17 amIt is indeed also obvious to me, in spite of not writing video coders nor THOSE LIBRARIES.But I meet at work, with a non-negligible frequency, people thinking like:Embedded? Oh, of course, that's "add a RPi and throw Python code into it"Why we can't use Python on this CR2032 powered wearable/tag/patch?Why do even exist programming languages other than Python?Thus, the difference may be not so obvious to everyone.

author: Nominal Animal
author_rank: Super Contributor
timestamp: March 29, 2025, 03:00:38 pm
content: The premise is interesting, but the implementation necessarily takes shortcuts that make the results basically useless.The fundamental complexity here is that programming languages are tools used to create tools (programs, applications, libraries) that are used to solve problems. Comparing the energy consumption of the end result is a nice and simple-sounding idea, but hellishly complicated in practice.One of those complications, one that I'm extremely familiar with, is the definition offastorefficient: do you measure wall-clock time, or the CPU time only? For human-interactive tasks, we should use wall-clock time because of the energy costs of maintaining that human there waiting for the results. For non-interactive tasks, we should use CPU time because there is no human waiting for the results. Using one yardstick for all is utterly unrealistic, like assuming all humans are interchangeable spheres 1m in diameter and expecting the end results to have sociological meaning.My favourite example, one that made me realize this myself back in mid-nineties, is the common task of reading an unordered dataset from storage to a specific order in memory. If you want to minimize the total CPU time used, you read the data, then sort it with an efficient sort algorithm. (The exact algorithm to use depends on the relative cost of comparisons and insertions and swaps.) If you want to minimize the wall-clock time, you use slightly more CPU time to split the incoming data into records and store it into a self-sorting structure like a binary heap or a tree. The difference is that reading the incoming records into a self-sorting structure uses the wall-clock time otherwise unused in waiting for more data to arrive, our computing devices still being limited by the storage I/O data transfer rates.When we compare programming languages, we almost always include the standard libraries that language environment provides. Both the programming language itself, and its standard libraries, have a specific approach to problem solving. For example, all arrays inAwkare associative with string or integer keys (thusdictionariesormaps), notindexedas in most other programming languages; and at the core, one-dimensional (although multidimensional arrays are supported via string keys concatenated using a reserved character). In essence, in Awk, youcannotin any sensible manner read incoming records into a self-sorting structure, because it does not support self-sorting structures (in any sensible or efficient manner). However, its arrays are extremely efficient.Therefore, comparing the same algorithm implemented in different languages is problematic, because it ignores how the language typically solves the problem the algorithm is applied at. Again, implicit assumptions, essentially making the choice of Computer Languages Benchmark Game iffy. To be useful, the paper would instead need to compare the energy performance of complete tools.Finally, the paper ignores mixed-language applications, especially those using native-language libraries. Software isn't static: they must be maintained to stay compatible with existing systems and formats, and optimally,reconfigured and optimized for the needs of the tasks at hand. I very much like to split the end-user safely-modifiable parts (the graphical user interface) into high-level interpreted language so end-users don't even need a development environment, just modify some text files, to change the application to better suit their work flow,and save precious time and mental effort; keeping only the hard-core data lifting and proprietary bits in native-language libraries provided in binary form. How do you account for the energy savings in end-users (or their organization on their behalf) adjusting the code to best fit the work flow at hand? Sometimes very simple changes can save a significant amount of human waiting time; that is why we have plug-ins and extensions and scripting interfaces to applications.In light of all of the above, I am not at all certain that assigning any kind of one-dimensional "energy efficiency" rating, or even comparing any two programming languages on their purported "energy efficiency", makes anypracticalsense: it is too much of an abstraction with too many implicit assumptions to be useful in practice. There are only two use cases that I can see: telling development organizations that the choice of programming language has energy usage implications (without being able to provide any practical guidance), and to proselytize for and against programming languages benefiting/penalized by the implicit assumptions.

author: madires
author_rank: Super Contributor
timestamp: March 29, 2025, 03:37:05 pm
content: Quote from: tszaboo on March 29, 2025, 10:54:55 amFromhttps://fabienmaussion.info/scientific_programming/week_04/01-Why-Numpy.html:Quote

author: tszaboo
author_rank: Super Contributor
timestamp: March 29, 2025, 04:09:45 pm
content: Quote from: madires on March 29, 2025, 03:37:05 pmI'm well aware.Quote from: SiliconWizard on March 29, 2025, 01:49:38 pmNo, I'm being serious here, with just a hint of trolling. None of the people in this thread could write C code which would actually in real world conditions outperform in all possible scenarios the very well optimized python libraries. For starters, because numpy is written by 1700 people, and no matter how much narcissism there is, it's just going to result faster code.They have to turn to these artificially created handycapped scenarios.In real world, you end up with stuff like this:https://github.com/OpenMathLib/OpenBLAS/issues/3538People being stunned and not understanding why their numpy is going faster, when they try to rewrite it in the 'very efficient C'.Then we can start talking about the different compliers. And how 1700 people have the time and put in the effort to make the code performant on different architectures. And how you can optimize for speed with ray, or efficiency by handing it over to specialized hardware with a few lines of code.Is C faster than python? Sure.Can you, as a developer with limited resources given to you, actually write code as performant than well written python?

author: ejeffrey
author_rank: Super Contributor
timestamp: March 29, 2025, 04:20:48 pm
content: Not to surprising in broad strokes, but definitely focused on a specific set of problems. It's not clear to me how generalizable the results are. But the basic idea that execution time mostly but not exactly tracks power useSome of the individual results for some of the high performance compiled languages are a bit surprising, for instance the variation for languages like C++ compared to C. C++ is mostly a superset of C and can be basically as fast as C, and sometimes faster. So the obvious conclusion here is that the C++ programmers chose a less efficient design. Which is a fair point but one worth looking more into.My understanding is that they averaged multiple implementations for each language. It would be interesting to see the variances maybe that was in the paper but I didn't see it.

author: ejeffrey
author_rank: Super Contributor
timestamp: March 29, 2025, 04:38:08 pm
content: Quote from: madires on March 28, 2025, 07:28:17 pmNot on the scale relevant to this paper. The faster python project and the python JIT have been mostly getting improvements in the 10-20% level. But that's the difference between python code being 50x slower than C and 40-45x slower.The python nogil work will allow python to use multiple cores more efficiently which will improve wall clock time for threaded programs. It won't improve CPU time or energy efficiency for the most part.A real JIT might be able to improve python performance to be similar to JavaScript and would be major revolution. But it's quite difficult to develop a python JIT.On the other hand sometimes you can make python dramatically faster by simply compiling with cython. Usually you have to make some changes to get major speedups but often it's quite simple.

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2025, 06:37:16 pm
content: Quote from: ejeffrey on March 29, 2025, 04:38:08 pmJIT is mid-80s technology, first introduced in Smalltalk. It is a cached peephole-optimised compiled version of the bytecode.A more interesting technology was developed in the 90s. It allowed anemulatedprocessor to executeoptimisedCfasterthan running the binaries on the processor itself! The technique was first developed in Self, was tried with C in the Dynamo project, but then "accidentally" became a production technology. Alternatively, "... the performance of many +O2 optimized SPECint95 binaries running under Dynamo is comparable to the performance of their +O4 optimized version running without Dynamo."How did it manage that? It instrumented the runtime to find out theactualcode and data access patterns (cf what might be guessed at compile time), then optimised the hell out of those. C and C++ are poor in that respect since there is too much ambiguity at source code level, which results in pessimised binaries.Such techniques have been adopted into more modern languages, notably Java. Of course "enterprise Java" is the poster child for poor performance due to multiple of crap layers/libraries/algorithms - which are much more important than the underlying language.Overall it is a shame that too many people are still taught to perform "coding optimisations" based on technological assumptions that were outdated in the early 90s. Science progresses one death at a time.https://shiftleft.com/mirrors//www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf

author: Picuino
author_rank: Super Contributor
timestamp: March 29, 2025, 07:02:43 pm
content: Many of the tasks that different languages are required to solve in this paper are tasks for which compiled languages are specialized. As in the attached joke, it is a somewhat biased quiz.Interpreted languages are all slower than compiled languages, but they are still widely used despite all the current pressure for greater execution efficiency. This is a paradox that anyone who is in the business of denigrating interpreted languages should try to solve.Interpreted languages are often used in conjunction with highly optimized libraries and all they execute is the “business logic” and not the hard work of repeating a loop billions of times.

author: Picuino
author_rank: Super Contributor
timestamp: March 29, 2025, 07:16:06 pm
content: Interpreted languages are not specialized in execution efficiency, but in programming and maintenance efficiency.Hence PHP, Java, Python or JavaScript are widely used.For example JavaScript/TypeScript could be replaced by compiled languages, e.g. Rust, with WebAssembly technology and gain execution speed. But this change would make the development and maintenance of web applications more difficult.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 29, 2025, 07:42:07 pm
content: Quote from: SiliconWizard on March 29, 2025, 02:29:46 pmYour points can be pretty much summarized as:* For internal single-use tooling, use whatever is fastest to write, ignoring performance (in most cases)* For end-product used by large masses (at their computers, or in data centers / server farms, doesn't matter which), performance in most cases mattersI have some trouble with this dualism, wrapping my mind around having to maintain these two sets of skills all the time. And clearly so do others. It is very common to write "end products" in inefficient languages/frameworks/mindsets simply becausedevelopers are familiar with them, and they feel thatit doesn't matter, because they have fixed themselves into the "single use tooling/exercise" mindset and extend that to something it doesn't belong to. It's horrible.I have the same issue with only maintaining one of the above, but I do the opposite. I write my small scripts in C, because... I have my mind set on the end product. I can use the same header files. I can mix production code and tooling code with fewer wrappers. I don't have to maintain knowledge of another language.And I'm sure this feels weird to many. On paper, it would be much faster to do "small tests" and tooling and so on, in Python, than in C. Especially concentrating on some low-level memory management stuff when "just testing out" an algorithm feels awkward. But the few times I have tried to do something in Python I have been very unproductive, because I do so little of it. And then I have to switch to working in Canywayfor most of the project.So I have written generic CSV parser for some tasks in C from scratch. Spent maybe half a day for that. But then again, it runs an algorithm which simulates real time of one year in one hour. And this algorithm itself needs to be in C. I often put a 12-core server to run tens of those for the whole night. With algorithm written in Python, I'd need to wait for a year. So it's out of question. But I could write the CSV import part in Python, sure. And some visualization, etc. But then I would have a mixed-language project with interface work.Maybe some others on this forum are more "at home" with multi-language projects, but clearly looking at how nonoptimal language choices commonly are, I suspect this "best tool for the job" is a rare skill. Realistically, people use what they are familiar with, and that leads to algorithms being written in Python, because not everything can be solved by a few library function calls.

author: DiTBho
author_rank: Super Contributor
timestamp: March 29, 2025, 08:12:19 pm
content: GoLang? Anyone?

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2025, 08:43:39 pm
content: Quote from: Picuino on March 29, 2025, 07:02:43 pmSome businesses compile stock market trading rules into hardware; VHDL and FPGAs. C is too inefficient and slow.Choose the right tool for the job. That implies you know the job, a wide range of tools, and the fundamental equivalence of them all. Not many people can do that.

author: Picuino
author_rank: Super Contributor
timestamp: March 29, 2025, 10:29:25 pm
content: That argument is a kind of logical fallacy.- People like to walk in the park at low speed.- But there are people who race in formula 1 on high-speed circuits.- True, as is still true of the first sentence.It is still true that front-end logic is done with JavaScript, not with C or VHDL.

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2025, 01:20:56 am
content: Quote from: Siwastaja on March 29, 2025, 07:42:07 pmJust#include <gc.h> and useGC_malloc()instead ofmalloc()and delete all thefree()C gets even better if you dump much of the rest of the standard library and use better, GC-aware, stuff.apt install libgc-devif required. advanced: keep some GC_free() if you're really really sure. Also optimise by using GC_malloc_atomic() for things you're sure won't have pointers inside them, strings, buffers etc. There are also weak pointers and finalisers available if you need them.

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2025, 01:24:21 am
content: Quote from: Picuino on March 29, 2025, 10:29:25 pmNode runs algorithms written in pure JavaScript about as fast as C compiled without any-Ooption. It's worlds different in speed to Python -- though about as quick to write code in. More people should consider it.

author: radiolistener
author_rank: Super Contributor
timestamp: March 30, 2025, 02:41:46 am
content: Quote from: brucehoult on March 29, 2025, 09:49:57 amSuch a significant performance difference suggests that the language is implemented as an interpreter. It is quite surprising that Python has not yet fully transitioned to JIT compilation, as many other popular languages have. With JIT, the performance gap would likely be much smaller, as just-in-time compilation can optimize code execution dynamically, bringing interpreted languages much closer to compiled ones in terms of efficiency.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 30, 2025, 06:48:52 am
content: Quote from: Picuino on March 29, 2025, 10:29:25 pmAnd this analogy is so wrong. In reality, need for performance in computing is not an exception (like some special racing event), it's really ubiquitous. Our lifestyles depend on stuff like shitposting on this very forum or twitter or whatever, watching Youtube crap, we are pretty much glued to our smartphones.All of that is pretty resource-consuming (both in end-user devices and server infrastructure) and is completely enabled by relatively efficient programming (it could be even better, though). If you tried to replace that with, say, Python, the whole world would just collapse.Using inefficient programming paradigms and languages is really a special luxury available only in some special cases. Enjoy it when you can. The idea is to save developer time at the expense of computing time.QuoteAnd that is exactly why JavaScript saw big fundamental changes well over a decade ago, and become quite efficient language: automated minimalization/obfuscation of code, and JIT compilers in browsers.Same has not (yet?) happened with Python for example, but it'stheoreticallypossible - it's not like the language syntax itself forces inefficient implementation. But so far there has been not enough need; the raw performance of writing algorithms in Python is so inefficient that it itself drives programmers to do something else. Clearly everyone's happy and people know where and how to use Python, to the point of it being so obvious that not everybody understandswhatarticles like this one are really talking about andwhy.

author: Tation
author_rank: Regular Contributor
timestamp: March 30, 2025, 07:46:19 am
content: Quote from: radiolistener on March 30, 2025, 02:41:46 amSince version 3.13 CPython source code includes JIT compilation, although it is not enabled by default when built, but you can enable it in your builds. PEP 744 describes it and why it is, by now, experimental and why it is not enabled by default. From such PEP (boldis mine):QuoteSo we are very far from JIT speeding Python from 50x-75x slower than C to being comparable to it.

author: Picuino
author_rank: Super Contributor
timestamp: March 30, 2025, 08:20:54 am
content: Quote from: Siwastaja on March 30, 2025, 06:48:52 amThe article places PHP close to Python and far from C or Rust.However, despite being a slow language, it is the language that drives this SMF-based forum and entirely programmed in PHP.https://download.simplemachines.org/EDIT:All this reasoning about the need for speed (which is true), however, does not answer the fundamental question: Why are slow languages still used? Because it is a reality that they are used.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2025, 10:19:01 am
content: Quote from: Picuino on March 29, 2025, 10:29:25 pmNot always...https://www.vemeko.com/blog/67121.htmlhttps://github.com/muditbhargava66/High-Frequency-Trading-FPGA-System("Modify the custom IP core (custom_ip_core.v) to implement your desired processing logic. Update the risk management module")(risk_management.v) with your specific risk limits and monitoring rules.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2025, 10:22:10 am
content: Quote from: Siwastaja on March 30, 2025, 06:48:52 amPython is currently hampered by the Global Interpreter Lock.ISTR moves to remove that, but in my ignorance I expect it is deeply embedded in the language. Hence I'll believe Python can be multithreaded after it has been proven

author: Tation
author_rank: Regular Contributor
timestamp: March 30, 2025, 11:43:38 am
content: Quote from: tggzzz on March 30, 2025, 10:22:10 amCPython 3.13 has (experimental) support for free-threaded mode, with the GIL disabled. It is possible to download official CPython binaries with such mode enabled (and, so, no GIL) selecting the appropriate option in the installer.PEP 703describes this. I find this change much more promising than the experimental JIT.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2025, 11:50:37 am
content: Quote from: Tation on March 30, 2025, 11:43:38 amExperimental, far from defined let alone implemented and tested. Given the number of "topics" mentioned in PEP0703, I'll wait until it has been proven to work.A 30s skim indicates, for example..."Many recent garbage collectors are mostly concurrent – they avoid long stop-the-world pauses by allowing the garbage collector to run concurrently with the application. So why not use a concurrent collector? Concurrent collection requires write barriers (or read barriers). The author is not aware of a way to add write barriers to CPython without substantially breaking the C-API."and"Like PEP 683, this PEP proposes an immortalization scheme for Python objects, but the PEPs use different bit representations to mark immortal objects. The schemes cannot be identical because this PEP depends on biased reference counting, which has two reference count fields instead of one."

author: Tation
author_rank: Regular Contributor
timestamp: March 30, 2025, 12:06:15 pm
content: Defined enough to be implemented a few months ago and being now tested in the wild.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 30, 2025, 01:24:28 pm
content: Quote from: Picuino on March 30, 2025, 08:20:54 amYou realize that when we shitpost on this forum, maybe 0.01% of the chain is PHP code? Think about it what happens when you type and your text appears on my screen, use your brain, I know you can do it. Don't forget text input, drawing on monitor, TCP/IP stack and so on.That PHP part could indeed be anything else, performance-wise, including Python. And PHP being such trainwreck it is, Python would be a much better choice.We can manage inefficient languages in certain parts exactly thanks to everything else being optimized for performance. That includes efficient libraries called from PHP or Python.

author: ejeffrey
author_rank: Super Contributor
timestamp: March 30, 2025, 03:30:51 pm
content: Quote from: Siwastaja on March 30, 2025, 06:48:52 amThere is the PyPy alternate implementation which uses a JIT and gets significant performance improvements. Python is not an easy language to make a well performing JIT due to its object model, but the biggest limitation is the C API. CPython has far more 3rd party native code extension libraries than any other interpreted language. Getting a JIT for fast python execution while giving up existing native code extensions is often going to be a performance downgrade.I think PyPy has some support for the CPython API but it is incomplete and comes at a performance cost, presumably because it has to create full python objects that could otherwise be optimized away.

author: brucehoult
author_rank: Super Contributor
timestamp: March 30, 2025, 05:31:42 pm
content: Quote from: Siwastaja on March 30, 2025, 01:24:28 pmI think PHP is efficient enough as a templating engine, substituting variables into slots in HTML -- engine written in C of course. There won't be a lot of algorithmic code going on.

author: radiolistener
author_rank: Super Contributor
timestamp: March 30, 2025, 06:16:29 pm
content: Quote from: Picuino on March 30, 2025, 08:20:54 amI find the results of that article highly questionable, as some of the performance comparisons contradict what is commonly observed in real-world testing. For example, it claims that Java is faster than C#, which seems unrealistic - I didn't seen Java outperform equivalent C# code. On the contrary, Java applications often exhibit higher latency and slower execution, with C# showing a significant performance advantage, especially on Windows.From my own experience, one case that stood out was when rewriting an application from Java to C# on Android resulted in a significant performance boost of up to 300-400%. Similarly, I have observed discrepancies in the comparison between C and C#. In practice, I do not see such a dramatic performance gap between these languages, despite frequently benchmarking and comparing performance-critical code written in both C and C#.An even greater inconsistency can be seen in the compiled code size results. It almost seems as if the author deliberately repositioned languages that should have ranked at the top toward the middle of the list.The reason I am skeptical about this article is that the data it presents contradicts the performance results I have consistently observed in real-world testing. Given these inconsistencies, it seems likely that this is a biased or sponsored bullshit than an objective, data-driven analysis aimed at accurately representing performance/efficiency comparisons.I can understand if the test code was deliberately selected to produce the desired results. However, in that case, the findings of such a comparison are clearly meaningless and hold no real value.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 07:09:08 am
content: Quote from: brucehoult on March 30, 2025, 05:31:42 pmYou can actually find quite a lot of logic within the SMF code.You can take a look at one of the project php files I have attached (renamed to txt) .

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 07:14:55 am
content: Quote from: Siwastaja on March 30, 2025, 01:24:28 pmHow did you come up with that 0.01%? Do you mean time consumed, energy, maybe something else?The conclusion I have come to, using my brain, is that you finally realize that the use of interpreted languages is quite useful and not as slow as it seems, or at least not as slow as some papers would have us believe.

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2025, 08:23:14 am
content: Quote from: Picuino on March 31, 2025, 07:09:08 amI didn't read the whole thing. Half maybe. It's mostly straight line code with if/then/else and a lot of database calls, which will take far more time than processing a bit of script logic.The loops I found were mostly around database calls, or in one case a string trim that looped around a regexp replace, which is also going to dominate that loop.The worst thing I noticed (for speed being limited by the scripting nature of the language) is a function to scan characters in a string and UTF8-decode it, which 99% of the time is going to come down to "fetch character, check if it's under 128, which it is, so append it to the output string". It's notidealto do that in PHP (or Python) but at least it's only O(n) on things that probably aren't that large.If something is going to take a µs in C but 50 µs in PHP/Python that's not going to be a big deal. The big deal comes when it's going to be 100 ms in C -- a billion instructions on a modern x86 -- and 5 seconds in PHP.

author: Jeroen3
author_rank: Super Contributor
timestamp: March 31, 2025, 08:36:35 am
content: I don't think this discussion is talking about the correct meaning of the result.Sure the results could be debatable. But the results are also not wrong.As expected, the native compiled language, with decades of optimisation for low level performs best. Then the native compiler with safeguards a bit slower, followed by the interpreted languages.But this should not spark debate about which language is best. It should spark debate about scale.For example: If you add one additional function to the PHP of this forum, and some more javascript to this forum. Then it may takes 2 microseconds longer for each request.But multiplied by392356average page views per day that is 2 seconds of extra cpu time per day.That's not that bad, right. But what if...3 billion devices run javaDecisions about language or where in the stack you do a computation may add up to a significant amount of energy globally if you have the scale.And looking at how typescript does in these results....

author: tszaboo
author_rank: Super Contributor
timestamp: March 31, 2025, 08:55:05 am
content: Quote from: Jeroen3 on March 31, 2025, 08:36:35 amNo surprises there, really. But also incorrect usage of the languages.If you would drag race two cars, one with electric engine, one with petrol, would you allow the petrol car to shift gears? Electric would likely win. And the electric doesn't need to shift. But if you don't allow the petrol to shift, your results are just bad. And nobody who knows how to drive actually uses the car that way.Let's take something concrete if we are talking about websites and PHP and Javascript:I've run profiling on this very page, and see the reults for yourself. The "saythanks" seems to block loading the page for 300ms, and about 50% of the time is spent on HTML parsing. Also about 300ms on CSS, which as I remember is the styling, colors and fonts.Then again, if it's blocking the rendering, does it do something, or waits for data. How much the consumption is on the client side, how much on the server. What if the server is swamped with many requests at the same time, by chance?

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2025, 09:18:21 am
content: Quote from: Picuino on March 31, 2025, 07:14:55 amThink about it! It can't be time or energy consumed. Exactly because I'm claiming that part to use "inefficient language", it means it's consuming relatively more time and energy, than in "efficient language". But then again, if it's, say, 50x less efficient, that 0.01% would still be just 0.5% in time and energy. So not a problem at all.So that % is some hand-wavy percentage of "functionality". Maybe very roughly lines-of-code, even.Do you see where I am getting at? If 0.01% of "total functionality" is implemented 100x less efficiently, that is still only 1% of total energy. So everything else still dominates. But what if we replaceeverythingwith the "inefficient language"? Then that 0.01% part is back down from 1% to 0.01% of total energy relatively, but absolute energy to do that everything just went up by 100x.So we evendiscussingabout if Python or PHP is 40 or 50 or 60 times slower than same algorithm written in C is made possible by the fact that everything else in this chain is (A) fast enough, (B) dominating in execution time.TLDR really is, inefficient scripting or interpreted languages are used whenever their inefficiency does not matter. No news here. Languages like this have existed already in 1960's. But trying to somehow white wash them as not being "as inefficient" is just ridiculous, and I think this is a new phenomenon. I don't see any sensible reason to do that, just fanboyism.QuoteNo one ever disagreed with you on that, though. Fanboyism is bad for your health. Wasting a lot of time in creating totally unnecessary strawmen and fighting against them.Don't forget that a reader of academic paper also has some responsibility. Generally, if something doesn't seem to make any sense to you or seems blatantly incorrect, you should consider the possibility you are misinterpreting it. As brucehoult said, a paper which compares energy use of calling the same numpy (or whatever) C implementation from wrappers of different languages would be useless*. So clearly the paper must discuss something else than "efficient programming through intensive library use". If the paper is not relevant to e.g. your current project, fine. It isn't relevant to you then. But it still gives a good rough idea of relative energy consumption of computationally heavy algorithms implemented in different languages.*) maybe not completely useless; how the wrappers work could be compared, but it would be a totally different thing neverthelessStop thinking about everyone not praising Python in every sentence as your enemies. Instead, think about it that way: the paper can be highly useful for a fresh Python programmer as it shows that if you try to do e.g. a string processing loop parsing hundreds of megabytes of text in Python, it will be very slow; but instead, the correct solution is to utilize library functions in Python to achieve same, and then that would be fast because those libraries are written in C. Do you also now see why I said 0.01%? You can do pretty fancy stuff in Python with just dozens of lines. And youshoulddo exactly that. It will then also run fast. Because 99.99% of code is elsewhere.This is the truth, and knowing the truth is helpful. C enables your Python programming, andthere's nothing wrong with that. We don't have to be enemies because of that.The real world is operating beautifully, with different languages operating in synergy, filling the gaps of others. Specifically, Python and C have a strong relationship. You should just accept that, because it's a fact of life, and it's beautiful.

author: brucehoult
author_rank: Super Contributor
timestamp: March 31, 2025, 10:06:20 am
content: Quote from: tszaboo on March 31, 2025, 08:55:05 amMaybe not the best example. My (factory stock) 265 HP 2008 Subaru Outback does 0-100 km/h faster than any Tesla that doesn't have AWD. And, yeah, it changes gears a couple of times in that. It doesn't matter how much power you have if you're traction-limited.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 10:55:42 am
content: I have not talked about Python, but about interpreted languages, in general. And I know well both the limitations of these languages and their strengths.I am the first one who fled from Basic to embrace compiled Pascal as a wonderful language for its speed and its orientation towards structured programming and object-oriented programming (TurboPascal).But when I later discovered the simplicity and power that interpreted languages could have (starting with AWK), interpreted languages won me back.What I don't understand is this mania for speed, without realizing that the Pareto principle (that you have described with the 0.01%) tells us that a large percentage of code will only represent a minimum percentage of execution time and that code is more worthwhile to be written in an interpreted language in many scenarios.https://en.wikipedia.org/wiki/Pareto_principleEDIT:I am not talking about replacing compiled languages with interpreted ones, nor about making simple and repetitive algorithms with interpreted languages.What I am saying is that interpreted languages have their niche and it seems that in this forum that obvious thing is not mentioned or is answered as something said by a fanboy.It is as if you want to deny the reality of a large amount of code that is programmed to be interpreted (despite its slowness, which I do not deny).

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2025, 11:09:48 am
content: Quote from: Picuino on March 31, 2025, 10:55:42 amOh, but here the math is easy. Assuming 50x speed difference between "fast" and "slow" languages, 2% of the whole chain could be "slow" and 98% "fast" and that would lead to half of the execution time being spent in the "slow" part, and maximum theoretical improvement (by switching everything to "fast") being a tad below 50%.We sure can afford slow languages, but it needs to stay in "niche" (per work done). It works exactly in my 0.01% scenario. It will still work in 0.1% scenario and even 1% scenario, but not any more at 10% (unless we are willing to accept significant trade-off in speed; I am not).Most of the calculation work being doneneedsto be done efficiently. And that's exactly how it is, in real world, because once something gets too slow for comfort, people complain and it gets fixed.I don't understand the mania comment. I think performance isunderappreciated, if anything. Inefficient solutions have been really popular for long time, exactly because we can afford them, but sometimes it goes too far. It's nearly unbelievable that an open source spreadsheet software cannot handle 5000 rows in a spreadsheet in freaking year 2025 on a typical mid-end laptop. I would hope those "manic" guys would fix this.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 11:22:09 am
content: I have no idea what the actual percentages will be and would like to know. That would be an interesting paper.On the other hand I see interpreted languages everywhere. In this forum, without going any further, HTML, CSS, JavaScript, PHP. Underneath there are, of course, very efficient C implementations to handle the database, the on-screen presentation, etc. But as I see it, both complement each other and are coexisting in many, many scenarios.

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2025, 11:57:54 am
content: Quote from: Picuino on March 31, 2025, 11:22:09 amAnd then, of course, the interpreter concepts are used "lower down". Classic example is that in many cases a single x86 CISC instruction is executed by many "invisible" internal RISC µops.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 12:12:40 pm
content: All microcontroller instructions are actually interpreted, including RISC instructions. The opposite would be the execution of hardcoded algorithms on an FPGA or ASIC.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2025, 12:15:53 pm
content: Yeah, interpreter concept does not need to be inherently inefficient. Instead of hand-waving based on generalized ideas, measurements of real-world products are valuable, and that's exactly what this paper is trying to do. But it also causes a lot of backlash; no measurement is perfect, and it's impossible to cover all types of uses, so some people always get offended.Quote from: Picuino on March 31, 2025, 12:12:40 pmCalling a CPU an "interpreter" is of course possible, but I don't know if that'susefuldefinition. We already have a term for a CPU which differentiates it from hardcoded logic (e.g. ASIC):CPUorprocessor. Term CPU itself implies that the thing is interpreting bits in program memory and acting based on those.

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2025, 01:24:08 pm
content: Quote from: Siwastaja on March 31, 2025, 12:15:53 pmIt is useful, since changing the interpreterafterprocessors are installedin the fieldis the way Intel and AMD mitigate vulnerabilities such as rowhammer. That there are such vulnerabilities is a consequence of having to make the interpreter+hardware so damn complex in order to get the last 0.1% of performance.

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2025, 01:30:59 pm
content: Quote from: Picuino on March 31, 2025, 12:12:40 pmThe original RISC processors had instruction sets where the fields mapped directly onto internal signal lines. That was the reason they were relatively fast and consumed little power.That has completely changed for some processors, particularly x86 where superscalar operation is the key to their performance.For other processors, especially barrel processors like Sun's Niagara T series which avoid the penalties of superscalar operation, it is unclear whether it has changed.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 02:12:57 pm
content: I think that in the scope of the discussion of this thread, calling machine language an INTERPRETED language is quite relevant and accurate.We are talking about efficiency and speed and in that area ASIC circuits win by a landslide, and can be a hundred times faster than compiled C.But it turns out that there are other considerations just as important as speed and efficiency, which are flexibility and implementation cost.At one extreme we have the fast, efficient ASICs that are very rigid and expensive to design.At the other extreme we would have the purely interpreted languages, slow, inefficient and very flexible and cheap to program.There is a whole range in between: FPGA, RISC CPU, CISC CPU, assembly language, compiled languages, bytecode, interpreted languages and surely some more that I have left out.

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2025, 02:24:58 pm
content: Quote from: Picuino on March 31, 2025, 02:12:57 pmAnd that's why the whole premise of the paper and this thread is ... misguided.Choose the right tool for the job at hand. Not a difficult concept!

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2025, 02:26:37 pm
content: Quote from: tggzzz on March 31, 2025, 01:24:08 pmYou missed the context. Picuino suggested that even simple CPUs not running modifiable microcode could be called interpreters of some sort.Thatis not useful IMHO. I agree it already makes much more sense with microcode that can be updated, it's like a very small and efficient interpreter of a very low-level programming language.

author: tggzzz
author_rank: Super Contributor
timestamp: March 31, 2025, 02:35:29 pm
content: Quote from: Siwastaja on March 31, 2025, 02:26:37 pmI'm not sure I do see the context, but it isn't worth disappearing down that rabbit holeDepending on what is meant by "interpreter" - and English is a very, um, flexible language - even a simple RISC without microcode could be regarded as interpreting the API. Another boring rabbit hole

author: madires
author_rank: Super Contributor
timestamp: March 31, 2025, 02:52:34 pm
content: It's all about TCO. A quick n' dirty script is great for automating things when it's run only a few times a day. If you run a large shopping website and need much more servers to deal with a script based shop framework it might be more cost effective to spend money on something old fashioned like C and running much less servers. Do the math for you specific use case and it will become clear what to choose.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 03:00:11 pm
content: Do you know of an online store that uses compiled C instead of PHP?

author: madires
author_rank: Super Contributor
timestamp: March 31, 2025, 05:03:26 pm
content: They rarely tell which framework they run. But yes, I've seen websites running frameworks based an compiled code, and they are fast. Anyway, it's up to each site what they prefer or not. And please don't try to apply the strawman fallacy.

author: Picuino
author_rank: Super Contributor
timestamp: March 31, 2025, 06:37:55 pm
content: I will try not to use fallacies. I don't like them being used on me. But it is really difficult that in this forum do not appear fallacies or more or less tortuous arguments to defend that one is right.Well, to the point, I for one can give you dozens of examples of frameworks, CMS, eCommerce platforms, etc. based on PHP, Ruby, Python or JavaScript, but I don't know any based on compiled languages and I have spent quite some time looking for different CMS years ago.Some of the known projects are quite large and yet you can see that they are based on Wordpress, Drupal, Shopify or any other similar platform.The question had some malice, but also a genuine interest in knowing some case that I don't know, considering that I know a little bit about the subject but not in depth.

author: Siwastaja
author_rank: Super Contributor
timestamp: March 31, 2025, 07:02:01 pm
content: Web shop would be obviously implemented in whatever language is popular among developers for obvious reasons (something familiar -> easier to write; popular language -> more maintainers).Once you have HTTP server, PHP itself, TCP/IP stack and so on all implemented in C, it doesn't make much difference if PHP handles querying a few product names in shopping basket and some price data from (inefficient) database, instead of e.g. C. The amount of data flow per customer is just so ridiculously low. Now much more demanding magic happens e.g. when showing high-resolution images of the products, but no one would manipulate pixels on PHP. You would instantly see how it fails if you tried to.

author: shapirus
author_rank: Super Contributor
timestamp: March 31, 2025, 07:29:05 pm
content: CPU time isn't everything. There's also memory usage. Some interpreted languages or, rather, certain frameworks used in web backend apps result in ridiculously high amounts of memory consumed on performing fairly basic tasks.But server resources are often much cheaper than skilled programmers, so we have what we have.Here's, for instance, three k8s pods with WordPress with a few plugins (I think Elementor being the worst offender) which aren't even seeing much load:NAME CPU(cores) MEMORY(bytes)blog-6d7788c4c8-cxjxh 1m 766Miblog-6d7788c4c8-rz7rt 55m 854Miblog-6d7788c4c8-xbtrh 102m 863Mi

author: brucehoult
author_rank: Super Contributor
timestamp: April 01, 2025, 12:58:08 am
content: Quote from: tggzzz on March 31, 2025, 01:30:59 pmThat's more a description of very early minimal as-cheap-as-possible computers, especially mini-computers such as the DEC PDP-8 and DG Nova.RISC processors such as MIPS or RISC-V get more flexibility and more powerful instructions with better code density by having a small number of different instruction formats with different subsets of the possible fields in them.e.g. in RISC-V RV32I register-to-register arithmetic instructions have rs1, rs2, rd and 4 bits selecting the exact operation ("func3" plus SUB and SRA use bit 30 (part of "funct7") to distinguish them from ADD and SRL.Arithmetic with a constant and load instructions and jump-and-link-register have rs1, rd, a 12 bit immediate, and func3.Conditional branches and store instructions have rs1, rs2, a 12 bit immediate, and funct3.JAL, LUI, and AUIPC have rd and a 20 bit immediate.So an RV32I instruction decoder expands those formats from 32 bits into rs1, rs2, rd, a 32 bit constant, and funct4 which is 51 bits in total, plus some 1 bit control signals such as isLoad, isStore, isALUreg, isALUimm, isAUIPC, isLUI, isBranch, isJAL, isJALR. So that's 60 bits total per instruction going through the CPU pipeline.There might be a few more convenience signals such asisALU = isALUreg | isALUimmjust to save an OR gate in multiple places later, but that's basically the size of it.Youcouldbuild a CPU that stores programs as these 60 bit pre-decoded instructions in RAM instead of the actual 32 bit instructions as a cost, obviously, of making programs almost twice as large.But this decoding from 32 bits to 60 bits is pretty trivial stuff that doesn't take many gates or much time.If you have your program and data in different memory banks (Harvard architecture) and the registers and RAMs have asynchronous reads then you can make a RV32I CPU that executes one instruction per clock cycle without any microcode or pipelining, just as pure data flow from gate to gate to gate:PC -> program RAM/ROM -> instruction decode -> read rs1 and rs2 from register file -> ALU -> (RAM loadORpass through) -> register file write ->CLOCKin parallel: (PC+4ORPC+constantORrs1+constant) -> PCLoad and store can both use the ALU to add rs1 and constant exactly the same as an ADD, feeding the result to the RAM as an address. Store also sends rs2 to the RAM.At each clock pulse you're just writing the newly-calculated values into PC, optionally registers, optionally RAM[rs1+constant]. After that you simply wait long enough for all the values to percolate through the circuits before the next clock pulse."All microcontroller instructions are actually interpreted, including RISC instructions."You have to interpret (find the meaning) each instruction, but with an ISA as simple as RV32I you are not in any sense running an interpreter in the sense of a step by step microprogram.

author: brucehoult
author_rank: Super Contributor
timestamp: April 01, 2025, 01:18:43 am
content: Quote from: Picuino on March 31, 2025, 03:00:11 pmI personally wrote such stores, back in the mid to late 90s.I had a client that was an advertising company. They started to offer their clients the service of making web sites for them, which they ran on a Mac in their office, running (of course at that time) MacOS 7 or 8.The web server, WebSTAR (https://en.wikipedia.org/wiki/WebSTAR), supported CGIs via loading C/C++ shared libraries. When they needed something more than static HTML they got me to write plug-ins for them.I wrote things such as mortgage calculators, shopping baskets, user authorisation, templating calculated or database values into HTML ... all in C++.Once you have a set of useful library functions it doesn't really take any more time to write than doing it in Javascript or PHP or Python. Longer, but not twice as long. And it runs like a scalded cat.

author: radiolistener
author_rank: Super Contributor
timestamp: April 01, 2025, 02:58:35 am
content: Quote from: shapirus on March 31, 2025, 07:29:05 pmThe difference in memory consumption between managed and native languages can indeed be significant. However, with managed languages, the situation is more nuanced. Not all of the memory they allocate is actively used - managed runtimes often preallocate and retain memory to optimize future allocations. If the system starts running low on memory, they can release unused portions back to the OS. This behavior can sometimes give the impression of excessive memory usage, even when actual consumption is lower than it appears.Just ran a simple prime number search test out of curiosity, comparing the performance of C, C#, Java, and Python on Linux x64. The difference between C, C#, and Java was less than 4%. However, Python was 23.95 times slower. This is sad for Python, that it still so slow and don't use JIT.

author: shapirus
author_rank: Super Contributor
timestamp: April 01, 2025, 06:05:31 am
content: Quote from: radiolistener on April 01, 2025, 02:58:35 amNo that's not how it works, not in all cases, at least.Yes it works like that with page cache. When there is memory pressure, page cache data can be dropped by the system and memory reclaimed. This happens transparently to the processes (aside from being able to watch the respective metrics), it's handled by the system.But if a process does a malloc() call and writes to the allocated block, then the memory pages which were written to will stay marked as used (RSS) and unavailable to other processes and will not be freed under any circumstances until the process itself calls a free(), exits, or the OOM killer terminates it.RSS size is what was reported in the resource usage snippet that I quoted in my previous post, so that's unfreeable memory.Thus this allocated, initialized, but not actively used (or otherwise -- it doesn't matter) memory is a problem. These processes occupy server resources which become unavailable to other processes.That's how it works on Linux. I don't know about other systems.p.s. that damn wordpress in the example I showed is not only growing huge, but it's also growing seemingly indefinitely (which is a form of a memory leak) until it is restarted. It needs memory cgroup limits and a restart cron job to be set. What a steaming pile of turd. Not unexpectedly: much of what is written in PHP is the same: the language itself seems to encourage poor programming practices and techniques and attracts those who should not be allowed to come close to a computer. Alas, it has business importance, so it has to be accepted and worked around.

author: Picuino
author_rank: Super Contributor
timestamp: April 01, 2025, 07:12:01 am
content: The web world is crazy. All the popular CMS use slow interpreted languages!!!https://en.wikipedia.org/wiki/List_of_content_management_systemsProbably doing the logic of a CMS is not the same as calculating prime numbers and has different needs that we do not know about.

author: tggzzz
author_rank: Super Contributor
timestamp: April 01, 2025, 08:59:37 am
content: Quote from: Picuino on April 01, 2025, 07:12:01 amSome back-of-the envelope figures for how many clock periods an access takes...L1 cache reference 0.5 nsBranch mispredict 5 nsL2 cache reference 7 nsMutex lock/unlock 100 nsMain memory reference 100 nsCompress 1K bytes with Zippy 10,000 nsSend 2K bytes over 1 Gbps network 20,000 nsRead 1 MB sequentially from memory 250,000 nsRound trip within same datacenter 500,000 nsDisk seek 10,000,000 nsRead 1 MB sequentially from network 10,000,000 nsRead 1 MB sequentially from disk 30,000,000 nsA principal CMS function is to interact with the client and read/write to disk, frequently in a network attached storage box.The read/write would take 20,000,000-30,000,000ns.Working out what to read/write will be much much shorter, so "losing" a factor of 10 in that bit's performance won't even register.Yes, that is very simplistic, but that's all it needs to be

author: tggzzz
author_rank: Super Contributor
timestamp: April 01, 2025, 09:17:56 am
content: Quote from: brucehoult on April 01, 2025, 01:18:43 amI (with one other techie) too wrote a web store and fulfilment system in the late 90s, when the concepts were so novel that it won a Financial Times prize. It was written in Java, and worked very well, thank you.A few years later I wrote a telecom event processing system in Java. The Java version was a single Unix process, whereas the older C version waslotsof Unix processes running on a PA-RISC. People weregobsmackedat the performance of the Java version on PA-RISC,plusat the low hardware cost on Sun Niagara T-series processors. It was so good that, completely unexpectedly, a partner decided to buy rights to use the execution engine.The reasons are many, but includereduced cache (L1/2/3) thrashing due to the JVMinvisiblyoptimising cache executionreduced TLB/page swap thrashing due to it being a single processreduced inter-process communicationusing decent modern algorithms made practical by using a decent modern languagelibraries reflecting lessons learned from many walks of life over many decades (C and especially C++ have traditionally been too parochial, due to arrogantly presuming They Know Best)

author: Picuino
author_rank: Super Contributor
timestamp: April 01, 2025, 09:18:25 am
content: Actually several CMSs use Java, which I'm not sure is an interpreted language. Its performance has surprised me quite a bit by how good it is (only 2 times more energy and 1.9 times slower than compiled C).Considering that there are processors capable of running directly Java bytecode, maybe it should be considered a compiled language.

author: tggzzz
author_rank: Super Contributor
timestamp: April 01, 2025, 09:32:15 am
content: Quote from: Picuino on April 01, 2025, 09:18:25 amSuch Java bytecode processors were a dead end, and can be ignored. I learned that lesson (different language!) back in the 1980s, having first seen it in the 70sStrictly speaking Java is interpreted bytecode, but it avoids repeated interpretations using JIT (mid80s technology used in Java from mid 90s onwards). It also further invisibly optimises the code and memory access patterns based on what the code isactuallydoing at runtime rather than what the compile can guess itmightbe doing (mid90s technology used in Java from the early 00s).In contrast for anotherdecadethe C/C++ world was still fantasising that it didn't need a memory model - and that caused applications to be implemented in a highly suboptimal fashion.Too many people base their (lack of) understanding of modern languages on things they were taught decades ago in "computer 101". GC == reference counting == stop the world pauses is a classic example of that (hasn't been true since the late 80s!)

author: brucehoult
author_rank: Super Contributor
timestamp: April 01, 2025, 10:12:44 am
content: Quote from: Picuino on April 01, 2025, 09:18:25 amLANGUAGES are neither compiled nor interpreted. Only IMPLEMENTATIONS are.QuoteAny such processors are very slow.At one time when Java apps were first becoming very popular on mobile phones Arm added an instruction BXJ "interpret the byte pointed to by LR as a Java bytecode" Register r5 contains a pointer to a 1 KB table of 256 pointers to routines that handle each bytecode 0..255 if the particular CPU you are running on does not implement a given bytecode.Some CPUs at one time e.g. ARM926EJ-S actually implemented some unknown subset of bytecodes in hardware.But, by the time the chip got to market, Java JIT technology had improved enough that using BXJ to change to Jazelle mode was slower.So all modern Arm CPUs are believed to implement BXJ to simply call the subroutine table for all JVM instructions.

author: madires
author_rank: Super Contributor
timestamp: April 01, 2025, 10:48:23 am
content: Quote from: Picuino on April 01, 2025, 07:12:01 amThey prefer the ease of changing and modifiying things over resource conservation. The drawback is that their users need to throw in more CPUs and RAM. Another issue is security. PHP, tons of add-ons and what have you are a security nightmare. From my experience, the time saved in programming in PHP you have to waste for keeping everyting up-to-date (possibly even more time).

author: tggzzz
author_rank: Super Contributor
timestamp: April 01, 2025, 10:52:31 am
content: Quote from: brucehoult on April 01, 2025, 10:12:44 amThey are all interpreted by hardware

author: radiolistener
author_rank: Super Contributor
timestamp: April 02, 2025, 09:08:50 pm
content: Quote from: Picuino on April 01, 2025, 09:18:25 amModern runtime environments for Java and C# uses Just-In-Time (JIT) compilation, which translates bytecode into native machine code at runtime. Additionally, they offer Ahead-Of-Time (AOT) compilation, allowing bytecode to be precompiled into a native executable. When executing a precompiled application, the runtime verifies whether the bytecode has changed since compilation. If it remains unchanged, the precompiled native code is executed directly. Otherwise, the runtime may either fall back to JIT compilation or produce an error, depending on the configuration.Today, many programming languages, including JavaScript, use JIT compilation, so it is incorrect to call them interpreted. JIT-compiled languages are also compiled, but the translation into machine instructions happens at runtime on the target system rather than during development. This allows for optimizations tailored to the specific processor executing the code. Unlike the classic C compilation, where the compiler must generate generic code to support multiple processor architectures, a JIT compiler can adapt the instructions in real time, optimizing execution based on the actual hardware.

author: tggzzz
author_rank: Super Contributor
timestamp: April 02, 2025, 09:28:17 pm
content: Quote from: radiolistener on April 02, 2025, 09:08:50 pmJava haslonghad an extra technique, in its HotSpot compiler. HotSpot is effectively profile based optimisation done automatically and concurrently while the program is executing.It makes optimizations that are impossible for simple JITters and AoT compilers.