chaokunyang

no profile record

Submissions

Apache Fory Serialization 1.2.0: JDK 25 support without sun.misc.Unsafe

1 pointsby chaokunyangil y a 25 jours1 comments

Apache Fory C++: 10x faster serialization than protobuf

fory.apache.org

4 pointsby chaokunyangil y a 4 mois2 comments

Extend Protobuf/FlatBuffers Schema IDL with Shared/Circular Reference Support

fory.apache.org

1 pointsby chaokunyangil y a 4 mois3 comments

Show HN: First IDL for Object-Graph Serialization (Apache Fory IDL)

fory.apache.org

1 pointsby chaokunyangil y a 4 mois2 comments

Show HN: Fory C++ Serialization – Polymorphism, Circular Refs, 12x vs. Protobuf

fory.apache.org

3 pointsby chaokunyangil y a 5 mois1 comments

Show HN: Browser Terminal Use – run local CLI/agent loops in browser terminals

2 pointsby chaokunyangil y a 5 mois1 comments

Show HN: Browser Terminal Use – A Local-to-Cloud Execution Bridge for LLM Agents

1 pointsby chaokunyangil y a 5 mois0 comments

Trillion‑Scale RL in Real Time: Awex Delivers Second‑Level Weight Updates

2 pointsby chaokunyangil y a 8 mois2 comments

Show HN: Apache Fory Rust – 10-20x faster serialization than JSON/Protobuf

fory.apache.org

67 pointsby chaokunyangil y a 9 mois59 comments

Apache Fory Rust – Polyglot serialization with trait objects and circular refs

fory.apache.org

5 pointsby chaokunyangil y a 9 mois1 comments

comments

il y a 25 joursdiscuss

Apache Fory 1.2.0 is out.

The main Java change is JDK 25 support without using sun.misc.Unsafe in the active runtime path. Older JDKs keep the existing fast path, while JDK 25+ uses replacement implementations based on supported JVM APIs.

Other notable changes:

- Java 9/16 module-info generation

- JDK 26+ final field deserialization support even when --illegal-final-field-mutation=deny

- compatible scalar field reads for schema evolution, e.g. int64 <-> String when the conversion is lossless

- generated gRPC service companions across Java, Rust, Go, Kotlin, Scala, C#, Python, and JavaScript/TypeScript - compatible-mode and row-format performance work

Feedback from people testing serialization libraries on newer JDKs or dealing with Unsafe removal would be useful.

il y a 4 moisdiscuss

1. 10X faster serialization than protobuf c++ 2. Shared/Circular reference tracking Support 3. Polymorphism and tagged union support 4. Schema evolution support 5. idiomatic domain object API

il y a 4 moisdiscuss

Flatbuffer Example:

namespace demo;

table Node {

  parent: Node (fory_weak_ref: true);

  children: [Node] (fory_ref: true);

  cached: Node (fory_ref: true, fory_thread_safe_pointer: false);

}

il y a 4 moisdiscuss

Protobuf Example:

syntax = "proto3";

message TreeNode {

  TreeNode parent = 1 [(fory).weak_ref = true];

  repeated TreeNode children = 2 [(fory).ref = true];

}

il y a 4 moisdiscuss

If you already have .proto or .fbs schemas and you want shared/circular reference support, with the Fory compiler you can keep those schemas, add a small set of Fory options, then foryc generates idiomatic native models across Fory-supported languages

With fory first-class object graph serialziation support, you can serialize object graphs without manual *_id link reconstruction or rewriting your entire schema into Fory Schema.

1. GitHub: https://github.com/apache/fory

2. Compiler docs: https://fory.apache.org/docs/compiler

il y a 4 moisdiscuss

Tiny Schema demo

message Customer { string id = 1; string name = 2; }

message Order {

  string order_id = 1;

  ref Customer customer = 2;

  list<string> items = 3;

}

il y a 4 moisdiscuss

1. Docs https://fory.apache.org/docs/compiler

2. GitHub https://github.com/apache/fory

3. Benchmarks https://github.com/apache/fory/tree/main/docs/benchmarks

il y a 5 moisdiscuss

Fory C++ serialization blog: https://fory.apache.org/blog/fory_cpp_blazing_fast_serializa...

il y a 5 moisdiscuss

This project is for running local CLI/agent loops on macOS/Linux/Windows while executing commands inside browser-hosted terminals for cloud servers. The key goal is output/exit-code parity so local automation can trust remote runs.

il y a 8 moisdiscuss

GitHub Repo: https://github.com/inclusionAI/asystem-awex

il y a 8 moisdiscuss

Awex is a weight synchronization framework between training and inference engines designed for ultimate performance, solving the core challenge of synchronizing training weight parameters to inference models in the RL workflow. It can exchange TB-scale large-scale parameter within seconds, significantly reducing RL model training latency. Main features include: Blazing synchronization performance: Full synchronization of trillion-parameter models across thousand-GPU clusters within 6 seconds, industry-leading performance; Unified model adaptation layer: Automatically handles differences in parallelism strategies between training and inference engines and tensor format/layout differences, compatible with multiple model architectures; Zero-redundancy Resharding transmission and in-place updates: Only transfers necessary shards, updates inference-side memory in place, avoiding reallocation and copy overhead; Multi-mode transmission support: Supports multiple transmission modes including NCCL, RDMA, and shared memory, fully leveraging NVLink/NVSwitch/RDMA bandwidth and reducing long-tail latency; Heterogeneous deployment compatibility: Adapts to co-located/separated modes, supports both synchronous and asynchronous RL algorithm training scenarios, with RDMA transmission mode supporting dynamic scaling of inference instances; Flexible pluggable architecture: Supports customized weight sharing and layout behavior for different models, while supporting integration of new training and inference engines. GitHub Repo: https://github.com/inclusionAI/asystem-awex

il y a 8 moisdiscuss

I also did a benchmark with dill, it shows that: fory is 20~40X faster and up to 7x higher compression ratio compared to dill. I don't dive into dill to see how it works. Here is my benchmark code:

https://github.com/chaokunyang/python_benchmarks

il y a 8 moisdiscuss

Yes, you are right. I missed this when I wrote the benchmark code. I will update the benchmark code and share the results here

il y a 8 moisdiscuss

I understand your concern. Personally, I’m open to using AI as part of the development process, but the majority of the code in this repository has been written manually and carefully reviewed.

The AGENTS.md file was added only recently. Its original purpose wasn’t to hand code generation entirely to an AI, but rather to use AI as a pair‑programming debugger — for example, having it walk through tricky binary parsing issues byte‑by‑byte. Serialization in a compact binary format can be hard to debug, and AI can sometimes save hours by quickly pinpointing structural mismatches.

That said, serialization is a fundamental piece of infrastructure, so we remain conservative: any AI‑assisted changes go through the same rigorous review and test process as everything else. As technology evolves, I think it’s worth exploring new tools — but with care.

il y a 8 moisdiscuss

You mean this file? https://github.com/apache/fory/blob/main/AGENTS.md

il y a 9 moisdiscuss

I liked the name “Fury” too — I actually named it myself and was really fond of it, but unfortunately we had to change it.

il y a 9 moisdiscuss

DOP is great, but there’s always a gap between DOP and OOP. That gap is where Fory comes in. Right now, Fory takes an OOP‑first approach, but next we’ll add a DOP path by introducing an optional IDL — bridging the two styles. My goal is for the IDL to also support optional OOP‑style expressiveness, so teams can choose the balance that fits their needs.

il y a 9 moisdiscuss

DOP is great for certain scenarios, but there’s always a gap between DOP and OOP. That gap is where an extra domain model and the conversion step come in — especially in systems that rely heavily on polymorphism or want to keep serialization types decoupled from core business models.

il y a 9 moisdiscuss

The Rust benchmarks in Fory are intended more as end‑to‑end benchmarks for typical OOP‑style application scenarios, not just raw buffer write speed.

Protobuf is very much a DOP (data‑oriented programming) approach — which is great for some systems. But in many complex applications, especially those using polymorphism, teams don’t want to couple Protobuf‑generated message structs directly into their domain models. Generated types are harder to extend, and if you embed them everywhere (fields, parameters, return types), switching to another serialization framework later becomes almost impossible without touching huge parts of the codebase.

In large systems, it’s common to define independent domain model structs used throughout the codebase, and only convert to/from the Protobuf messages at the serialization boundary. That conversion step is exactly what’s represented in our benchmarks — because it’s what happens in many real deployments.

There’s also the type‑system gap: for example, if your Rust struct has a Box<dyn Trait> field, representing that cleanly in Protobuf is tricky. You might fall back to a oneof, but that essentially generates an enum variant, which often isn’t what users actually want for polymorphic behavior.

So, yes — we include the conversion in our measurements intentionally, to reflect the real‑world large systems practices.

il y a 9 moisdiscuss

DOP is very interesting, I like this idea too — most DOP approaches are implemented via an IDL, which is another valid direction. I plan to support that in Fory. I want to give users the freedom to choose the model that works best for them.