Not a problem in practice as you use val 99.99% percent of the cases (which shows why immutability should be the default, because most often that is needed) and Idea underlines any mutable references, so the sticks out. It also suggests val when a var is not actually mutated.
They aren't inherently power efficient because of technical reasons, but because of design culture reasons.
Traditionally x86 has been built powerful and power hungry and then designers scaled the chips down whereas it's the opposite for ARM.
For whatever reason, this also makes it possible to get much bigger YoY performance gains in ARM. The Apple M4 is a mature design[0] and yet a year later the M5 is CPU +15% GPU +30% memory bandwidth +28%.
The Snapdragon Elite X series is showing a similar trajectory.
So Jim Keller ended up being wrong that ISA doesn't matter. Its just that it's the people in the ISA that matter, not the silicon.
[0] its design traces all the way back to the A12 from 2018, and in some fundamental ways even to the A10 from 2016.
AFAIK you needed to pay a license fee to write programs using Jazelle instructions (so you needed to weigh whether the speedup of Jazelle was cheaper than just buying a more powerful CPU), and the instruction set itself was also secret, requiring an NDA to get any documentation (so no open source software could use it, and no open toolchains supported it).
I remember being very disappointed when I found out about that
I generally agree, although one should not forget x86 (and AMD64) leaves about 3-10% performance on the table due to having a memory model that doesn't allow to reorder loads with other loads and stores with other stores.
People are absolutely part of an ISA's ecosystem. The ISA is the interface between code and CPU, but the code is generally emitted by compilers, and executed in the context of runtimes and operating systems, all designed by people and ultimately dependent on their knowledge of and engagement with the ISA. And for hot code in high-performance applications, people will still be writing directly in assembler directly to the ISA.
Do you have any actual evidence for that? Intel does care about power efficiency - they've been making mobile CPUs for decades. And I don't think they are lacking intelligent chip designers.
I would need some strong evidence to make me think it isn't the ISA that makes the difference.
Basically, x86 uses op caches and micro ops which reduces instruction decoder use, the decoder itself doesn't use significant power, and ARM also uses op caches and micro ops to improve performance. So there is little effective difference. Micro ops and branch prediction is where the big wins are and both ISAs use them extensively.
If the hardware is equal and the designers are equally skilled, yet one ISA consistently pulls ahead, that leads to the likely conclusion that the way the chips get designed must be different for teams using the winning ISA.
For what it's worth, the same is happening in GPU land. Infamously, the M1 Ultra GPU at 120W equals the performance of the RTX 3090 at 320W (!).
> Isn't Lunar Lake first mobile chip with focus on energy eff?
Not by a long shot.
Over a decade ago, one of my college professors was an ex-intel engineer who worked on Intel's mobile chips. He was even involved in an Intel ARM chip that ultimately never launched (At least I think it never launched. It's been over a decade :D).
The old conroe processors were based on Intel's mobile chips (Yonah). Netburst didn't focus on power efficiency explicitly so and that drove Intel into a corner.
Power efficiency is core to CPU design and always has been. It's easy create a chip that consumes 300W idle. The question is really how far that efficiency is driven. And that may be your point. Lunar Lake certainly looks like Intel deciding to really put a lot of resource on improving power efficiency. But it's not the first time they did that. The Intel Atom is another decades long series which was specifically created with power in mind (the N150 is the current iteration of it).
> It is like saying that Java syntax is faster than C# syntax.
Java and C# are very similar so that analogy might make sense if you were comparing e.g. RISC-V and MIPS. But ARM and x86 are very different, so it's more like saying that Go is faster than Javascript. Which... surprise surprise it is (usually)! That's despite the investment into Javascript implementation dwarfing the investment into Go.
Actually, if you had made an opposite example, it might have gone against your point. ;) C# gives you a lot more control over memory and other low-level aspects, after all.
According to an AMD engineer I asked at the time, when they evaluated Ryzen/K12, it was "maybe" a 15% advantage for ARM depending on scenarios.
The efficiency came solely from the frontend which is a lot heavier on x86, and stay up longer because decoding is way more complex. The execution units were the same (at least mostly, I think, might be misremembering) so once you are past the frontend there's barely any difference in power efficiency.
Actually power efficiency was a side effect of having a straightforward design in the first ARM processor.
The BBC needed a cheap (but powerful) processor for the Acort computer and a RISC chip was
When ARM started testing their processor, they found out it draw very little power...
Acorn won the bid to make the original BBC home computer, with a 6502-based design.
Acorn later designed their own 32-bit chip, the ARM, to try to leapfrog their competitors who were moving to the 68000 or 386, and later spun off ARM as a separate company.
>Are ARM processors inherently power efficient? I doubt.
In theory yes. In practice none of the x86 design are even close, the lunar lake at same wattage barely competes with M1. And M1 is one node generation behind.
Do you mean with the levels filter that Krita has, with the curves filter that Krita has, with the color balance filer that Krita has, with the slope, offset, power filter that Krita has, or with the hue/saturation/luma or red chroma/blue chroma/luma adjustment filter that Krita has?[1]
They are all available as non-destructive filter layers, by the way, and Krita users had access to this way before GIMP 3.0 was released with non-destructive filters.
> Do you mean with the levels filter that Krita has, with the curves filter that Krita has, with the color balance filer that Krita has, with the slope, offset, power filter that Krita has, or with the hue/saturation/luma or red chroma/blue chroma/luma adjustment filter that Krita has?
Honestly, I did not know that these existed in Krita (when I used Krita, I did not find them).
However, I still stubbornly maintain that I answered the question sufficiently, which used the qualifier "with a better UI".
Taking a leaf out of my wife's book "Even when I'm wrong, I'm right!* :-)
Why would anybody think it is a real alternative to upload your photos to website which is running proprietary garbage. Just use Adobe if you are going to do that.
I strongly prefer local software, but as someone coming from Photoshop who now only does the occasional edit (and therefore can't justify the price), I find Photopea to be a good alternative, especially since it closely mimics Photoshop's interface so I don't have to learn a new UI. Also, your images stay local on your computer and aren't uploaded to their servers.
It's developed by a single guy, which I think is very impressive given how much of Photoshop's functionality it has. I just really wish it were open source (and not a web app).
I don't see a problem with that. This code would typically be inside it's own function anyway, but regardless I think your nitpick is less important than the readability benefit.
reply