joas_coder

public class Hello {

    public static void main(String[] args) {

        Chatter chatter = new Chatter();

        String text = "Hello " + chatter.getWord() + "!";
        System.out.println(text);
        free text; // destroy object and reclaim the memory

        free chatter; // destroy object and reclaim the memory

        // System.out.println(chatter); // use after free NEVER compiles
    }

}

// OR:

public class Hello {

    public static void main(String[] args) {

        Chatter chatter = new Chatter();
        defer free chatter;

        String text = "Hello " + chatter.getWord() + "!";
        defer free text;
        System.out.println(text);
    }
}

Ironwood is an interesting project: a Java-like, object-oriented language that compiles AOT to native executables, without a JVM, JIT, garbage collector, raw pointers, or Rust-style ownership.

Unlike GraalVM Native Image, which takes existing Java bytecode and packages the required Java runtime components into a native executable, Ironwood is a separate language designed from the start around native execution and explicit compiler-enforced safe memory management.

It uses LLVM, like Rust and Zig, so the native code produced can be very fast. It has a "defer" keyword for deferred cleanup, like Zig.

What do you think of the idea?

This resonates with an adjacent problem I’ve been exploring: durable project provenance rather than live-session portability. I’m building PromptSourceCode for Codex Desktop; it preserves the human requests, corrections, and attachments as readable local history alongside the project: https://github.com/ironwood-lang/prompt-source-code. It deliberately doesn’t try to translate or resume sessions across agents. Does Skillsync expose stable session and turn identifiers that an external audit history could reference after translation?

Strongly agree. Ironwood (https://github.com/ironwood-lang/ironwood) takes that to the limit by throwing away the JVM :) The static type is the tag, so nothing is tagged at runtime. Primitives are machine-width values, references are one pointer, and generics specialize in the closed world, so the language has no boxing at all.

> If it's not your first rodeo in compilers, IMHO just design your runtime primarly for register-passable values from day one, it might feel like premature optimization, but since the value model will permeate so much of the runtime, the knock-on effects once you do decide to fix it probably makes it worth to go with it from day 1.

Day one, definitely. Those were cheap to fix only because the value model never had to change.

> Now with containers, running Java apps in containers isn't great because of that JVM layer.

Funny, Ironwood (https://github.com/ironwood-lang/ironwood) explores exactly this space: familiar Java programming without JVM startup, warmup, or GC.

And a quick YouTube short video on how to put the app on auto-pilot so that you don't have to do anything to have your screenshots receive meaningful names: https://youtube.com/shorts/8bxhBgJvp7M

Thanks for the feedback. I did not know my Mac had an on-device Apple Foundation model. Is it multimodal? I'll be checking it out and comparing it with Google Gemma 4. I thought Apple was out of the AI model race.

The idea is to ship more powerful lightweight free models as they become available. I'm looking forward to Gemma 5!

> The biggest concern for an app like this is how much RAM you end up using trying to run it

You are totally right. A new feature for a future version would be to turn off the model when the app is idle. And only launch it next time the user takes a screenshot. It is a trade-off between latency to generate the names and memory RAM.

For anyone who wants to see the workflow before downloading the large app bundle, here’s a short demo: https://www.youtube.com/watch?v=QIt2H_CUYBM

The goal of this research is to explore the performance differences between JIT (just-in-time compilation) and AOT (ahead-of-time compilation) strategies and to understand their respective advantages and disadvantages. The intent is not to claim that one language is slower or worse than the other.

In our tests, we observed better results with the HotSpot JVM 23 using JIT compilation. We got slower results with C++ (compiled with Clang 18), GraalVM 23 (compiled with native-image), and HotSpot JVM 23 with the -Xcomp flag. We are seeking to understand why this happens, and if possible, identify ways to improve the performance of the C++ version to match the results of Java's JIT compilation.

Our benchmark involves comparing a hash table (map) implementation in Java to an equivalent implementation in C++. We made every effort to ensure consistency between the two implementations, but it’s possible that some nuances were overlooked.

The hash table implementation itself is simple, and we aimed to make the Java and C++ code as equivalent as possible, including how memory is managed. For instance, we ensured that the C++ hash table values are stored by reference, not by value, to avoid unnecessary copying.

The benchmark creates a hash table with 5,000,000 buckets and inserts 10,000,000 objects, minimizing collisions. The linear search in each bucket is kept to a maximum of two iterations to avoid discrepancies in measurements due to varying collision behavior across different elements.

The Bench class, which handles the measurements, should also be equivalent in both implementations.

Given these details, does anyone have insights into why the C++ version of the benchmark was slower than the Java version? Could there be something we overlooked or an aspect of the C++ implementation that could be optimized further? Perhaps specific Clang optimization options we should explore?

The link to the project is here => https://github.com/coralblocks/CoralBench?tab=readme-ov-file...

I agree it would be interesting and a fun project! Correct me if I'm wrong, but the problem with PGO is that every time the code changes the PGO needs to be updated as well. Also, my past experience with PGO (for the GraalVM native-image) is that it improves a bit, but not much. Maybe 50% at best. But again, the only way to know for sure is to do it and measure it. That's something we should definitely dig deeper to see what kind of difference (in practice) it can make.

I see your point. Sorry about that. Your given example looks very cool. We'll try to do something like that. For now, you can see the results here: https://gist.github.com/coralblocks/21523d73f460924874685f11...

Or on GitHub: https://github.com/coralblocks/CoralBench?tab=readme-ov-file...

It will be hard to make a final conclusion. It is more of a research exercise to learn. All we can say is that as the code stands right now Java JIT is faster than C++ clang AOT for this simple map implementation. And all the code, compilation scripts, executions scripts, details, etc. are available in our GitHub so that other people can execute and play with these benchmarks in their own environment, to draw their own conclusions.

There is also an ongoing discussion on SO => https://stackoverflow.com/questions/79268109/c-implementatio...

The GitHub for the project is at https://www.github.com/coralblocks/CoralBench

You can find all the results and code in our GitHub repository => https://github.com/coralblocks/CoralBench?tab=readme-ov-file...

The goal of this research is to explore the performance differences between JIT (just-in-time compilation) and AOT (ahead-of-time compilation) strategies and to understand their respective advantages and disadvantages. The intent is not to claim that one language is slower or worse than the other.

In our tests, we observed better results with the HotSpot JVM 23 using JIT compilation. We got slower results with C++ (compiled with Clang 18), GraalVM 23 (compiled with native-image), and HotSpot JVM 23 with the -Xcomp flag. We are seeking to understand why this happens, and if possible, identify ways to improve the performance of the C++ version to match the results of Java's JIT compilation.

Our benchmark involves comparing a hash table (map) implementation in Java to an equivalent implementation in C++. We made every effort to ensure consistency between the two implementations, but it’s possible that some nuances were overlooked.

The hash table implementation itself is simple, and we aimed to make the Java and C++ code as equivalent as possible, including how memory is managed. For instance, we ensured that the C++ hash table values are stored by reference, not by value, to avoid unnecessary copying.

The benchmark creates a hash table with 5,000,000 buckets and inserts 10,000,000 objects, minimizing collisions. The linear search in each bucket is kept to a maximum of two iterations to avoid discrepancies in measurements due to varying collision behavior across different elements.

The Bench class, which handles the measurements, should also be equivalent in both implementations.

Given these details, does anyone have insights into why the C++ version of the benchmark was slower than the Java version? Could there be something we overlooked or an aspect of the C++ implementation that could be optimized further? Perhaps specific Clang optimization options we should explore?

The link to the project is here => https://github.com/coralblocks/CoralBench?tab=readme-ov-file...

If you don't mind suggesting a better title I'll be happy to change it

Do you know a trustworthy source where I can compare single thread performance of M3s and M4s?

I thought they were trustworthy but I can be wrong. Where is the screaming text in what site that you are referring to?

Agree! But how about the M3 8 Core (4754) beating the M4 Max 14 Core (4614)? I thought the M4s were faster than the M3s (single core / single thread), but it looks like they will only be faster on multi core / multi thread benchmarks. I would think that the sheer speed of a CPU is the single core / single thread performance number.

According to CPUBenchmark.net the M3 Max 16 Core is the fastest single thread cpu with a score of 4,785, followed by the M3 Max 14 Core with a score of 4,771.

Although the numbers above are close, it does not make much sense to me that a chip with more CPUs will be faster on single thread performance than the same chip with less CPUs. But I can be wrong.

Also, according to their list, even the M3 8 Core beats the M4 chips (Pro and Max included). Again on single thread performance. Am I missing something?

Am I missing something or the M3 for single thread performance is faster than the M4?

I can't emphasize enough that I'm only talking about single thread performance here.

I see. Sorry about that. Won't be putting any more comments in the title. Thanks for your guidance.

I HAVE NOW CHANGED THE TITLE => Thanks again!

Sorry about that. I'm new here. Would you be so kind as to tell me what I did wrong? I'll be happy to correct it and learn not to do it again.

Their official benchmarks => https://www.cpubenchmark.net/singleThread.html

According to PassMark CPU Benchmarks, a trusted source, updated frequently, the M3 Max 16 Core is the fastest single thread cpu with a score of 4,785, followed by the M3 Max 14 Core with a score of 4,771.

Although the numbers above are close, it does not make much sense to me that a chip with more CPUs will be faster on single thread performance than the same chip with less CPUs. But I can be wrong.

Also, according to this list, even the M3 8 Core beats the M4 chips (Pro and Max included). Again on single thread performance.

Am I missing something or the M3 for single thread performance is faster than the M4?

I can't emphasize enough that I'm only talking about single thread performance here.

You were interested in the diamond queue, so just wanted to say that it is now released in our GitHub => https://github.com/coralblocks/CoralQueue?tab=readme-ov-file...

You are going to block/wait yourself when availableToPoll() (now changed to availableToFetch() for clarity) returns 0. When that happens you can block/wait by busy spinning or by using a wait strategy. The blocking term means that the producer has to block/wait when the ring is full and the consumer has to block/wait when the ring is empty.

For the non-blocking ring, the producer never blocks on a full ring. It overwrites the circular ring. The consumer can still block on an empty ring.

So to make it clear:

Blocking ring => producer and consumer can block/wait

Non-Blocking ring => producer never blocks and consumer can still block on an empty ring. Consumer can also fall behind too much and disconnect.