Hi everyone!

I work on PerfChecker.jl, a Julia package for running repeatable performance checks and comparing results across implementations or package versions.

You define the operation to measure and how to verify its correctness. PerfChecker coordinates benchmarking, profiling and analysis tools—including BenchmarkTools, Profile.Allocs and JET—and saves the results for inspection, comparison and sharing. You can use it to investigate performance problems and prepare regression checks for CI.

I’ve put together an English tutorial series with an introduction and five chapters covering:

• Installation and a first run.
• Benchmarks, profiles and analysis tools: what they’re useful for and how to interpret their output.
• Reproducible suites, correctness checks and CI configuration.
• VS Code, terminal, Web and Pluto interfaces, plus exporting and sharing results.
• MCP advice, reviewed code changes and bounded investigations.

The walkthroughs use real interfaces and recorded results. The emphasis is on understanding what each tool tells you and choosing a useful next step.

YouTube playlist

Source code and issues

I’d appreciate feedback on getting started, interpreting results, and workloads you’d like to see covered. Questions, bug reports, documentation improvements and contributions are all welcome.

Thanks to the Julia community and the maintainers of the tools PerfChecker brings together!

(There's more to Luminal.jl than this, see the github link for more, but this post focuses on running Qwen3.8-27B)

Serve Qwen3.8-27B (GGUF)

examples/qwen35_server.jl serves a Qwen3.5 / 3.6 / 3.8 GGUF through an OpenAI-compatible API (streaming chat completions, tool calls, reasoning content), for harnesses such as opencode. Weights stay in the GGUF's own quantization on the GPU (LUMINAL_GGUF_NATIVE=1; Q4_K_XL, about 17 GB), and the model's MTP head drafts tokens for speculative decoding.

bash LUMINAL_GGUF_NATIVE=1 julia -t auto,1 --project=. examples/qwen35_server.jl \ /path/to/Qwen3.8-27B-UD-Q4_K_XL.gguf --max-seq=262144 --port=8080

• Use -t auto,1: the server needs the extra interactive thread. The HTTP tasks run on the main thread and the GPU work in a task pinned to another one; without that, nothing is streamed while a prefill or a decode step blocks the main thread.
• The first start takes a few minutes (reading the GGUF, compiling the graphs). The log prints serving ... when it is ready.
• --max-seq sets the context and the KV cache allocated up front (Float16, 64 KB per token: 17 GB at 262144). Other flags: --mtp=<gguf> (a separate file with the MTP head), --host, --name (the model id), --no-spec, --int8.
• Point the client at http://127.0.0.1:8080/v1 (GET /v1/models, GET /health, POST /v1/chat/completions). For opencode, add an @ai-sdk/openai-compatible provider with that baseURL and the --name as the model id. Long prompts can take minutes before the first token, so raise or disable its request timeouts.
• --reasoning-budget=N limits the thinking: after N reasoning tokens the server closes the <think> block with a short wrap-up and the model answers from what it has (the resume costs a re-prefill of the new turn, about 10-20 s at N = 4096). A request overrides it with thinking_budget (also thinking.budget_tokens, reasoning_budget; 0 = no limit). In opencode, put "thinking_budget": N in the model's options.
• Prompts are cached: the system prompt, each turn, and state checkpoints every 4096 tokens (LUMINAL_CKPT_EVERY), so a follow-up turn reprocesses only its new tokens. A cold prefill runs at 330-480 tok/s (about 3 minutes for 75k tokens); a warm turn answers in 3-25 s. Decode is 11-15 tok/s at 70-130k tokens of context (2.3-2.9 tokens per speculation cycle).
• It handles one request at a time, and it needs about 35-60 GB of unified memory at the largest context, depending on how many prompts are cached. The log reports prompt processing, generation speed and speculation per request.

For a one-shot generation from a GGUF, examples/qwen35_gguf.jl <file.gguf> "prompt".

https://github.com/philtomson/Luminal.jl

NOTE: right now I'm only sure that this works well on AMD Strix Halo GPUs. It might work on Nvidia GPUs via CUDA.jl, but I have not tested it.

This video shows how my molecular dynamics code is composed, and what functionality it has so far. There is also the link to GitHub to download the current version of the code, which requires Molly.jl, Chemfiles.jl and EzXML.jl

If you try the code please leave any suggestions and bugs you find here, in YouTube or in the GitHub repo.

We are launching our demo for the steam next fest now! Visit: Necro-Matcher on Steam to download and play!
I haven't posted about this on reddit yet, so here's some context: https://discourse.julialang.org/t/im-creating-the-worlds-first-commercial-game-written-in-julia

Hi everyone. I've been working on a solver for the geometric superconducting diode effect in two-gap superconductors (like MgB₂), and I just released v1.1.

It's a 3D two-band time-dependent Ginzburg–Landau solver with:

- self-consistent vector potential (so screening and self-field are part of the model)
- gauge-invariant Josephson voltmeter that counts vortex crossings
- arbitrary 3D shapes from TOML files or a browser editor
- a terminal menu to launch and track runs

v1.1 adds an implicit scheme for the Maxwell term, which gives ~3× speedup at κ=2 and ~100× at κ=25. Same onset brackets, voltages within 0.2%. A production-box run takes minutes on a laptop.

It's standard TDGL (not generalised KWT) on a Cartesian grid, and pyTDGL is better if you need unstructured 2D films. A multiband generalised version is the next step.

Repo: https://github.com/georgeotjg/juliaTDGL

Feedback and issues welcome, especially from anyone working on superconducting devices.

I've been working on contact mechanics in LowLevelFEM.jl and wanted to share a small 2D Hertz-type contact example.

One of my goals is to keep the implementation as close as possible to the mathematical weak form.

For example, the penalty contact stiffness is simply:

G = ContactGap(C)
Kc = ∫(G ⋅ cn ⋅ G; updateFrom=u)

The same contact operator can also be used in a Lagrange-multiplier formulation:

B = ∫(Λ ⋅ ContactGap(C, active=:all))

The figures show the resulting contact pressure, normal gap, and von Mises stress distribution.

The implementation handles closest-point contact detection at Gauss points and currently supports both 2D and 3D problems. I've also been working on multithreaded sparse assembly and lightweight geometry updates to reduce the cost of nonlinear iterations.

It's still a work in progress, particularly for more advanced contact laws, but the basic framework seems promising.

I'm curious how others working with FEM in Julia approach contact mechanics, especially the balance between a readable weak-form formulation and efficient contact search and assembly.

Hi everyone, I’ve been working on discrete-event simulation in Julia and wanted to share an early release of two packages: SimCore.jl and SimDES.jl. * SimCore.jl provides foundational event scheduling primitives (FutureEventList, virtual clocks, and $O(1)$-memory streaming statistics). * SimDES.jl builds on top of SimCore to model queueing networks, material handling, and physical conveyor kinematics. * GitHub: SimDES.jl | SimCore.jl

Motivation & Where This Fits in the Ecosystem

Julia already has great simulation packages, and I want to acknowledge them upfront: * If you prefer process-oriented simulation (SimPy-style coroutines with @resumable and @yield), ConcurrentSim.jl is mature and well-suited for that workflow. * If your problem revolves around agent-based modeling with complex spatial interactions, Agents.jl is the standard and far more established. * For clock-based discrete event generation, DiscreteEvents.jl offers a clean, native approach. Why SimCore and SimDES?
My work required a specific combination of needs that led me to build this framework: 1. Automated Verification Against Queueing Theory: I wanted the engine's test suite to continuously assert empirical simulation results against closed-form queueing equations ($M/M/1$, $M/M/c$, $M/M/1/K$, Pollaczek-Khinchine for $M/G/1$, open Jackson product-form networks, and Little's Law invariance). 2. Physical Conveyor Accumulation (ZPA): In material handling, items have physical dimensions and cannot overlap. I needed deterministic 1D conveyor kinematics where items queue up behind obstacles (Zero-Pressure Accumulation), observe safety gaps, and respect optical sensor interlocks without needing a heavy continuous physics engine. 3. Constant-Memory Streaming Statistics: To run long simulations without blowing up RAM, SimCore integrates single-pass Welford variance, Jain-Chlamtac $P^2$ streaming quantiles ($P{50}, P{95}, P_{99}$), and Welch moving-average warmup detection in $O(1)$ memory.

4. Decoupled Visualizations: The core engine has zero graphics dependencies, but optionally connects to Makie (CairoMakie for vector reports, or GLMakie for interactive desktop GUIs with live observable streaming).

Quick Example: M/M/1 Queue

```julia using Pkg Pkg.add(["SimCore", "SimDES"]) using SimDES, Distributions

1. Setup simulation world with an arrival source and single server

world = SimWorld() source_id = register_zone!(world, ZoneConfig(name = "Arrivals", arrival_dist = Exponential(1.0 / 2.0))) server_id = register_zone!(world, ZoneConfig(name = "Server", capacity = 1, service_dist = Exponential(1.0 / 4.0))) connect_zones!(world, source_id, server_id)

2. Run simulation

run_sim!(world; t_end = 1000.0)

3. Inspect results

stats = get_zone_stats(world, server_id) println("Utilization ρ: ", stats.utilization) # Expected ≈ 0.50 println("Mean System Time W: ", stats.mean_sojourn) # Expected ≈ 0.50 ```

There is also an interactive physical conveyor example in the repo (examples/06_interactive_conveyor_makie.jl) that demonstrates dynamic package routing, optical interlock gating, and ZPA queuing in GLMakie (an animated GIF of this is also embedded in the README).

Current Limitations & Honest Caveats

This is an early v0.1.0 release, and there are several limitations worth noting: * Early API: While the underlying queueing math passes all automated test suites, the public API may still evolve as we receive feedback. * Paradigm: It is based on explicit event scheduling and state transitions rather than coroutine-based yielding. If your mental model relies heavily on SimPy-style generators, ConcurrentSim.jl might feel more natural.

* Documentation: More work towrads tutorials and real-world industrial case studies is required .

Feedback Welcome!

If you work in operations research, queueing theory, industrial engineering, or discrete-event modeling, I would be very grateful if you could try running your models or take a look at the code. Any feedback, critique of the API design, bug reports, or feature suggestions on our GitHub Issues would be immensely appreciated. Thank you!

I am finally able to do MD on a peptide. This does not mean that all parameters are correctly assigned, still some work to be done, but at least the program can assign most of the atom types present in this molecule. Very happy about this small milestone!

I have been building a book of advanced mathematics where every formula keeps its originator's name on the page. The part that might interest people here is that no result in it is allowed to be a picture. Each one has to come with a small Julia program that recomputes it, and the nine machines are in the repo under site/machines.

They are:

- galaxy_rotation.jl, rotation curves against the visible mass

- eddington.jl, the luminosity where radiation pressure balances gravity

- jeans_mass.jl, the mass at which a cloud collapses

- schechter.jl, the galaxy luminosity function

- hubble_tension.jl, the two measurements of H0 that will not agree

- three_body.jl, the figure eight orbit

- lorenz.jl, because it is the honest example

- phyllotaxis.jl, the golden angle in a sunflower

- rubik_group_order.jl, the cube group at 43,252,003,274,489,856,000

Each one is standalone, no package, runs from a terminal, and prints what it claims with the numbers attached. The rule i set myself is that a plate ships only if its machine reproduces the number on the page.

I would genuinely like review on the numerical choices: tolerances on the three body integrator, whether the Schechter fit should carry its errors on the page, and whether the cube group order should be a computation or a lookup. Repo is at github.com/Mascottz/Codex-Naturalis, machines are the only folder you need.

I have been improving the functionality of my JuliaMD program, and made a routine to detect aromatic rings. I also added more atom types which can be detected and assigned GAFF types, so more types of molecules can be simulated.

Small update of my project of molecular dynamics with Julia (2 min Video)

https://youtube.com/shorts/6kZmMTnoI_0?feature=share

I'm doing an assignment, and I need help with basically everything. My code refuses to run in Julia, it just comes out blank. For context, I have never ever coded in my life, and our lecturer didn't teach us anything, it is also not in our curriculum. I'm very lost. If you are norwegian that would help a lot more.

Other info I was provided before the code is(translated with google translate):

Here is the recipe for another variant of the Fibonacci numbers that allows for randomness. To calculate each number, a random number (r) is first drawn from [0, 1]. If r < 0.2 (we call the number 0.2 the threshold value(tv) here) and we have generated at least three numbers in the F-vector, we use the update F(k) = F(k − 1) – F(k − 3). Otherwise (i.e. if r >= 0.2) the next number is calculated using the usual Fibonacci rule F(k) = F(k-1) + F(k – 2).

and that after the code was done being filled out then we are supposed to use this

n = 20;
V = Fibonacci_vri(n)
println(V)


using Plots
plot(V, label="", xlabel = "steg", ylabel = "F")

I was provided with a code that wasn't finished yet, so I filled in the blanks which is k >= 3, F[k] = F[k-1] - F[k-3], F[k] = F[k-1] + F[k-2] and return F This is what I tried to run:

function Fibonacci_vri(n)
    tv = 0.2;
    F = zeros(Int, n)
    F[1] = 1;
    F[2] = 1; 
    for k = 3:n
        r = rand();
        if r < tv && k >= 3
            F[k] = F[k-1] - F[k-3];
        else
            F[k] = F[k-1] + F[k-2];
        end
    end
    return F

n = 20;
V = Fibonacci_vri(n)
println(V)


using Plots
plot(V, label="", xlabel = "steg", ylabel = "F")

Hello guys,

I am a PhD student, my research field relies a lot in optimization.

I would like to ask about a possible framework, I mean, if it makes sense technically. What is the actual viability and how can I perform it.

Basically my framework is:

1. Check if elements (numbers between 1 to 1e20) belongs to a list (~10 million elements). In matlab I use "unique" function. I would like to setup a bloom filter and maybe make viable to perform it in parallel;

2. Perform a lot of rng sampling in batch, linear mapping and logical tests (this is simple and must be easily done);

3. Send instructions of how to assemble the constraints of the LP to each core of the cpu;

4. Call a solver based in simplex (LP solver, usually I use gurobi) for each core of the cpu in an instanced rng stream, so I don't mess up the step 2;

5. Meanwhile send a matrix (1e3 x 1e5), for GNN evaluation, to GPU so it can process it and return the output for the ram;

6. After the asynchronous evalution in parallel (GPU should be faster than CPU evaluation), the algorithm goes to step 1.

There is a possibility to call to a python routine instead to perform the GNN evaluation. Can Julia do this ? Basically the asynchronous evaluation in parallel and possibly call an external routine in python?

Thanks in advance and I apologize if there is a lacking of technical precision in my questions. I use computation as a tool, I have little expertise in this field. Please ask if I need to clarify something.

I'd like to show you ProjecturEd, a projectional editor I've been working on.

It's an application to view and edit structured data. You can define your own data structures and your own views for them. They work together with the domains that come with it, like JSON, Markdown, Julia code, widgets and charts. An AI assistant works with you on the same data and the same views. You can also use it as a user interface for your own Julia programs.

It's not yet finished, but most of it works. I think it's ready to show, and I'd like to get some feedback.

So, I started ProjecturEd in Common Lisp in 2013 (a long-long time ago) as a side project. I was interested in editing structured data because almost always it ends up as editing text. I wanted to look at and change the structured data itself using the keyboard and mouse. Now, thanks to AI software development is entirely different now. I created the Julia version (in 4 months part-time) for a new port of a well known and widely used discrete event communication network simulator (OMNeT++). It's a complete rewrite, with many more domains, more backends and the AI assistant built-in from the ground-up.

Here is a demo video, where a local AI agent builds a study of an M/M/1/K queue from seven user requests using the application's internal API. It writes the model and the formulas, runs OMNeT++ simulations, plots the results and finds the answer. The model is qwen3.8:27b in Ollama, on my machine. The OMNeT++ tool in the video is built on ProjecturEd, but its code is not public.

https://projectured.org/assets/videos/queue-study.mp4

Here is how it works, in short. The structured data is the source, and every view is computed from it. A projection (a composite one) turns the structured data into a view. It also turns your edits in the view back into typed operations on the structured data. Projections can be combined in many ways e.g. chaining, recursively, type dispatching. For example JSON goes to syntax recursively, then from syntax to text recursively, then to graphics. Many other combinations and mixtures are possible. Every data structure field is a reactive cell, the editor is lazy and incremental. A computed value stays until something it depends on changes. What's not on the screen is not computed, and a view never shows stale data.

The most important part for me is that you can add your own domain. A domain is a package with its document types, projections, operations and key bindings. Navigation, search, copy and paste, sorting, filtering, files, mixing with other domains, all the backends and the assistant work with it, with little or no extra code. The whole JSON domain is a few hundred lines. The web page shows how it's built.

The assistant runs Julia code inside the editor, so it uses the same API as you do. It can search the API by name, by pattern or by meaning. It can also open tabs and arrange the window. You can undo its changes with Ctrl+Z, like your own. By default it uses a local model through Ollama, but it also works with Claude. Other AI tools can use the same tools through MCP. Note that it's not a sandbox, and the MCP server has no authentication. Please don't run it on a shared machine.

ProjecturEd also comes with its own Julia REPL. You open it in a tab and type Julia, like in the normal REPL. But a result that is a viewable data structure or a picture shows as itself, not as text. And you can edit it right there.

• Web page with more videos: https://projectured.org
• Code and guides: https://github.com/projectured/projectured-julia

I'm happy to answer any questions.

For the past months, I’ve been designing an open-source project called O.N.E. (Open Networked Earth). It’s an economic framework designed for a post-labor world where robotics and automation produce our basic necessities.

Instead of using fiat money, the economy is coordinated using physical conservation laws: solar kilowatt-hours, liters of clean water, and crop yields.

To test if this actually works (or if it collapses), I (with AI help)wrote the formal specifications for a discrete-event co-simulation engine codenamed SIMONE.

The simulation needs to model:

• Physical substrate: Hourly solar irradiance and hydrology using open satellite data.
• Technical assets: Pumps, solar panels, and inverters that suffer wear-and-tear and need spare parts.
• Heterogeneous human agents: Thousands of individual citizens with different behaviors (cooperators, free-riders, informal barterers).
• Governance rules: Rotating citizen juries making resource allocation decisions.

I initially looked at Python (Mesa), but running thousands of distinct agents with complex decision-making alongside physical equations might quickly hits a performance wall.

AI pointed me toward Julia and the Agents.jl ecosystem as the gold standard for high-performance scientific modeling.

I’ve completed the system architecture, constitutional logic, and an initial web prototype, but I’m looking for experienced Julia developers and modelers who would like to:

Help review the simulation specifications.

Advise on whether Agents.jl + DifferentialEquations.jl is the right stack for this.

Potentially collaborate on building the open-source engine (AGPL-3.0, 100% non-commercial, zero crypto/tokens).

For those working with multi-agent systems in Julia: what architectural pitfalls should I watch out for when coupling physical differential equations with discrete human agent behaviors?

Hi, I'm just wonderin what others thing before I make a bug report/pr. I'm a noob, so i swear i should be missing something

Why wouldn't failed regex's return the equivalent of match(r"", my_string)? (This returns a 0 length substring match at location 0 - the internal C PCRE2 thing is a null pointer with those fields basically).

This would stop the whole set of functions from returning Union{Nothing, <whatever>}, and make things checkable after as well as on calling it (Currently you always need to check before accessing a field). As well as juicy typesafe trimmed static compilation

Of course it should not break existing code, but that could be fixed by defining isnothing( RegexMatch("") ) = true

edit: I'm wrong. unions are typesafe

Hey everyone, I’ve been experimenting with seismic imaging in Julia and CUDA.jl. I built a 2D model that sends waves through rock layers, records the echoes, and reconstructs the layer boundary using reverse-time migration.

I also compared several GPU kernels. On my Quadro RTX 8000, the straightforward coalesced kernel beat both shared-memory tiling and a register window.

article

code and benchmarks

We have been working on finishing several small twirls and bugs in Manopt recently. We have had a roadmap for a while already at

https://github.com/JuliaManifolds/Manopt.jl/issues/297

so if you are using Manopt.jl or consider using it and have points you would like to see included, now is a good time to either comment on that issue or open new issues we can add to the list.

Hi everyone!

We are three Oil & Gas Engineering students from Institut Teknologi Sumatera (ITERA), Indonesia, and for our university capstone project we decided to do something slightly unusual:

build a database engine in Julia.

The project is called AiresDB.

It originally started because we wanted a database engine for our final Oil & Gas coursework, but the project gradually became much larger than we expected. We eventually decided to make it open source so other students, study programs, or anyone interested could use it, study it, modify it, and hopefully improve it with us.

AiresDB currently has:

- an Indonesian-inspired query language called AiresQL

- ACID transactions with WAL and recovery

- MVCC with serializable conflict detection

- 8 KiB page-based storage

- slotted pages and RIDs

- a persistent B+Tree

- a buffer pool

- a small query planner and relational executor

- an HTTP/JSON server

- support for Windows and Linux

We also built reproducible tests and benchmarks because we wanted to understand whether what we were building actually worked rather than just being able to run a few queries.

But we are still students, and honestly, building a database engine has been much harder than we expected.

There are areas such as storage concurrency, query optimization, indexing, recovery, and systems programming where people in this community almost certainly have much more experience than we do.

We have also used AI tools during development for learning, debugging, reviewing ideas, and exploring implementations. We do not want to pretend that we understand every design decision perfectly, which is one of the reasons we are sharing AiresDB here.

We would really appreciate technical criticism.

If something in the architecture looks wrong, unnecessarily complicated, unsafe, un-Julian, or could simply be designed better, please tell us.

We are also looking for contributors.

If database internals, Julia systems programming, storage engines, query optimizers, testing, documentation, or even breaking databases sounds interesting to you, we would be very happy to work with you.

AiresDB is currently released under the permissive University of Illinois/NCSA Open Source License.

GitHub:

https://github.com/aires-id/AiresDB

This is still a technical preview, not something we would recommend for critical production data yet.

Thanks for taking a look. Criticism, questions, ideas, issues, and pull requests are all very welcome.

I want to give VS Code AI Agent access to VS Code Julia Terminal.

And created VS Code extension that patches standard Julia VS Code extension https://github.com/al6x/julia-bridge

Ideally something like that should be part of standard Julia VS Code extension.

Ideas to improve/simplify welcomed.

P.S.

Also here's AI instructions how to use it

Don't run Julia unless explicitly asked, and never start a fresh process. Use static inspection by default. When asked,
run `/projects/julia-bridge/client.js --timeout 120 'code'` from the project root. It uses the existing VS Code REPL,
returns JSON, and interrupts Julia on timeout or Ctrl-C.


For nontrivial work, replace the body of `AgentEval.run()` in `./AgentEval.jl`, then evaluate
`import AgentEval; agent_result = Base.invokelatest(AgentEval.run)`. Revise reloads it before each request. After
changing `const` or `struct` definitions, explicitly run `Revise.revise(AgentEval)`. Return compact values, preferably
named tuples, and use files for large output. Use plain code and
don't use `eval` to monkey-patch package methods.

Hey everyone,

I just updated from Julia 1.12.7 to Julia 1.13 and noticed a significant degradation in Tsetlin.jl (https://github.com/BooBSD/Tsetlin.jl) inference performance.

On the same hardware and with the same benchmark, performance dropped from about 38.4 million MNIST predictions/sec to 33.4 million predictions/sec, roughly a 13% slowdown.

I don't use any third-party packages—only the Julia standard library.

Does anyone know what might be causing this regression or how I could investigate/fix it?

Julia-1.12.7 benchmark:

boo@rig:~/Tsetlin.jl$ julia -O3 -t auto examples/MNIST/mnist.jl 
Loading model from /tmp/tm.tm... Done.

CPU: AMD Ryzen 9 7950X3D 16-Core Processor
Running in 32 threads.
Input vector size: 784 bits. Density: 16.36%
Average clause literal density: 12.19%. Using literals index: false.
Preparing input data for benchmark... Done. Elapsed 17.942 seconds.
Warm-up started... Done. Elapsed 8.354 seconds.
Benchmark for TMClassifier model started... Done.
320000000 predictions processed in 8.331 seconds.
Performance: 38410229 predictions per second.
Throughput: 4.865 GB/s.
Input data size: 40.531 GB.
Parameters during training: 313600.
Parameters after training and compilation: 38237.
Accuracy: 98.11%.

Julia-1.13 benchmark:

boo@rig:~/Tsetlin.jl$ julia -O3 -t auto examples/MNIST/mnist.jl 
Loading model from /tmp/tm.tm... Done.

CPU: AMD Ryzen 9 7950X3D 16-Core Processor
Running in 32 threads.
Input vector size: 784 bits. Density: 16.36%
Average clause literal density: 12.19%. Using literals index: false.
Preparing input data for benchmark... Done. Elapsed 17.515 seconds.
Warm-up started... Done. Elapsed 9.557 seconds.
Benchmark for TMClassifier model started... Done.
320000000 predictions processed in 9.576 seconds.
Performance: 33417915 predictions per second.
Throughput: 4.233 GB/s.
Input data size: 40.531 GB.
Parameters during training: 313600.
Parameters after training and compilation: 38237.
Accuracy: 98.11%.