I interpreted it as "enough to live a comfortable life".
Money is part of how you get there, but it is not a goal in itself. Many start businesses where money is the main goal, and where the amount that you are satisfied with inevitably shifts once you get richer
Considering that their cheapest pricing is $12 (per month, 1 month minimum) and they claim 550 million users, either they made tons of riches or the numbers are to be questioned. I leave it to you to estimate which is more likely.
In a world where people trade time for money, they effectively collect time as money, and money can be used to buy back time through the correct conveniences if they choose to buy back the freedom in their time, first through high leverage low cost items, and then over time more.
It was me. I'm sorry for the confusion caused by this.
My interest in the article was in the German link of the word, so wanted to really emphasize that. I made a mistake it seems, if only by not simply saying ".. was probably a german translation"
Admittedly, Apple has “refused” to do many things over the years (pen support on iPad comes to mind) and yet ends up doing them. Apple refuses to do something until they want to sell it.
FWIW, I don’t understand the appeal of this device at all, but I don’t expect much consistency from Apple.
Have you checked mammoth-1/elephant-1 models? They are benchmarking quite well compared and are currently free on openrouter. I currently use mammoth-1 for a small internal app and it works flawlessly for what I am doing.
Ah damn and also interesting. I am using it for classifying ads in podcasts. I am listening to a lot of English podcasts, but I am in Germany so often German segments are cut in. Mammoth-1 has had zero issues classifying those segments, but I guess my usecase might just be a lot simpler than yours.
Just fyi, i switched to span-02 on openrouter as well since it’s 10x cheaper than mammoth and it’s performing just as well for me, if not better because it’s noticably faster! So thanks for the recommendation.
> Two small edits close most of it: compute the loop bounds into locals before the loop,
I always assumed any decent runtime/compiler takes care of such optimisations, and usually leave such things to JDK in my Java code. Is that really not the case?
Its possible the JIT would have optimized this but that optimization isn't making its way into the native AOT build.
Also possible if it were more idiomatic C# it would have optimized it better. RyuJIT does in fact do BCE and other loop optimizations. It's improving a lot every year too.
The optimization paths from C# though Roslyn and RyuJIT probably don't start with C# written like it were C. Maybe iterating over Spans and slices would have optimized to fewer instructions than raw dogging nested for loops.
You would be astounded how more efficient your program can be if you are doing decent amount of computation or IO.
You can try to understand some of it by doing some measurements and doing some napkin math using the hardware limits like internet bandwidth or IO read/write etc.
Decent ones do. .NET's JIT has historically (before ryujit especially and tbh I haven't looked at .NET much in the past decade) not been decent, general statements about decent compilers never applied to it. It has been playing catch-up lately but apparently it still has a ways to go.
That is absolutely not true. Not historically, and not now. .NET's JIT has always been very good, bar a few qualifying statements.
It used to be based on MSVC, with the most expensive optimizations trimmed, things like loop hoisting, devirtualization, generally ones with long runtimes, or ones that required whole program visibility.
But otherwise it was competent, if you wrote code aware of these limitations, it could get very close to even C++, and even on naive code, it was always very competitive (with strange wildcards, that if you used raw pointers, which are an obscure C# feature, you could get code to be even faster, due to the compiler's heritage).
It also helped, that due to MS's nature; C# was meant to be used with MS frameworks, written by people who were aware of the compiler's quirks, which you could learn if you looked at these codebases.
Sure if yo measure against LLVM-compiled static languages, it falls short in certain scenarios, but it's been soldily in the pack of other GC languages like Java or Go, and always has been.
There's an experiment to create an LLVM-based Native AOT tool chain. I sincerely hope they work on this properly, so that we can have a properly optimized AOT. But I'm not sure if it will end up with less quirks.
Thanks for that. I had definitely noticed that the .NET JIT wasn't doing loop hoisting. And that you could get close to C/C++ performance if you did loop hoisting manually. It's useful to get some insight on .NET's actual optimization philosophy.
The old JIT was a fork of a pared-back version of MSVC; this was for all platforms, except the .NET Compact framework, which was for embedded stuff, and it was its own fork.
There were other weird things like C++/CLI which was a full-fat MSVC fork used to compile C++ either into .NET IL or x86 code which could be embedded into .NET assemblies, but could still call into .NET code.
But what most people think of as .NET (Framework) was definitely using the old MSVC-based JIT
For what it’s worth, C++/CLI is not a fork, but a feature of the VC++ compiler, which still exists and supports the latest .NET versions, with the important caveats that it’s neither cross-platform nor open source.
I, for one, would love to have a cross-platform, open source C++/CLI compiler, because there is no more convenient way to consume nontrivial C++ APIs (and buggy, poorly-specified COM APIs only documented by C++ example code) in .NET.
Ehhhhhhh I thought it was a bit of a mishmash, at least before ryujit?
i.e. I think the x64 framework compiler was based on MSVC, but the x86 was a bit of a different beast. That was part of why they did RyuJit in the first place, to help unify the JITs between the large divergence in how they worked [0].
One big thing being, AFAIK the old 32 bit JIT would never use SSE2 outside of some block copy type stuff. They assumed a safe baseline for most other instructions and stuck with that (although, there can be good reasons for this, e.x. consistency with x87 behavior.)
Will also add that the old x64 compiler sometimes really did do some questionable stuff, i.e. when we flipped things to use it we never really saw a perf benefit even when dealing with larger datatypes/etc that should have seen a benefit from wider registers.
RyuJit definitely has fixed that, but... again, the past is a bit hazy.
They have been improving, this is one area however where those C# vs Java flamewars kind of miss out.
While C# the language has much more goodies than Java the language, Java the platform has had much better options than the CLR, because it has been mostly Microsoft and Mono (nowadays almost gone after the acquisition), whereas the Java ecosystem has a plethora of implementations, each one wiht their JIT and GC implementations, even AOT caches since almost three decades now.
Thankfully the outcome of Project Midori, and the whole Secure Future Initiative , has had the side effect of Microsoft becoming more serious about .NET performance, instead of always outsourcing performance workloads to C++ and COM.
Kind of, us users of .NET would have liked a Delphi, VB 6 kind of attention to performance, however for many years, Microsoft management had exactly that attitude, expecting that anyone that cared about performance would be writting COM in C++, or DLLs, and consuming those artifacts from .NET.
Finally they changed their approach to .NET, besides Midori, SFI that I mention on a sibling comment, certainly also due to Go and Rust competition.
Note how Azure nowadays does most of their open source contributions in Go and Rust, the rewrites that completly ignored .NET, while the team mentions lack of adoption on .NET related podcasts.
Silverlight comes to mind, Also the fever dream that was '.NET micro'. I might still have my NetDuino somewhere...
> the main target audience of C#/.NET has always been LOB CRUD app shops.
I do think this has changed over time. There's definitely been improvements to the overall ecosystem from game developers (Cysharp being the most prolific) via both libraries and feedback around the BCL/JIT/etc.
Docker is probably the highest-profile software written in Go. Are you happy with that choice? Would you do it in Rust if it was available at the time, or Zug?
reply