Programming languages are generally defined as a more human-friendly way to program computers than using raw machine code. Within the realm of these languages there is a wide range of how close the programmer is allowed to get to the bare metal, which ultimately can affect the performance and efficiency of the application. One metric that has become more important over the years is that of energy efficiency, as datacenters keep growing along with their power demand. If picking one programming language over another saves even 1% of a datacenter’s electricity consumption, this could prove to be highly beneficial, assuming it weighs up against all other factors one would consider.

There have been some attempts over the years to put a number on the energy efficiency of specific programming languages, with a paper by Rui Pereira et al. from 2021 (preprint PDF) as published in Science of Computer Programming covering the running a couple of small benchmarks, measuring system power consumption and drawing conclusions based on this. When Hackaday covered the 2017 paper at the time, it was with the expected claim that C is the most efficient programming language, while of course scripting languages like JavaScript, Python and Lua trailed far behind.

With C being effectively high-level assembly code this is probably no surprise, but languages such as C++ and Ada should see no severe performance penalty over C due to their design, which is the part where this particular study begins to fall apart. So what is the truth and can we even capture ‘efficiency’ in a simple ranking?

Defining Energy Efficiency

At its core, ‘energy efficiency’ is pretty simple to define: it’s the total amount of energy required to accomplish a specific task. In the case of a software application, this means the whole-system power usage, including memory, disk and processor(s). Measuring the whole-system power usage is also highly relevant, as not every programming and scripting language taxes these subsystems in the same way. In the case of Java, for example, its CPU usage isn’t that dissimilar from the same code written in C, but it will use significantly more memory in the process of doing so.

Two major confounding factors when it comes to individual languages are:

• Idiomatic styles versus a focus on raw efficiency.
• Native language features versus standard library features.

The idiomatic style factor is effectively some kind of agreed-upon language usage, which potentially eschews more efficient ways of accomplishing the exact same thing. Consider here for example C++, and the use of smart pointers versus raw pointers, with the former being part of the Standard Template Library (STL) instead of a native language feature. Some would argue that using an STL ‘smart pointer’ like a unique_ptr or auto_ptr is the idiomatic way to use C++, rather than the native language support for raw pointers, despite the overhead that these add.

A similar example is also due to C++ being literally just an extension to C, namely that of printf() and similar functions found in the <cstdio> standard library header. The idiomatic way to use C++ is to use the stream-based functions found in the <iostream> header, so that instead of employing low-level functions like putc() and straightforward formatted output functions like printf() to write this:
printf("Printing %d numbers and this string: %s.\n", number, string);
The idiomatic stream equivalent is:
std::cout << "Printing " << number << " numbers and this string: " << string << "." << std::endl;
Not only is the idiomatic version longer, harder to read, more convoluted and easier to get formatting wrong with, it is internally also significantly more complicated than a simple parse-and-replace and thus causes more overhead. This is why C++20 decided to double-down on stream formatting and fudging in printf-like support with std::format and other functions in the new <format> header. Because things can always get worse.

Know What You’re Measuring

At this point we have defined what energy efficiency with programming languages is, and touched upon a few confounding factors. All of this leads to the golden rule in science: know what you’re measuring. Or in less fanciful phrasing: ‘garbage in, garbage out’, as conclusions drawn from data using flawed assumptions truly are a complete waste of anyone’s time. Whether it was deliberate, due to wishful thinking or a flawed experimental setup, the end result is the same: a meticulously crafted document that can go straight into the shredder.

In this particular comparative analysis, the pertinent question is whether the used code is truly equivalent, as looking across the papers by Rui et al. (2017, 2021), Gordillo et al. (2024) or even a 2000 paper by Lutz Prechelt all reveal stark differences between the results, with seemingly the only constant being that ‘C is pretty good’, while a language such as C++ ends up being either very close to C (Gordillo et al., Prechelt) or wildly varying in tests (Rui et al.), all pointing towards an issue with the code being used, as power usage measurement and time measurement is significantly more straightforward to verify.

In the case of the 2021 paper by Rui et al., the code examples used come from Rosetta Code, with the code-as-used also provided on GitHub. Taking as example the Hailstone Sequence, we can see a number of fascinating differences between the C, C++ and Ada versions, particularly as it pertains to the use of console output and standard library versus native language features.

The C version of the Hailstone Sequence has two printf() statements, while the C++ version has no fewer than five instances of std::cout. The Ada version comes in at two put(), two new_line (which should be merged with put_line) and one put_line. This difference in console output is already a red flag, even considering that when benchmarking you should never have console output enabled as this draws in significant parts of the operating system, with resulting high levels of variability due to task scheduling, etc.

The next red flag is that while the Ada and C versions uses the native array type, the C++ version uses std::vector, which is absolutely not equivalent to an array and should not be used if efficiency is at all a concern due to the internal copying and house-keeping performed by the std::vector data structure.

If we consider that Rosetta Code is a communal wiki that does not guarantee that the code snippets provided are ‘absolutely equivalent’, that means that the resulting paper by Rui et al. is barely worth the trip to the shredder and consequently a total waste of a tree.

Not All Bad

None of this should come as a surprise, of course, as it is well-known (or should be) that C++ produces the exact same code as C unless you use specific constructs like RTTI or the horror show that is C++ exceptions. Similarly, Ada code with similar semantics as C code should not show significant performance differences. The problem with many of the ‘programming language efficiency’ studies is simply that they take a purported authoritative source of code without being fluent in the chosen languages, run them in a controlled environment and then draw conclusions based on the mangled garbage that comes out at the end.

That said, there are some conclusions that can be drawn from the fancy-but-horrifically-flawed tables, such as how comically inefficient scripting languages like Python are. This was also the take-away by Bryan Lunduke in a recent video when he noted that Python is 71 times slower and uses 75 times more energy based on the Rui et al. paper. Even if it’s not exactly 71 times slower, Python is without question a total snail even among scripting languages, where it trades blows with Perl, PHP and Ruby at the bottom of every ranking.

The take-away here is thus perhaps that rather than believing anything you see on the internet (or read in scientific papers), it pays to keep an open mind and run your own benchmarks. As eating your own dogfood is crucial in engineering, I can point to my own remote-procedure call (NymphRPC) library in C++ on which I performed a range of optimizations to reduce overhead. This mostly involved getting rid of std::string and moving to a zero-copy system involving C-isms like memcpy and every bit of raw pointer arithmetic and bit-wise operators goodness that is available.

The result for NymphRPC was a four-fold increase in performance, which is probably a good indication of how much performance you can gain if you stick close to C-style semantics. It also makes it obvious how limited these small code snippets are, as with a real application you also deal with cache access, memory alignment and cache eviction issues, all of which can turn a seemingly efficient approach into a sluggish affair.

hackaday.com/2024/09/10/assess…

A new compromise text sent by the Hungarian Presidency of the EU Council to delegations about the draft law to detect child sexual abuse material (CSAM), focuses on known material, possibly lessening concerns around the regulations' privacy implications.

euractiv.com/section/law-enfor…

Siamo di fronte ad un nuovo e sofisticato side channel attack. L’attacco RAMBO (Radiation of Air-gapped Memory Bus for Offense), presentato da ricercatori israeliani, sfrutta l’emissione elettromagnetica prodotta dalla memoria RAM per rubare dati da computer isolati fisicamente (air-gapped).

Attraverso un malware, i ricercatori hanno manipolano l’accesso alla memoria per generare segnali elettromagnetici rilevabili con dispositivi di ricezione SDR (Software Defined Radio). Anche se la velocità di trasmissione è relativamente bassa (fino a 1000 bit al secondo), è sufficiente per sottrarre informazioni sensibili come password o chiavi crittografiche. Questo attacco rappresenta una minaccia crescente soprattutto per sistemi ad alta sicurezza.

La RAM è stata a lungo considerata una parte non attaccabile direttamente nei sistemi informatici, ma la scoperta del team israeliano dimostra che la memoria volatile può essere utilizzata come vettore di attacco attraverso radiazioni elettromagnetiche. La particolarità di RAMBO è che riesce a superare le misure di sicurezza di isolamento fisico, sfruttando una vulnerabilità fisica nei sistemi di memoria che in precedenza non era stata considerata.

L’attacco non necessita di connessione diretta al computer preso di mira, ma solo della presenza di un ricevitore nelle vicinanze. Questi segnali elettromagnetici possono essere generati appositamente con modelli di accesso alla memoria RAM ben studiati, manipolati dal malware installato sul computer vittima.

La trasmissione dei dati è unidirezionale, quindi i criminali riescono a leggere i dati sensibili senza inviare alcun segnale che potrebbe compromettere il loro attacco.

Una delle sfide principali per i difensori di sistemi sensibili come quelli militari o finanziari è che i tradizionali metodi di sicurezza come firewall e software anti-malware non sono efficaci contro attacchi basati su radiazioni elettromagnetiche, in quanto non c’è interazione diretta con la rete o i sistemi di protezione. Anche se la velocità di trasmissione dei dati di RAMBO è bassa, questo attacco può essere eseguito nel tempo, permettendo ai criminali di raccogliere informazioni critiche.

Per prevenire attacchi come RAMBO, gli esperti di sicurezza consigliano l’adozione di misure fisiche come schermature elettromagnetiche, in particolare per le macchine ad alta criticità. L’implementazione di gabbie di Faraday intorno ai dispositivi potrebbe essere una soluzione efficace, poiché queste barriere bloccano i segnali elettromagnetici in uscita, impedendo la trasmissione non autorizzata dei dati.

RAMBO si inserisce in una crescente serie di attacchi volti a compromettere la sicurezza di sistemi air-gap, tradizionalmente considerati tra i più sicuri. A differenza di altri attacchi, RAMBO non richiede la compromissione di connessioni cablate o wireless convenzionali, rendendolo un vettore d’attacco estremamente subdolo e potenzialmente devastante per ambienti altamente protetti.

In sintesi, l’attacco RAMBO rappresenta una nuova e insidiosa minaccia che sfrutta le radiazioni elettromagnetiche della RAM per estrarre dati critici da sistemi isolati. La difesa contro tali attacchi richiede l’adozione di misure innovative e fisiche, oltre alla consueta protezione software, per garantire la sicurezza dei dati in ambienti sensibili.

Per maggiori dettagli sull’attacco RAMBO, puoi consultare l’articolo completo qui.

L'articolo Arriva RAMBO! l’emissione Elettromagnetica della RAM consente di Rubare i Dati dai computer isolati proviene da il blog della sicurezza informatica.

When Apple started rolling out its Retina displays, it multiplied the amount of pixels compared to their standard, non-Retina displays by four. This increased pixel density while keeping the standard screen size — idea for those needing a lot of detail for their work. But, as is common with Apple, using these displays outside of the Apple ecosystem can be quite a challenge. Retina displays have been around for about a decade now, though, with some third-party hardware able to break them free of their cage. This post details how [Kevin] liberated the 5K display from a 2017 iMac for more general use with support for USB-C.

The first step was to find a used iMac for the right price, and then sell off most of its parts to recoup most of the initial cost. That brought the cost of the panel itself to about $250. The key to getting the display working without all of the Apple hardware is the R1811 driver board, which can be had for around $300. A new 156 watt power supply was added to the mix, and [Kevin] also put in a few extras like a USB cable extension and a latching push-button which kills the display’s power. Additionally, he attempted to get the original iMac speakers working with this setup too, but none of his attempts resulted in anything close to quality sound so he’s mostly abandoned that extra feature for now.

With that all buttoned up, he has a 27″ 5K display with USB-C input for around $650 which is quite a deal. The MacRumors thread that [Kevin] added his project to currently has around 1,700 posts about similar builds too, so it can be a wealth of information for all kinds of models. As Apple drops support for their older machines, these displays will become more and more common and projects like these can keep a lot of e-waste out of the landfill while also providing decent hardware at a bargain price. Don’t just look for iMacs and MacBooks though; there’s a similar process to use various iPad displays for other things as well.

hackaday.com/2024/09/10/rescui…

Secondo i servizi occidentali, c'è un aumento dell'attività militare russa intorno ai cavi sottomarini delle comunicazioni.

The post Se la Russia ci taglia Internet… la guerra ibrida intorno ai cavi sottomarini appeared first on InsideOver.

<<la “Banda del buco” ha derubato due oreficerie a Roma per un bottino di oltre 110mila euro. Ma la polizia è riuscita a fermarli: tra gli arrestati anche il “boss-poeta” 64enne Mauro Belli.
Belli era uscito da Rebibbia nel '23, dopo aver scontato 12 condanne. Dalla detenzione aveva tratto ispirazione per il suo libro "A Mauro, falla finita", che presentava nei festival di letteratura. Ma Belli non aveva mai voltato pagina dalla sua vita precedente, fatta di reati e droga: "Sempre contro i ricchi, mai contro i poveri", scriveva>>.

open.online/2024/08/29/roma-ba…

La banda del buco con il boss poeta che usava i B&B per rapinare le gioiellerie - Open

Le oreficerie dovevano essere sotto dei B&B. Così creavano un passaggio nel pavimento: sei gli arrestati

^{Ugo Milano (GOL Impresa Sociale)}

slowforward.net/2024/09/09/out…

slowforward

2024-09-09 08:08:05

youtu.be/GxQ3PucXg8k?si=npkiXs…

.

slowforward.net/2024/09/09/out…

#experimentalFilm #film #PeterTscherkassky #video

outer space / peter tscherkassky

^slowforward