3 ms·

Isn't Lunar Lake first mobile chip with focus on energy eff? And it is reasonably efficient We will see how big improvement is it's successor panther lake in J

Isn't Lunar Lake first mobile chip with focus on energy eff? And it is reasonably efficient We will see how big improvement is it's successor panther lake in January on 18A node >I would need some strong evidence to make me think it isn't the ISA that makes the difference. It is like saying that Java syntax is faster than C# syntax. Everything is about the implementation: compiler, jit, runtime, stdlib, etc If you spent decades of effort on peformance and ghz then don't be shocked that someone who spent decades on energy eff is better in that category

cogman10 1y ago
> 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).
mrsmrtss 1y ago
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.
- high_na_euv 1y ago
  Yet how much perf in recent dot nets comes from that, and how much comes from "Span<T>"ning whole BCL?
  - mrsmrtss 1y ago
    There’s much more to it than just Span<T>. Take a look at the performance improvements in .NET 10: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-10/ https://devblogs.microsoft.com/dotnet/performance-improvemen.... When it comes to syntax, even something like structs (value types) can be a decisive factor in certain scenarios. C# is fast and with some effort, it can be very fast! Check out the benchmarks here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - high_na_euv 1y ago
      I know that C# is fast, this is my favourite lang, but it is hard to say honestly which one is faster I love the saying "i dont trust benchmarks that i didn't fake myself"
- layer8 1y ago
  That’s semantics though, not syntax. What’s holding Java performance back in some areas is its semantics. It might be the same with x86 and power-efficiency (semantics being the issue), but there doesn’t seem to be a consensus on that.
IshKebab 1y ago
> 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.

cogman10 1y ago

> 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).

mrsmrtss 1y ago

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.

high_na_euv 1y ago
Yet how much perf in recent dot nets comes from that, and how much comes from "Span<T>"ning whole BCL?
- mrsmrtss 1y ago
  There’s much more to it than just Span<T>. Take a look at the performance improvements in .NET 10: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-10/ https://devblogs.microsoft.com/dotnet/performance-improvemen.... When it comes to syntax, even something like structs (value types) can be a decisive factor in certain scenarios. C# is fast and with some effort, it can be very fast! Check out the benchmarks here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - high_na_euv 1y ago
    I know that C# is fast, this is my favourite lang, but it is hard to say honestly which one is faster I love the saying "i dont trust benchmarks that i didn't fake myself"
layer8 1y ago
That’s semantics though, not syntax. What’s holding Java performance back in some areas is its semantics. It might be the same with x86 and power-efficiency (semantics being the issue), but there doesn’t seem to be a consensus on that.

IshKebab 1y ago

> 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.