Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday November 20 2021, @10:03PM   Printer-friendly
from the is-it-cost-effective dept.

This paper is from 2017, however, I found it interesting and thought our community would also find this worthy of discussion ...

Have you ever wondered if there is a correlation between a computer's energy consumption and the choice of programming languages? Well, a group Portuguese university researchers did and set out to quantify it. Their 2017 research paper entitled Energy Efficiency across Programming Languages / How Do Energy, Time, and Memory Relate? may have escaped your attention, as it did ours.

The team used a collection of ten standard algorithms from the Computer Language Benchmarks Game project (formerly known as The Great Computer Language Shootout) as the basis for their evaluations.

Last year they updated the functional language results, and all the setups, benchmarks, and collected data can be found here. Check out the paper for more details. Have your choice of programming language ever been influenced by energy consumption?

hackaday.com


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1) 2
  • (Score: -1, Troll) by Anonymous Coward on Saturday November 20 2021, @10:18PM (1 child)

    by Anonymous Coward on Saturday November 20 2021, @10:18PM (#1198160)

    You can see them when you're driving...

    • (Score: -1, Offtopic) by Anonymous Coward on Saturday November 20 2021, @10:48PM

      by Anonymous Coward on Saturday November 20 2021, @10:48PM (#1198173)

      aristarchus can't see to drive at night, and hasn't been able to for decades

  • (Score: 3, Insightful) by Anonymous Coward on Saturday November 20 2021, @10:24PM (35 children)

    by Anonymous Coward on Saturday November 20 2021, @10:24PM (#1198163)

    Another worthless comparison.

    There is one 1 green language. Native assembler period.

    C is waste of time unless using PDO-11 that directly supports 1/2 of items addressing base functionas. C was written to help migrate a ASM to another system.

    • (Score: 4, Interesting) by Anonymous Coward on Saturday November 20 2021, @10:42PM (14 children)

      by Anonymous Coward on Saturday November 20 2021, @10:42PM (#1198169)

      I disagree, and your post is a great example of a logical fallacy that I don't know the name of (other than "sweeping generalizations stated as absolute all-encompassing truth").

      Native assembler has the potential to be more efficient, but that is very dependent on the programmer's ability.

      C compiler optimizations will often, maybe almost always, yield better code, esp. for bigger complex projects.

      Years ago I learned to have the compiler spit out the assembler code that I (and others) then examined, made some C changes, compiled again, etc., and got the best results.

      • (Score: 2, Interesting) by Anonymous Coward on Sunday November 21 2021, @12:35AM (10 children)

        by Anonymous Coward on Sunday November 21 2021, @12:35AM (#1198195)
        And yet when I benchmarked hand-written assembly compared to c for i/o, my assembler was between 10 and 200x faster. Maybe you need to try harder, and learn how to write assembler from scratch instead of just polishing compiled c output. Because they're NOT the same thing.

        but as expected, java is shit in comparison to either. DannyB is gonna be butthurt. Why this is a surprise to anyone but fanbois is beyond me.

        • (Score: 2, Insightful) by Anonymous Coward on Sunday November 21 2021, @01:09AM (3 children)

          by Anonymous Coward on Sunday November 21 2021, @01:09AM (#1198202)

          Oh, so 1 example means that all examples will follow?

          Sounds like you're a great programmer, but evidently and oddly logical thought isn't a requirement for good programmers.

          Maybe you need to try harder, and learn how to write assembler from scratch instead of just polishing compiled c output.

          Again with the logical fallacy. You need to try harder and learn about business efficiency and productivity.

          • (Score: 1, Touché) by Anonymous Coward on Sunday November 21 2021, @01:24AM

            by Anonymous Coward on Sunday November 21 2021, @01:24AM (#1198206)
            --

            Web servers (cloud shit) are examples where business efficiency is totally ignored - repeatedly running the same inefficient code rather than spending the money up front to convert it to c. Maybe they could avoid bullshit like buying carbon offsets if they worked on making code more energy efficient. Fucking MBAs gotta MBA I guess , making shit up to justify their ignorance.

            code reuse is a thing for c and asm, not just perl and javascript and java and other energy hogs.

          • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @09:05PM

            by Anonymous Coward on Sunday November 21 2021, @09:05PM (#1198411)

            Generally.

          • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @03:01AM

            by Anonymous Coward on Tuesday November 23 2021, @03:01AM (#1198795)

            ...try harder and learn about business efficiency and productivity.

            Say you spend a day optimizing something, and that will save every user one second every time they perform some operation. It won't sell any more products for you, so... meh.

        • (Score: 5, Informative) by sjames on Sunday November 21 2021, @06:43AM (3 children)

          by sjames (2882) on Sunday November 21 2021, @06:43AM (#1198266) Journal

          Or perhaps you need to get a better C compiler and learn how to use -O

          • (Score: 2, Insightful) by Anonymous Coward on Sunday November 21 2021, @02:10PM (2 children)

            by Anonymous Coward on Sunday November 21 2021, @02:10PM (#1198319)
            Even the most ptimized c code still benefits from embedded assembler; so compilers have known limitations. So take your snark and shove it.
            • (Score: 4, Insightful) by sjames on Sunday November 21 2021, @07:33PM

              by sjames (2882) on Sunday November 21 2021, @07:33PM (#1198383) Journal

              It's exceedingly rare and very well into diminishing returns. The best use of inline assembler is for special cases such as using the underlying machine's atomic operations or unconventional access to hardware registers.

              When used, it should be well isolated and modularized to cause as little porting issues as possible.

              For example, don't throw inline assembly in the middle of a large function, put it in a function declared inline in a source file with the other inline functions defined in assembly.

            • (Score: 2, Insightful) by Anonymous Coward on Monday November 22 2021, @05:03AM

              by Anonymous Coward on Monday November 22 2021, @05:03AM (#1198503)

              And what do you do if you need the code to work on different computers? There's a reason why everything isn't written in assembly, beyond just the difficulty in doing so. Assembly isn't portable and tends to be used for portions of the code where you do need the extra efficiency. But, that bit of code is guaranteed to not be portable and will require rewriting for every platform and sometimes just because the architecture has changed.

        • (Score: 3, Insightful) by DannyB on Monday November 22 2021, @03:36PM

          by DannyB (5839) Subscriber Badge on Monday November 22 2021, @03:36PM (#1198581) Journal

          as expected, java is shit in comparison to either [C or assembler]. DannyB is gonna be butthurt.

          No. Not butthurt at all.

          Danny's Inciteful Observation: If there were one perfect language for all uses we would all already be using it universally.

          I have no problem acknowledging that assembler and maybe C are the most efficient ways possible to program a processor.

          Now ask yourself this: why isn't everyone using assembly language then? Or C?

          I would go back to "Danny's Inciteful Observation" above. Maybe "perfection" or more simply, goals to be achieved are in more than one dimension. You focus on two dimensions: energy efficiency, and speed. These are important. But there are others.

          An inciteful observation: Economic efficiency is another important metric to businesses. Developer efficiency is another. Time to market is another core metric.

          A highly inciteful remark: If I can use Java and beat my C using competitor to market by one year, and beat my Assembler using competitor to market by five years, then my manager and I will laugh all the way to the bank. And they will be watching us making money while bragging about how fast and efficient their choice of languages are.

          Now don't get me wrong. There are absolutely applications where every cpu cycle and every byte and every watt counts.

          Too bad there isn't an Inciteful mod.

          --
          People today are educated enough to repeat what they are taught but not to question what they are taught.
        • (Score: 0) by Anonymous Coward on Monday November 22 2021, @09:46PM

          by Anonymous Coward on Monday November 22 2021, @09:46PM (#1198693)

          I mean, I am a Python fanboy, but I expected that Python would be near the bottom of the list in all of these, runtime efficiency/speed is not the reason you use Python. I would think Java is the same, though, I honestly don't know why people use Java.

      • (Score: 2) by mcgrew on Sunday November 21 2021, @09:35PM (2 children)

        by mcgrew (701) <publish@mcgrewbooks.com> on Sunday November 21 2021, @09:35PM (#1198421) Homepage Journal

        Assemblers are faster and far more compact than compilers. And write much smaller code.

        --
        mcgrewbooks.com mcgrew.info nooze.org
        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @10:45PM

          by Anonymous Coward on Sunday November 21 2021, @10:45PM (#1198438)

          That's like saying that electric typewriters make better novels than manual typewriters.

        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @10:46PM

          by Anonymous Coward on Sunday November 21 2021, @10:46PM (#1198439)

          Assemblers are faster and far more compact than compilers. And write much smaller code.

          "It's a poor craftsman who blames his tools."

          Assembler is only as good as the person coding it. Poor coders can easily produce large, inefficient assembler code; good coders can produce tight, efficient code, whether assembler or compiled. Compilers are only as good as their optimizations.

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @06:16AM

      by Anonymous Coward on Sunday November 21 2021, @06:16AM (#1198262)

      You haven't seen my attempts at assembler, good sir.

    • (Score: 5, Insightful) by maxwell demon on Sunday November 21 2021, @06:46AM (5 children)

      by maxwell demon (1608) on Sunday November 21 2021, @06:46AM (#1198267) Journal

      No, native assembler still wastes energy in the translation process. Native machine code is the only green language.

      --
      The Tao of math: The numbers you can count are not the real numbers.
      • (Score: 1, Insightful) by Anonymous Coward on Sunday November 21 2021, @10:38PM

        by Anonymous Coward on Sunday November 21 2021, @10:38PM (#1198433)

        Sigh. The natives are restless.

        Assembler is a high-level representation of CPU instructions.

        Yeah, you probably code by stuffing bits into micro-ops.

      • (Score: 3, Interesting) by sgleysti on Sunday November 21 2021, @10:40PM (3 children)

        by sgleysti (56) Subscriber Badge on Sunday November 21 2021, @10:40PM (#1198435)

        Native machine code is the most green in terms of CPU usage because it is the most rare :)

        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @11:02PM (2 children)

          by Anonymous Coward on Sunday November 21 2021, @11:02PM (#1198443)

          And rarely well done.

          • (Score: 3, Touché) by sgleysti on Sunday November 21 2021, @11:31PM (1 child)

            by sgleysti (56) Subscriber Badge on Sunday November 21 2021, @11:31PM (#1198451)

            But who will ever know?

            • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @02:24AM

              by Anonymous Coward on Tuesday November 23 2021, @02:24AM (#1198786)

              The Task Scheduler.

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @01:30PM

      by Anonymous Coward on Sunday November 21 2021, @01:30PM (#1198314)

      Wow, someone doesn't know what they are talking about.

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @08:37PM (11 children)

      by Anonymous Coward on Sunday November 21 2021, @08:37PM (#1198405)

      There is one 1 green language. Native assembler period.

      In absolute terms, I agree, but it truly depends on who's driving. Put today's scriptkiddie behind the wheel, and you'll have to tank-up at every intersection.

      I truly can't recall the last time I heard anyone say "elegant solution." At one time, only a fraction of a percent of coders could appreciate the hardware, optimizing and instruction scheduling; with MIPS to spare and schedules to meet, can anyone even justify putting the pedal to the mettle?

      • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @09:01PM (2 children)

        by Anonymous Coward on Sunday November 21 2021, @09:01PM (#1198409)

        As I said, only a fraction of a percent could do it — and I include myself in that group — but so many of us have moved on or moved out. I think we had an appreciation for the elegance, and the passion and desire to try to master our own little corner of the art. Maybe if people again started with nothing, and worked their way up as the art developed...

        Different times; different people.

        • (Score: 2) by sgleysti on Sunday November 21 2021, @11:36PM (1 child)

          by sgleysti (56) Subscriber Badge on Sunday November 21 2021, @11:36PM (#1198452)

          I like to program 8-bit PIC microcontrollers in assembly for hobby projects. It's really fun.

          Most recent solution that I was proud of was implementing a state machine with a branch relative instruction to the section of code that handles the particular state and making the value of the state variable the relative address offset from the branch point to the associated section of code.

          • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @02:47AM

            by Anonymous Coward on Tuesday November 23 2021, @02:47AM (#1198793)

            Embedded stuff is surely an exciting place to immerse oneself in the intricacies of the art — end up with less code at the end of the day than when you started, and be proud of the fact. Platform independence is a high aspiration, but in practice there aren't that many platforms, and you'd be well off first understanding what's under the hood of the one you are passionate about.

      • (Score: 0) by Anonymous Coward on Monday November 22 2021, @05:57PM (7 children)

        by Anonymous Coward on Monday November 22 2021, @05:57PM (#1198616)

        There wasn't a soul on this place who mentioned optimizing, profiling, bottlenecks, whatever. Only one true language shall rule them all! Nothing showing any insight. Still a fraction of a percent. Having been banned from this place all weekend for too many for pro-American posts, I don't feel compelled to care about this place.

        • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @12:56AM (6 children)

          by Anonymous Coward on Tuesday November 23 2021, @12:56AM (#1198762)

          APK did on profiling and how to overcome bottlenecks on data type size and memory placement for more speed and he did so using Object Pascal proving it's superior in speed to all the rest and safer than C is. His methods are old school and clever to make Pascal string handling that's safer even faster than C strings are that are dangerous due to buffer overflow exploits on their null terimination weakness. Take a re-read here since you obviously missed it https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198434#commentwrap [soylentnews.org]

          • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @02:08AM (5 children)

            by Anonymous Coward on Tuesday November 23 2021, @02:08AM (#1198780)

            Traditional Pascal strings are pretty primitive, which makes them easy to maintain... though primitive. Even BASIC string headers of the era were more flexible.

            • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @05:22PM (4 children)

              by Anonymous Coward on Tuesday November 23 2021, @05:22PM (#1198947)

              See my subject-line above: Primitive? You mean LESS COMPLEXITY SUPERIOR (superior warrior) don't you??

              I.E./E.G. - By incorporating string length into the structures of even objects you avoid C null-terminated buffer overflows AND YOU GO FASTER than C++ does due to the added complexity in stdstring having to do length tests to avoid the C issue (I go past that to exceed C even by determining correct var type masks in shortstrings & it apples in hosts files example I noted, 255 char max len + summoning by register passed function/proc pointers to marshall them FASTER too (& I used to do inline asm for more in Delphi 7 but Delphi XE didn't have them SO I went to straight Object Pascal again + did the 'tricks' I note above to get more out of what's already KICK ASS better)!

              DISCLAIMER: HOWEVER - 1 C compiler I am FAIRLY SURE overcomes the speed hits of C++ and the null-terminated string weakness of straight C (& that compiler's not "pure C" anymore either) is Apple's OBJECTTIVE C !

              IMITATION is TRULY the sincerest form of FLATTERY!

              (I know since my nephew is a 10 yrs. man over @ Apple who, lol, KEEPS OFFERING ME WORK THERE as a consultant since if/when he has hassles, we "speek geek" about it over the phone (no specifics on the project itself, just theoreticals on "CONCEPTUAL What-IF" scenarios, & approaches I'd use to overcome them - bounce it off others to get NEW ideas really, or possibles)).

              * SIMPLE and SOUND thinking 5 moves AHEAD recognizing & STEALING already known GREAT Pascal ENGINEERING = GOOD ENGINEERING - that's Apple, lol!

              (less moving parts generally means less breakdown OR OVERHEADS - see C++ above slowdown & see Apple rebuilding their stringlibs obviously into PASCAL STRINGS - same structure really, a SUPERIOR one - why I used hosts? Same idea - less overheads & moving parts (as the TCP/IP stack already provides a built-in filtering mechanism natively - EVEN FIREWALLS can't claim that as they need a FILTERING layered overhead driver to even work)).

              "God don't build no JUNK" & DOES IT SIMPLE - so do I as (sarcasm but fits here in a big way since I use hosts files as an example of applied thought) "the LORD of HOSTS" (wish I was THAT good).

              Lastly - quoting the GREAT legendary film "I am LEGEND"'s intro with Dr. Alice Krippen? TAKE SOMETHING DESIGNED BY NATURE & REPROGRAM IT TO WORK FOR THE BODY rather than AGAINST IT - which is what I did.

              AND quoting it again (Sonia Braga to Will Smith) "It's working... NEVILLE: It's WORKING!" more efficiently by using a SAFER & FASTER (I make it even faster as I noted along with others noticing now) tool in Object Pascal!

              APK

              P.S.=> My "CODE-FU Kung Fu"? The SUPERIOR WARRIOR uses the best means & systems of thought - that clearly IS the Pascal string structure - Great artists don't just COPY, they STEAL (& Apple via Objective C, has - right move in this case but NO ORIGINAL THOUGHT existed other than SUPERIOR safer & faster Pascal string structs)... apk

              • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @05:46PM (3 children)

                by Anonymous Coward on Tuesday November 23 2021, @05:46PM (#1198955)

                Well, I've had lunch with Gary "Radar" Burghoff! So there!

                • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @07:37PM (2 children)

                  by Anonymous Coward on Tuesday November 23 2021, @07:37PM (#1198992)

                  See my subject-line above & ever heard of overhead cams in cars? They are a BETTER less moving parts design vs. the classic original pushrod design!

                  How/Why??

                  1st by removing what went from circular to linear to circular (crank to pushrods to camshaft(s)) you GAIN roughly 20% horsepower (loss occurs in physics when you go from linear to circular & vice-a-versa in machinery)...

                  * Same idea here really that I extolled on motors now goes for coding too - Albeit this time in more "mundane terms" AND A TOPIC most will "get" since imo, most dudes are "motorheads" @ heart (I could use classic literature OR scripture but this cuts the mustard).

                  Like motors & REAL WORLD object physics? The concept is the same & also extends to programming...

                  APK

                  P.S.=> Addendum to my original post reply to you on "primitive being GOOD" less moving parts in coding per https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198947#commentwrap [soylentnews.org] as the concept IS very similar in both... apk

                  • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @07:40PM (1 child)

                    by Anonymous Coward on Tuesday November 23 2021, @07:40PM (#1198994)

                    What a Wankel!

                    • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @07:47PM

                      by Anonymous Coward on Tuesday November 23 2021, @07:47PM (#1198998)

                      See my subject-line above - Wankel's ROTARY ENGINE iirc, only has 2 moving parts really in bearings on the ends of the shaft for firing the cylinders BUT he also got the design pattern largely from the OLD biplaines of WWI etc.!

                      * NO REAL ORIGINAL THOUGHT but a GOOD SOLID APPLICATION of the concept I extolled for coding & used motor/car analogies for in my example (pushrods designs vs. overhead cams) & YES YOU GOT IT (or you wouldn't have used Wankel).

                      APK

                      P.S.=> Very GOOD "danielsan", lol... apk

  • (Score: 4, Touché) by Runaway1956 on Saturday November 20 2021, @10:36PM (51 children)

    by Runaway1956 (2926) Subscriber Badge on Saturday November 20 2021, @10:36PM (#1198165) Journal

    We, meaning non-programmers, should search out programs written in C or C++? We should avoid programs written in php etc? I've never used this site for that purpose, but I suppose it could help - https://alternativeto.net/ [alternativeto.net]

    We already know to avoid javascript. Java doesn't look as bad as I expected. Ruby, Lua, Python, and Perl all look bad - unless I'm reading the comparisons upside down.

    Seriously, give us something useful for non-programmers here!

    • (Score: 3, Disagree) by takyon on Saturday November 20 2021, @10:38PM (20 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Saturday November 20 2021, @10:38PM (#1198166) Journal

      None of it matters. A new computer will be 50% more energy efficient in a couple of years.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 5, Insightful) by Runaway1956 on Saturday November 20 2021, @10:47PM (3 children)

        by Runaway1956 (2926) Subscriber Badge on Saturday November 20 2021, @10:47PM (#1198172) Journal

        That's not much of an answer. We are already hearing from Muckrosloth that 80% or more modern computers aren't good enough to run Windows 11. And, 100% of older computers are just junk. Microsoft may be the worst offender in that respect, but each generation of Linux follows a similar course, even if years behind Microsoft. It's too much trouble, but I'd like to dig out an old 386, and see how well various distros run on it. Apple seems to have remained pretty stable in that respect for years, but they've created their own silicon, which seems to run circles around Intel's recent offerings. (I can't really vouch for that, I don't have any Apple chips to play with.)

        So, for all the millions of computer users out there, is it safe to assume that we want C and C++ programs for our aging equipment?

        • (Score: 2, Insightful) by Anonymous Coward on Sunday November 21 2021, @01:12AM

          by Anonymous Coward on Sunday November 21 2021, @01:12AM (#1198204)
          I hy not? Those old programs still run just fine, don't phone home, and can't be canceled when a key server goes down. And itf you can dig up a c compiler for them, you can scratch your own itch without depending on 1,000 libraries from questionable sources , and learn the art.
        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @04:16AM

          by Anonymous Coward on Sunday November 21 2021, @04:16AM (#1198236)

          That's not much of an answer.

          It is the complete answer as blunt as we like from him. Your home and small business server will run off a Raspberry Pi, just use software written in systems languages. What more do you need? Your games, protein folding and SETI bullshit runs off a GPU. It uses OpenCL or CUDA and consumes vastly more energy than C programs because GPU's already dominate energy consumption for demanding compute.

        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @11:08PM

          by Anonymous Coward on Sunday November 21 2021, @11:08PM (#1198445)

          Apple seems to have remained pretty stable in that respect for years,

          Ha! Apple has made their software more hardware-demanding with every release. OS X 10.6 was slick on a 4GB C2D or C2Q machine; 10.9 was noticeably slow; 10.11 was a slug, even if RAM was increased. I've had to retire several perfectly good, fully functional computers because the newest OS releases were too bloated and support was dropped for OS versions that worked.

          Not that Windows is any better, but Apple shouldn't be held up as virtuous for something they don't do any better than Microsoft.

          We are already hearing from Muckrosloth that 80% or more modern computers aren't good enough to run Windows 11.

          We already know that's a bullsh!t excuse Microsoft is using to force people to buy new hardware so they can sell new OS licenses. The OEMs win with hardware sales and Microsoft wins by selling them the new OS. Nobody loses. Except us. Especially when Win11 is clearly a turd, like WinME, Vista, and Win8. Wait for them to polish it. Maybe they'll reduce the unnecessarily onerous hardware requirements by then.

      • (Score: 3, Touché) by krishnoid on Sunday November 21 2021, @12:20AM

        by krishnoid (1156) on Sunday November 21 2021, @12:20AM (#1198189)

        Until there's a security breach. I wonder what the carbon footprint of an exploited stack overflow bug looks like.

        Also, how about a just-in-time compiler? Say it translates to 10x the number of lines of hand-coded C that does the same thing, what's the corresponding multiplier for the actual energy consumed?

      • (Score: 4, Insightful) by Anonymous Coward on Sunday November 21 2021, @12:33AM

        by Anonymous Coward on Sunday November 21 2021, @12:33AM (#1198193)

        But web-dev crap will be 500% more inefficient in by then so it's a net loss.

      • (Score: 1, Interesting) by Anonymous Coward on Sunday November 21 2021, @12:41AM (2 children)

        by Anonymous Coward on Sunday November 21 2021, @12:41AM (#1198196)

        My kid's first question was, "are they using optimized libraries?" and "were Python etc jit'd?" Which only makes the question more difficult to frame, and the answers more complicated. If I don't know the right questions, I probably won't get the right answers.

        • (Score: -1, Flamebait) by Anonymous Coward on Sunday November 21 2021, @01:08AM

          by Anonymous Coward on Sunday November 21 2021, @01:08AM (#1198201)
          Jits are still closer than real raw compiled code, despite what everry fanboi says. And the results are clearly laid out here. This jit shit needs to die. Learn to cod with a real language.
        • (Score: 0) by Anonymous Coward on Monday November 22 2021, @05:05AM

          by Anonymous Coward on Monday November 22 2021, @05:05AM (#1198505)

          Python has terrible methane emissions due to it being mostly cow shit with a little bit of cow piss.

      • (Score: 1, Insightful) by Anonymous Coward on Sunday November 21 2021, @01:06AM (10 children)

        by Anonymous Coward on Sunday November 21 2021, @01:06AM (#1198200)
        All those servers running interpreted code would save lots of money and energy if they switched to c. Of course that would require better coders … something not available with code by google or stackoverflow moneys who claim to be full stack developers.

        And no, java doesn't count - as we can see from the results. But then again, it's still running in a byte code interpreter, not a real compiled code implementation.

        • (Score: 1, Insightful) by Anonymous Coward on Sunday November 21 2021, @02:07AM (6 children)

          by Anonymous Coward on Sunday November 21 2021, @02:07AM (#1198210)

          Rust, swift, C++, Objective C and others compile down to the same LLVM optimisations.

          There's barely any reason to choose C over any other such compiled language.

          • (Score: 1, Insightful) by Anonymous Coward on Sunday November 21 2021, @04:18AM (5 children)

            by Anonymous Coward on Sunday November 21 2021, @04:18AM (#1198237)

            > There's barely any reason to choose C over any other such compiled language.

            Rust is a language for CoC suckers, it's best avoided if the aim is freedom.

            • (Score: 3, Funny) by maxwell demon on Sunday November 21 2021, @06:50AM (4 children)

              by maxwell demon (1608) on Sunday November 21 2021, @06:50AM (#1198268) Journal

              The aim of software development is to create working software.

              --
              The Tao of math: The numbers you can count are not the real numbers.
              • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @08:01PM (1 child)

                by Anonymous Coward on Sunday November 21 2021, @08:01PM (#1198393)

                That's what we USED to think.
                Diversity, Equity, and Inclusion is the goal of all organizations now. Whatever they used to accomplish pales in comparison to this critical goal. You can even ask the US armed forces.

                • (Score: 2) by maxwell demon on Sunday November 21 2021, @08:10PM

                  by maxwell demon (1608) on Sunday November 21 2021, @08:10PM (#1198396) Journal

                  So the goal is to include all language constructs equally in the program? Well, that certainly could explain the bloat in modern software. :-)

                  --
                  The Tao of math: The numbers you can count are not the real numbers.
              • (Score: 2) by sgleysti on Sunday November 21 2021, @10:43PM

                by sgleysti (56) Subscriber Badge on Sunday November 21 2021, @10:43PM (#1198437)

                I continually wonder why this aim seems so difficult to achieve.

              • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @11:07PM

                by Anonymous Coward on Sunday November 21 2021, @11:07PM (#1198444)

                And fix the bugs in the next slipstream release.

        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @02:34AM (1 child)

          by Anonymous Coward on Sunday November 21 2021, @02:34AM (#1198213)

          Not running a bytecode interpreter for frequently run code. That code (identified by profiling in the running JVM) is compiled to native code. So running Java code is a mix of interpreted and compiled on the most commonly used JVMs.

          • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @02:18PM

            by Anonymous Coward on Sunday November 21 2021, @02:18PM (#1198320)
            And that native code is still unoptimizable compared to both native c and assembler. It's one reason nobody uses the gcc java-to-c compiler.. It's not quite slow enough to finish running before the heat death of the universe, but it's an indication of the true overhead of java converted to native code - there's too much useless code to support it because you can't take the shortcuts in java that you can in c, and java single inheritance and everything is a class is a shit flawed design.
        • (Score: 1, Interesting) by Anonymous Coward on Sunday November 21 2021, @08:27PM

          by Anonymous Coward on Sunday November 21 2021, @08:27PM (#1198402)

          For any project that doesn't require maximum performance (video editing, massively parallel number crunching, etc...) time-to-market and ease of making major changes is more important than language speed. That's not a programmer problem, it's a market problem. There were undoubtedly startups trying to do what Youtube, Facebook, DropBox, Twitter, and Reddit did using C or C++, and they got beaten by people whipping together projects in Python, Ruby, or PHP - languages many orders of magnitude slower, but languages that have faster product iteration.

          That's never going to change. The problem isn't the engineers, it's the market.

    • (Score: 4, Interesting) by looorg on Saturday November 20 2021, @11:29PM (14 children)

      by looorg (578) on Saturday November 20 2021, @11:29PM (#1198178)

      I don't really know what they are going for but looking at the lists on hackaday it seems to be languages that compile are good and the others are bad. That said I don't know why they rate Pascal so highly (i didnt read the entire paper), I dont have fond memorize of it. It produced good stuff but there was so much pre-planning involved it got annoying to use or code in.

      Have your choice of programming language ever been influenced by energy consumption?

      Not in this "green" sense they are thinking or talking about here, but naturally one want things that are fast, small and efficient as far as system resources go. It's like why you quickly moved away from BASIC etc.

      • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @01:40PM (13 children)

        by Anonymous Coward on Sunday November 21 2021, @01:40PM (#1198316)

        I don't know why they rate Pascal so highly - by looorg (578) on Saturday November 20, @11:29PM (#1198178)

        Does THIS answer your question (w/ facts)? Pascal still ROCKIN' THE PLANET https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198315#commentwrap [soylentnews.org]

        * :)

        APK

        P.S.=> It ought to - facts ARE facts... apk

        • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @02:24PM (4 children)

          by Anonymous Coward on Sunday November 21 2021, @02:24PM (#1198322)
          Delphi is dead. Get over it. So was your "business ". Nobody is using your shitty host file crap. In 30 years, you couldn't even make enough money to set up a basic website to offer it, instead of spamming all over the place. 30 years of basically being unemployed except for a few side hussles in the 90s. Fucking pitiful.
          • (Score: -1, Spam) by Anonymous Coward on Sunday November 21 2021, @02:30PM

            by Anonymous Coward on Sunday November 21 2021, @02:30PM (#1198323)

            You PROJECT that YOU are unemployed & haven't accomplished a FRACTION of what I have - so much so, I haven't HAD to WORK for anyone since 2008 when I retired. Occasionally, I contract (only if the job interest me & PAYS well) but my time is mine & MY MONEY WORKS FOR ME (literally) since then.

            NOW - PROVE You've done more, earlier & better than this? apk

            See a VERY PARTIAL LIST ONLY of some of my favorites over the decades I've done well in others recognized (in publications on wares I wrote on the side of doing my day job as a professional software engineer circa 1995-2007) while MOST of you were still in diapers I wager:

            Windows NT Magazine April 1997 "BACK OFFICE PERFORMANCE" pg 61

            (For SuperSpeed.com PAID CONTRACT (wrote SuperCache 40% performance boost) & SuperDisk finalist @ MS Tech Ed 2x in a row 2000-2002 HARDEST CATEGORY: SQLServer Performance Enhancement - they ended up BUYING OUT MY SOURCECODE & they are a certified MS partner...)

            WINDOWS MAGAZINE 1997 "Top Freeware & Shareware of the Year" issue pg 210 #1 entry

            PC-WELT FEB 1998 pg 84

            WINDOWS MAGAZINE, WINTER 1998 pg 92 MUST HAVE WARE

            PC-WELT FEB 1999 - pg 83

            CHIP Magazine 7/99 - pg 100

            GERMAN PC BOOK Data Becker "PC Aufrusten und Repairen" 2000

            HOT SHAREWARE #46 issue pg. 54 2001

            UltraDefrag64 Process Priority Control credited by lead devs of it in the programs credits section (for use in not only UPPING cpu priority but ALSO downing it for background operations)

            Paid for article @ PCPitstop in 2008

            * ... & of course, my A P K H o s t s F i l e E n g i n e which has over 1/2 million users going strong & was recommended by Malwarebytes' Mr. Steven Burn

            ---

            * :)

            (Before ANY of you judges me on ANY account? Prove to me you have done MORE, BETTER & EARLIER than that list yourselves - "so JUDGE NOT, lest ye BE judged"...)

            APK

            P.S.=> That list's not including the fact that INDUSTRIAL WARES I've done are STILL to this day running entire companies' lifeblood from sales to shop floor to reports to government etc. to this very day from the 1990's in my "day job" as a software engineer for decades, no problem, bulletproof & bugfree (afaik & I do check periodically over the years for the resume (not that I need to anymore, I did well enough to retire @ 47 yrs. of age back in 2007 - occasionally I contracted IF a job interested me & PAID well too of course, but since 2016 or so? I haven't had to work for ANYONE but ME since my MONEY WORKS FOR ME, not the other way around))... apk

          • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @02:50PM

            by Anonymous Coward on Sunday November 21 2021, @02:50PM (#1198326)

            Always a pleasue to see APK make jealous failures like you project your issues onto him and to have him shoot you down into silence against facts or challenges he puts out to you https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198323#commentwrap [soylentnews.org] that a "ne'er-do-well" like you could never manage or meet.

            If anyone is pitiful, unemployed and broke, it is clearly you. Of course, to hide these facts, you'll down moderate APK's posts even when they are +1 informative rated currently here https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198315#commentwrap [soylentnews.org] which is something the pitiful likes of you can't manage either unless you do sockpuppets to up moderate yourself. We do know that goes on here. Your admins and owners most of all.

          • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @03:08PM

            by Anonymous Coward on Sunday November 21 2021, @03:08PM (#1198331)

            Dear Jealous Troll, you should consider using AC/DC's "Shotdown in Flames" https://www.youtube.com/watch?v=UKwVvSleM6w [youtube.com] as your themesong after APK tore you up silencing you here since you can't prove you've done better or that you work or that Delphi is dead. Pascal is always in TIOBE's top 20 for 20 years strong now and did extremely well in this article's source also.

          • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @11:31PM

            by Anonymous Coward on Sunday November 21 2021, @11:31PM (#1198450)

            You PROJECT that YOU are unemployed & haven't accomplished a FRACTION of what I have - so much so, I haven't HAD to WORK for anyone since 2008 when I retired. Occasionally, I contract (only if the job interest me & PAYS well) but my time is mine & MY MONEY WORKS FOR ME (literally) since then.

            Delphi/Object Pascal's FAR from "dead" - this very article's source proves it - so does the TIOBE index (for 20++ yrs. Pascal's been there SOLID).

            So much for YOUR bs!

            My A P K Hosts File engine?? Quarter of a MILLION users++ too.

            My real business/livelyhood now (no longer coding) has done GREAT since 2001! How about yours? Not.

            NOW - PROVE You've done more, earlier & better than this VERY PARTIAL LIST ONLY of some of my favorites over the decades I've done well in others recognized (in publications on wares I wrote on the side of doing my day job as a professional software engineer circa 1995-2007) while MOST of you were still in diapers I wager:

            Windows NT Magazine April 1997 "BACK OFFICE PERFORMANCE" pg 61

            (For SuperSpeed.com PAID CONTRACT (wrote SuperCache 40% performance boost) & SuperDisk finalist @ MS Tech Ed 2x in a row 2000-2002 HARDEST CATEGORY: SQLServer Performance Enhancement - they ended up BUYING OUT MY SOURCECODE & they are a certified MS partner...)

            WINDOWS MAGAZINE 1997 "Top Freeware & Shareware of the Year" issue pg 210 #1 entry

            PC-WELT FEB 1998 pg 84

            WINDOWS MAGAZINE, WINTER 1998 pg 92 MUST HAVE WARE

            PC-WELT FEB 1999 - pg 83

            CHIP Magazine 7/99 - pg 100

            GERMAN PC BOOK Data Becker "PC Aufrusten und Repairen" 2000

            HOT SHAREWARE #46 issue pg. 54 2001

            UltraDefrag64 Process Priority Control credited by lead devs of it in the programs credits section (for use in not only UPPING cpu priority but ALSO downing it for background operations)

            Paid for article @ PCPitstop in 2008

            * ... & of course, my A P K H o s t s F i l e E n g i n e which has over 1/2 million users going strong & was recommended by Malwarebytes' Mr. Steven Burn

            ---

            * :)

            (Before ANY of you judges me on ANY account? Prove to me you have done MORE, BETTER & EARLIER than that list yourselves - "so JUDGE NOT, lest ye BE judged"...)

            APK

            P.S.=> That list's not including the fact that INDUSTRIAL WARES I've done are STILL to this day running entire companies' lifeblood from sales to shop floor to reports to government etc. to this very day from the 1990's in my "day job" as a software engineer for decades, no problem, bulletproof & bugfree (afaik & I do check periodically over the years for the resume (not that I need to anymore, I did well enough to retire @ 47 yrs. of age back in 2007 - occasionally I contracted IF a job interested me & PAID well too of course, but since 2016 or so? I haven't had to work for ANYONE but ME since my MONEY WORKS FOR ME, not the other way around))... apk

        • (Score: 2) by looorg on Monday November 22 2021, @01:34AM (1 child)

          by looorg (578) on Monday November 22 2021, @01:34AM (#1198473)

          Thanks. But not really. As noted I have not really written any Pascal, or have any or many memories of it, since Borlands Turbo Pascal (I think it was version 5 or 6? I know the box came with several big nice book and it ran under DOS). It produced nice compiled results but as I said that was probably like 25-30 years ago. If anything I would have thought that version of Pascal had fallen somewhat out of favor as a programming language. Do they even teach it anymore?

          My recollection of it was more that I did find it very odd then to write things in it and with it since it required so much pre-planning as there was the way in which things had to be written and called, you could only call on things that was written above it in the code or something such? So it was ok to write small things and such but it was annoying if things grew and changed or things had to be added later. But I don't claim any expertise really in the language. Anyhow my recollection and memory of that was that it was quite annoying compared to or if you already knew say C and some other languages. But this was very much before it eventually morphed into Delphi, or however that transformation took place.

          So in that regard I think it was more a surprise to see Pascal still on the list then anything else, not that it didn't produce good or decent results.

          • (Score: 0) by Anonymous Coward on Monday November 22 2021, @05:25PM

            by Anonymous Coward on Monday November 22 2021, @05:25PM (#1198608)

            It's pretty much like working in C/C++ really - I don't understand why you thought it was annoying since e.g. - instead of using { to start a procedure, you use begin & instead of closing your proc with} you put in end.

            Turbo Pascal (I started on version 4.5) evolved into Turbo Pascal for Windows (using the "OWL" libraries - Object Windows Lib iirc is what the acronym stood for) - & it was used in academia then but afaik in the early 2000's, that's when Java took over in academia.

            Anyhow/anyways - TP for Windows ended up as Delphi.

            What I like about it was Delphi itself was written in Delphi and as you saw in my link sourced from a competing trade magazine in VB Programmer's Journal, the performance is INCREDIBLE (especially on what every program does - math & strings, exceeding MSVC++ performance (API graphics also)).

            I.E. - You build on template forms (don't REALLY need it to be honest, but for placement of controls you might unless a form only has say, 1 button on it since IF NOT, the controls will be scrambled all over the form is my guess) like Visual Basic but you got BETTER than C++ performance.

            It was initially touted as "the VB Killer" & ended up killing even C++ in performance.

            I do understand WHY C/C++ took over - MONEY TALKS - big MS money. Plus, & THIS may sound "conspiracy theory" but, since C strings are INCREDIBLE VULNERABLE to null-terminated string BUFFER OVERFLOWS? I think it was only a SMOKESCREEN to sell "high performance" BUT with a HIGHLY HACKABLE SYSTEM - think about it - IF you were "big gov't.", wouldn't YOU want a "BACKDOOR" into everything written in the MOST PREVALENT LANGUAGE? Information IS POWER after all!

            From what I've seen & I programmed professionally as a programmer-analyst/software engineer (titles) since 1994 - whatever is taught in academia becomes "the way" even though it sucks shit (e.g. Java, very C++ like but slower & FULL OF SECURITY HOLES for like, forever, maybe a bit better now but I don't trust it myself - despite automatic "garbage cleanup" features it has that afaik, C++ is chasing as part of its future (that's going to SLOW IT DOWN even more, mark my words)). Plus, Mgt. ALSO wants to say "I headed a project in that language that is the 'latest buzzword all the cool kids are doing'" (what a FUCKING joke their world is, unless they were promoted there from formerly being a GOOD coder) too.

            Fucking politics. Kids that learn the "latest hip thing" come CHEAP too. What do they come with? Whatever academia pimps paid off by software companies like MS push on them. Fact. I saw it myself. Full OS, compilers etc. to HOOK the kids on it. Those kids also come CHEAPER by far than oldsters wtih actual HANDS ON experience. Way of the world...

            APK

            P.S.=> Lastly, Delphi or really ANY Object Pascal toolset like FreePascal & Lazarus IDE for it? It's EXCELLENT for database/information systems work - that was my "bread & butter" steady-eddy always available day-job meal ticket for decades & I've written (or co-written) GIGANTIC systems that run entire companies from production facility shop floor to sales & all else in between with it (multi-million line systems) - but I also did so in VB & C++ a few times on the last one only... apk

        • (Score: 0) by Anonymous Coward on Monday November 22 2021, @06:05PM (5 children)

          by Anonymous Coward on Monday November 22 2021, @06:05PM (#1198620)

          And "Groundhog Day" came out in 1993, but Bill Murray eventually broke free of it.

          • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @01:08AM (4 children)

            by Anonymous Coward on Tuesday November 23 2021, @01:08AM (#1198771)

            Apk provably demonstrated how much faster Pascal is in math, strings and graphics over C++ here https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198315#commentwrap [soylentnews.org] from a respected trade journal of its day and then showed how to make Pascal even faster than C is with C's dangerous null terminated buffer overflow weak strings vs Pascal's faster strings that have len incorporated into their structure so no buffer overflow exploits can be done to Pascal's stringwork. I felt he used very clever methods of using register passed procedure calls and he explained the upper limits of it on 32 bit (8 possible) and 64-bit (16 possible). This was smart of him also by using shortstring use on data that won't lose a thing since it fits there and won't be truncated all so it runs in faster local stack memory instead of slower global heap memory, and how to profile for it properly using hi resolution timers seeing that procedures need it most since they are the slowest and do the most work https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198434#commentwrap [soylentnews.org] . You shouldn't be giving anyone guff that knows those kinds of means, methods and understanding of programming. He demonstrates intelligence in planning for what tool to use and how\why and when to do so and how to get the best and even more from it when Pascal's already superior in speed and safety.

            • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @02:17AM (3 children)

              by Anonymous Coward on Tuesday November 23 2021, @02:17AM (#1198783)

              I like reminiscing, too. Reminds me of the big floating point library I did in MASM for the 80386... outperformed just about anything, in speed and size. A couple of hours later, just about every processor included a floating point unit, and I had a story, too. Now, let's do early spelling checkers...

              • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @01:32PM (2 children)

                by Anonymous Coward on Tuesday November 23 2021, @01:32PM (#1198874)

                1 big difference between your fantasyland exploits and APK is what apk spoke of he used, with the methods I distilled from his posts he stated he used, is that he has an actual program to demonstrate what he stated provably and you don't. All you have is talk and it could be pure fantasy from you. I suspect it is. A P K H o s t s F i l e E n g i n e https://www.start64.com/index.php/64-bit-software/64bit-security/5851-apk-hosts-file-engine-10-32-64-bit [start64.com] with a list of benefits in security and speed it yields that are numerous and beneficial on many levels, provably. There's your fantasyland and then there's his reality that's been widely used worldwide since the early 21st century. So what's that you said about Bill Murray since you are talking Macro Assembler use? Let's quote you from https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198620#commentwrap [soylentnews.org]

                And "Groundhog Day" came out in 1993, but Bill Murray eventually broke free of it. by Anonymous Coward on Monday November 22, @06:05PM (#1198620)

                At least APK's work survives in reality. Not fantasyland with no provable backing like you. All talk, no action. That's you.

                • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @05:26PM (1 child)

                  by Anonymous Coward on Tuesday November 23 2021, @05:26PM (#1198949)

                  I knew another a guy who caught the Y2K bug.

                  He was never the same.

                  • (Score: 0) by Anonymous Coward on Tuesday November 23 2021, @08:49PM

                    by Anonymous Coward on Tuesday November 23 2021, @08:49PM (#1199008)

                    He caught the same disease that was killing the chestnut trees.

                    - James Thurber

    • (Score: 5, Interesting) by RS3 on Saturday November 20 2021, @11:48PM (6 children)

      by RS3 (6367) on Saturday November 20 2021, @11:48PM (#1198183)

      At the risk of overstating what many here know, a CPU can only execute binary code that is specific to the CPU. Assembler is generally the lowest form of programming language- a human readable form of what the CPU understands. Most other higher-level languages are more human readable, but must be translated (compiled, or interpreted) into something the CPU can actually execute.

      https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Compiled_languages [wikipedia.org]

      https://en.wikipedia.org/wiki/Interpreter_(computing) [wikipedia.org]

      https://www.geeksforgeeks.org/difference-between-compiled-and-interpreted-language/ [geeksforgeeks.org]

      I don't have solid data, but I've always thought it was generally understood that interpreted languages are less efficient than compiled ones. Meaning, interpreted languages use more CPU cycles (and probably RAM) to do the same work of a compiled application.

      Of course that opens a big discussion involving knowing a language and how the interpreter runs it. IE, you can optimize interpreted languages. But my hunch is compiled code will still generally run faster.

      That said, some code can be run either way. BASIC is usually interpreted, but I remember long ago "c-BASIC"- compiled BASIC.

      Many interpreted languages are run by webservers through plugins. This very site runs on perl code that is executed by a webserver using a webserver plugin. Many interpreted languages also have caching functionality available so the code is interpreted once, and the resulting machine binary code is cached and run over and over (until something causes a cache flush). For php we have OPcache, memcached, and others, including ones that are specific to a platform (for example WordPress has caching plugins).

      • (Score: 2) by krishnoid on Sunday November 21 2021, @12:23AM (5 children)

        by krishnoid (1156) on Sunday November 21 2021, @12:23AM (#1198190)

        I don't have solid data, but I've always thought it was generally understood that interpreted languages are less efficient than compiled ones. Meaning, interpreted languages use more CPU cycles (and probably RAM) to do the same work of a compiled application.

        You'd think, but PyPy is (sort of) a counter-example to this [stackoverflow.com], with an extra layer of interpretation added to the scenario.

        • (Score: 2) by RS3 on Sunday November 21 2021, @01:12AM (3 children)

          by RS3 (6367) on Sunday November 21 2021, @01:12AM (#1198203)

          Thanks, that's interesting. I don't do a lot of programming right now. Would like to, certainly have messed around with Python and others. Just need a job where sw. dev. is involved...

          • (Score: 1, Informative) by Anonymous Coward on Sunday November 21 2021, @01:16AM (2 children)

            by Anonymous Coward on Sunday November 21 2021, @01:16AM (#1198205)
            and yet pyoi is still slower than c. And has just had another massive security hole in the repos.
            • (Score: 2, Insightful) by Anonymous Coward on Sunday November 21 2021, @02:17AM

              by Anonymous Coward on Sunday November 21 2021, @02:17AM (#1198211)

              Python is, in fact, the slowest of all the commonly used programming languages.
              The only way to mitigate the atrocious performance is to link to libraries that are compiled native code (pretty much written in C). Having that trick, how slow your program is turns into how much of your executing code is in the libraries versus awfully slow interpreted Python.

            • (Score: 4, Interesting) by janrinok on Sunday November 21 2021, @10:05AM

              by janrinok (52) Subscriber Badge on Sunday November 21 2021, @10:05AM (#1198301) Journal

              And if you read fully the reports that you are alluding to, you will find that many repos - not just Python - are having the same problems regarding security. This includes many of the current in-vogue must-use languages.

              Personally, although I would prefer it not to be a problem, I would rather read about repos finding and removing problem libraries than relying on a repo where the management simply haven't thought it could apply to their favourite language. At least somebody is looking for security breaches in the repo code.

        • (Score: 1, Informative) by Anonymous Coward on Sunday November 21 2021, @07:11AM

          by Anonymous Coward on Sunday November 21 2021, @07:11AM (#1198274)

          PyPy is a JIT. It will run slower than cPython until it is warm, but then it takes off. Same with most other JIT implementations of the various languages. Because the key to remember is that there is not really such thing as an "interpreted language" or "compiled language" because any language can have an interpreted implementation, a compiled implementation or something in between.

    • (Score: 4, Funny) by Anonymous Coward on Sunday November 21 2021, @12:01AM (1 child)

      by Anonymous Coward on Sunday November 21 2021, @12:01AM (#1198187)

      If javascript is the answer, then you asked a stupid question.

      • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @04:23AM

        by Anonymous Coward on Sunday November 21 2021, @04:23AM (#1198240)

        Is that the C style javascript written by programmers or the stuff written by liberal arts majors? One is clear and performs reasonably well, the other... who cares?

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @03:37PM

      by Anonymous Coward on Sunday November 21 2021, @03:37PM (#1198339)

      We already know to avoid javascript. Java doesn't look as bad as I expected. Ruby, Lua, Python, and Perl all look bad - unless I'm reading the comparisons upside down.

      TBH, Java is not too bad and of all the "scripting" or interpreted languages, Javascript is actually the most efficient. It is efficient thanks to all the effort to make it faster. Ruby, Python, etc. are all magnitude+ worse at efficiency than Javascript

      You actually see this in the paper, Table 4,

      C, Rust, C++ -- all about 1x, more or less
      Java -- 2x of C
      C#, Go -- 3x
      Javascript -- 5x
      Lua, Ruby, Python, Perl - 50-70x

      Javascript is at least in the magnitude area of compiled languages. The others, sadly, are much, much worse. Even shitty PHP is 30x which is 2x better than Perl efficiency.

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @04:54PM

      by Anonymous Coward on Sunday November 21 2021, @04:54PM (#1198350)

      Nothing. It means nothing.

      Since the late 1990s, if not earlier, things like time to market and the speed a project can make changes or just plain marketing, matter more than efficiency. YouTube and Reddit were originally written in Python, which is slow. Twitter was originally written in Ruby, which is slow. Facebook was originally written in PHP, which is slow. Minecraft and the user interface layer of Android were written in Java, which might be faster than the others but is still far slower and tremendously less memory efficient than C.

      Alternatives written in C or anything near C's speed aren't ready in time and can't change quickly enough, so they lose.

    • (Score: 0) by Anonymous Coward on Sunday November 21 2021, @09:09PM

      by Anonymous Coward on Sunday November 21 2021, @09:09PM (#1198412)

      We, meaning non-programmers, should search out programs written in C or C++?

      There are plenty of career opportunities in management.

      Restaurant, that is.

    • (Score: 2) by mcgrew on Sunday November 21 2021, @09:41PM

      by mcgrew (701) <publish@mcgrewbooks.com> on Sunday November 21 2021, @09:41PM (#1198425) Homepage Journal

      It means you clicked on the wrong discussion.

      --
      mcgrewbooks.com mcgrew.info nooze.org
    • (Score: 3, Insightful) by DannyB on Monday November 22 2021, @03:41PM (1 child)

      by DannyB (5839) Subscriber Badge on Monday November 22 2021, @03:41PM (#1198583) Journal

      If I can use Java (or whatever) to beat my C using competitor to market by one year, and beat my Assembler using competitor to market by five years, then my manager and I will laugh all the way to the bank. Meanwhile the C and Assembler users will be bragging about how fast and efficient their languages are while I'm making money.

      Important metrics:
      * cpu cycles
      * bytes
      * watts (energy efficiency)

      Other important metrics:
      * Developer efficiency
      * Speed of development
      * Time to market
      * Ease of maintenance
      * Ability for new developers to understand code base
      * Ease of refactoring software as needed

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 0) by Anonymous Coward on Monday November 22 2021, @08:28PM

        by Anonymous Coward on Monday November 22 2021, @08:28PM (#1198670)

        Agreed. C, assembler, and languages with similar performance to C and assembler, don't lose in the market because of performance. They lose because of developer speed. That's a market problem, not a language problem or a programmer problem or an industry mindset problem.

  • (Score: -1, Troll) by Anonymous Coward on Saturday November 20 2021, @10:42PM

    by Anonymous Coward on Saturday November 20 2021, @10:42PM (#1198168)

    Lick my plump stump

  • (Score: 4, Insightful) by Anonymous Coward on Saturday November 20 2021, @11:50PM (5 children)

    by Anonymous Coward on Saturday November 20 2021, @11:50PM (#1198185)

    If they think C is the most efficient, they didn't bother to theck colorforth or forth.

    (skims the result tables in the actual paper): Indeed, they did not.

    forth, most expecially on a processor designed for it, like the ones greenarrays make, is something like orders of magnitude better than a typical register-based CPU running compiled C code, no matter how optimized.

    The F18 core that greenarrays sell, reputedly can do a simple op (add, etc) with just 7 pJ, and can do a multiplication operation with just 450 pJ. These numbers are 47x and 5x better respectively than the next nearest competitor - a TI MSP430 microcontroller, which is a microcontroller optimised for extreme low power and using a newer process node to get there.

    In general, forth tends to result in crazy condensed and factorized code, such that remarkably little resources are needed to perform the application. The 'interpreted' reputation isn't actually true/fair - at run time, it's running binary code. The 'threadedness' gets hardware implemented more than you might think, even on a typical register cpu that does not support real stack-registers. The compactness of the code leads to vastly fewer cache misses, leading to quicker time-to-sleep.

    Forth is commonly misunderstood - the fact that a forth system can still compile code at runtime does not mean it is an interpreted system, except for the moment after new source is input. That whole facility is optional, and even if included, generally fits within just a few kb.

    With the F18, it was realised it was actually faster and more efficient to keep enough of a 'compiler' on the chip, and actually load source at runtime - allowing the chip to do the simple compilation required locally, on the fly. This effectively added as a very high-level form of code data compression. Only possible because of the KISS / efficiency principles built into the whole 'forth / forthlike interpreted-threaded langauge' approach.

    It's actually funny that both forth an Lisp essentially keep getting re-invented. Forth for efficiency, lisp for generality.

    • (Score: 2, Interesting) by Anonymous Coward on Sunday November 21 2021, @02:29AM (3 children)

      by Anonymous Coward on Sunday November 21 2021, @02:29AM (#1198212)

      Forth is little more than the bytecode of a stack oriented virtual machine.
      There is a reason it's not used anymore. And no, it is impossible for it to be faster than C. It will not even equal it for general purpose software.

      It's a neat, minimalist language that is tiny enough to easily learn and implement, but it is far, far too limited compared to other languages for practical software development. I still recommend learning it for the curious, as the concepts touched on are useful as part of your wider education. Just don't drink the Kook-Aid.

      • (Score: 4, Interesting) by rleigh on Sunday November 21 2021, @12:20PM (2 children)

        by rleigh (4887) on Sunday November 21 2021, @12:20PM (#1198308) Homepage

        There are situations where a Forth program could be much faster than C.

        With C, you need to save and restore registers on the stack as part of the platform's calling conventions. On ARM, for example, this is AAPCS. Not all functions will need to do this, depending upon their use of registers and the stack, but by and large there is an overhead to function calls, and a considerable amount of program code is dedicated to pushing and polling register values on and off the stack. If you write custom routines in assembler, you have to use AAPCS to call into, or be called from, C code, so you don't trash registers in use by the caller, or fail to save state that could be trashed by the callee.

        With Forth, you avoid all of that entirely. Individual Forth words will push and pop values onto the data stack and/or the return stack, but you don't have the platform calling conventions to worry about. While this will very much depend upon the Forth implementation and the specific application, it's not unreasonable for some applications to be vastly more efficient than the corresponding C. Passing data between words in Forth is cheap, and with the elimination of the C calling convention overheads, it's completely conceivable that it can handily beat C in some circumstances.

        As to whether I'd want to use Forth, it's neat but obscure. Definitely worth considering for custom DSLs for specific problems. But likely not for large applications.

        • (Score: 2) by turgid on Sunday November 21 2021, @03:10PM

          by turgid (4318) Subscriber Badge on Sunday November 21 2021, @03:10PM (#1198332) Journal

          Some CPU architectures, such as SPARC, attempted to mitigate the stack problem when calling functions with register windows. They introduced problems all of their own. Not to mention, on SPARC the register windows were a fixed size (8 32-bit ints). I believe the AMD 29k [cpushack.com] had a more sophisticated implementation.

        • (Score: 1, Interesting) by Anonymous Coward on Sunday November 21 2021, @10:39PM

          by Anonymous Coward on Sunday November 21 2021, @10:39PM (#1198434)

          There's also LIMITS to register called functions/procs: 16 max in 64-bit & 8 in 32-bit (# least in Object Pascal I noted here https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198315#commentwrap [soylentnews.org] ) & I've HIT it! You can't just "willy-nilly" indiscriminately apply it everywhere ALL the time to every function/proc!

          So - how did I decide WHICH procedures to call that way (register)?

          First, I profiled my code using OLD SCHOOL methods of registering hi-res MULTIMEDIA TIMERS w/ the system (higher res vs. std. timers as YOU probably know - yes, I can TELL "you've been there" just by reading your words & you know your shit (which you won't hear outta ME often to others generally - lol)).

          Whatever ones ATE THE MOST TIME in clockticks/ms (meaning they tore up the CPU worse than most), got the register imperative tacked onto their declarations so they were fastest. It worked, as STEP #1... for more?

          Well, I noted a program I did there in that post near it's termination. It works HEAVILY in strings & Object Pascal's FASTER than C++ (& others too per tests I noted) as is on strings & SAFER than C too - so, how to gain even MORE speed? Fit the RIGHT var types!

          Since host names can ONLY be 255 characters, MAX? I made the string default Short string (fitting the strings into local STACK vs. the SLOWER GLOBAL HEAP memory) & overrode it with directives on NON-API using calls (can't on many that demand larger string types is why)!

          Yes - this worked too & I'd wager it RIVALS or EXCEEDS even C on stringspeed now!

          Between Pascal's already heavy over C++ advantage (C++ Std. Template stdstring calls & libraries overcome the DANGER vs. buffer overflows but SLOW C++ TO SHIT, 1/2 as fast as pascal as is)

          So when I boosted my string processing by doing the "tricks" above? I'd race it against even UNSAFE (& imo, cheating) NULL-TERMINATED strings in C - bet I'd win too!

          * Lastly - you noted inline routines C/C++ & even Delphi can do for Inline ASM code (that helps but when you have to wait for compliers to get that, IF they do? You're stuck doing what I did in stringwork @ least - profile 1st (don't need a custom profiler either, see above) & fitting variable types AND PROCEDURE/FUNCTION calls that EAT THE MOST TIME into the registers...)

          APK

          P.S.=> It works - & nice to see someone that knows what they're really talking about in code in you too - I don't VERY often anymore on non-programmer oriented ONLY forums online... apk

    • (Score: 3, Interesting) by turgid on Sunday November 21 2021, @03:13PM

      by turgid (4318) Subscriber Badge on Sunday November 21 2021, @03:13PM (#1198333) Journal

      I think Sun took some ideas from FORTH chips with their picoJava [cpushack.com] CPU. By the way, FORTH was very popular on military satellites apparently, There are quite a few radiation-hardened custom FORTH CPUs orbiting the Earth.

  • (Score: -1, Troll) by Anonymous Coward on Sunday November 21 2021, @02:38AM (1 child)

    by Anonymous Coward on Sunday November 21 2021, @02:38AM (#1198216)

    The biggest plus for me is that they changed the name from The Great Computer Language Shootout to The Computer Language Benchmarks Game. I spend all my time trolling through code looking for words that trigger my blue-haired, nose-ring-wearing, Leftist ass.

    • (Score: 1, Funny) by Anonymous Coward on Sunday November 21 2021, @04:26AM

      by Anonymous Coward on Sunday November 21 2021, @04:26AM (#1198242)

      Blue is out. Commentator of unannounced gender and sexual preference - you can't back the blue!

  • (Score: 1, Informative) by Anonymous Coward on Sunday November 21 2021, @02:58AM (1 child)

    by Anonymous Coward on Sunday November 21 2021, @02:58AM (#1198220)

    The results are what you'd expect: the most efficient language they tested (highest performance, least memory usage) was just about always C, with C++ performing identically. The fastest VM based language was Java. Again, not surprising, as the JVM compiles frequently used code (determined at runtime) to native code.

    What surprised me was how bad perl performed most of the time. Even RUBY usually beat it! And ruby beat perl at REGEX which should've been perl's strong suit! That embarrassing. Out of the interpreted languages, Javascript was by far the fastest. That's heartening to hear given how widely deployed it is. Typescript of course performed identically.

    • (Score: 1, Interesting) by Anonymous Coward on Sunday November 21 2021, @11:20PM

      by Anonymous Coward on Sunday November 21 2021, @11:20PM (#1198446)

      Searcg Table 5. Pareto optimal sets for different combination of objectives there from https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf [uminho.pt] & see that for the very objectives you note? Pascal's RIGHT THERE in good company and it's BETTER COMPANY! How/Why? C's NULL-TERMINATED strings are DANGEROUS & prone to buffer overflow exploits!

      Ok - before you do it?

      Yes, C has an edge in 1/2 of it from chart #4 there iirc, but the catch?

      DANGER Will Robinson, danger (in buffer overflows in C strings). Pascal DOES have the other half as #1 in memory use though!

      * I avoided that using Object Pascal (faster SAFER strings that incorporate strlen INTO the variable itself along w/ reference couters also).

      NOW - as far as C++? I suggest you look @ the links below - Pascal's almost TWICE as FAST as MSVC++ in strings as is (I do more below to make it as fast as C I'd wager & safer already by FAR) + near TWICE AS FAST in math as well!

      All programs do work in math & strings. Safety + Accuracy matter too...

      HOWEVER "disclaimer": Don't get me wrong - C was my "1st love" & 3rd language I learned but learning the dangers in null-terminated strings TURNED ME OFF - bigtime. C has that problem. MSVC++ doesn't in stdstring use, but that slows it to shit...

      (So, ask youself - Why didn't they make their string structures/objects like Pascal? It would be a HUGE REWRITE of the C/C++ string functions is why imo - I think they WANTED C as the OS compiler - why?? To PENETRATE IT when needed in stack smashing etc. whenever necessary... stupid for us, not for the "powers that be" though! Mac Systems were initially done in Pascal but then "SUDDENLY" they were C... think about it!)

      APK

      P.S.=> Details are here https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198315#commentwrap [soylentnews.org]

      ... & moreso to get EVEN MORE SPEED (blows away C++ by DOUBLE in stringwork & DOUBLE in math too) outta Pascal strings & more?? MORE DETAIL is here (register called procs/functions + shortstrings on local faster STACK vs. slower GLOBAL HEAP memory use) https://soylentnews.org/comments.pl?noupdate=1&sid=46096&page=1&cid=1198434#commentwrap [soylentnews.org]

      ... & IF/WHEN POSSIBLE (Pain in the ASS in ports to diff. hardware though, means rewrite quite often)?? Inline Asm usage (I did that in Delphi 7 but when Delphi XE series came out? It wasn't there so I went back to straight Object Pascal code since the compiler didn't have it YET - does now though & yes, Delphi &/or FreePascal + Lazarus IDE are OS multiplatform & "multi-hardware platform" too))...apk

(1) 2