Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dispatcher object to callbacks to coordinate sampler outputs #3334

Closed
wants to merge 65 commits into from

Conversation

mitzimorris
Copy link
Member

@mitzimorris mitzimorris commented Mar 4, 2025

Submission Checklist

  • Run unit tests: ./runTests.py src/test/unit
  • Run cpplint: make cpplint
  • Declare copyright holder and open-source license: see below

Summary

Implement proposals in design-doc 32: https://github.com/stan-dev/design-docs/blob/master/designs/0032-stan-output-formats.md, starting by adding a dispatcher class to the stan::callbacks namespace.

Intended Effect

  • Simplify current stan::services APIs by replacing multiple output file arguments with a single dispatcher arg
  • Allow for more different outputs.

How to Verify

unit tests

Side Effects

??

Documentation

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):

Columbia University

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

@mitzimorris
Copy link
Member Author

clang auto-formatting is introducing errors for the linter.
cf this:

cef5f2b

@mitzimorris
Copy link
Member Author

here is a chat I've been having with Claude 3.7 about how the in-memory sample could be accessed by R and Python.
https://claude.ai/share/a4907ccd-7665-40bf-baa0-a240606b6bce

@stan-buildbot
Copy link
Contributor


Name Old Result New Result Ratio Performance change( 1 - new / old )
arma/arma.stan 0.33 0.31 1.06 5.99% faster
low_dim_corr_gauss/low_dim_corr_gauss.stan 0.01 0.01 0.94 -6.88% slower
gp_regr/gen_gp_data.stan 0.02 0.02 1.01 0.79% faster
gp_regr/gp_regr.stan 0.09 0.09 1.06 5.65% faster
sir/sir.stan 70.13 67.72 1.04 3.43% faster
irt_2pl/irt_2pl.stan 4.15 4.01 1.04 3.39% faster
eight_schools/eight_schools.stan 0.06 0.05 1.01 1.19% faster
pkpd/sim_one_comp_mm_elim_abs.stan 0.25 0.24 1.03 3.33% faster
pkpd/one_comp_mm_elim_abs.stan 19.55 19.56 1.0 -0.08% slower
garch/garch.stan 0.43 0.44 0.97 -2.97% slower
low_dim_gauss_mix/low_dim_gauss_mix.stan 2.74 2.6 1.05 5.1% faster
arK/arK.stan 1.81 1.73 1.04 4.17% faster
gp_pois_regr/gp_pois_regr.stan 2.87 2.74 1.05 4.44% faster
low_dim_gauss_mix_collapse/low_dim_gauss_mix_collapse.stan 8.68 8.4 1.03 3.22% faster
performance.compilation 183.7 180.39 1.02 1.8% faster
Mean result: 1.0233386108928109

Jenkins Console Log
Blue Ocean
Commit hash: 41fb879c2b057722f0b8d4e3462ddede193cb95e


Machine information No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal

CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 80
On-line CPU(s) list: 0-79
Thread(s) per core: 2
Core(s) per socket: 20
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Stepping: 4
CPU MHz: 2400.000
CPU max MHz: 3700.0000
CPU min MHz: 1000.0000
BogoMIPS: 4800.00
Virtualization: VT-x
L1d cache: 1.3 MiB
L1i cache: 1.3 MiB
L2 cache: 40 MiB
L3 cache: 55 MiB
NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78
NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Mitigation; IBRS
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke md_clear flush_l1d arch_capabilities

G++:
g++ (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Clang:
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

@WardBrian
Copy link
Member

Is there a design goal you have in mind for that which isn't answered by something like the existing code in tinystan?

In a bigger picture sense, I'm not sure that this would make sense to live in the Stan repo as opposed to a consumer (like tinystan or a future cmdstan-derived thing). I think focusing on what the API would look like (e.g. the router class, new sets of base classes, or improved services) is more important than on any specific instantiation of it (e.g. something that derives from one of the new base classes and stores its results in a buffer) at this point


Asides on Claude:

Own its memory: The buffer should be allocated and managed by Stan

I can't see the files you provided as input to the model, but I'm guessing this is some AI-"yes-man" behavior where it doesn't seek to criticize. This is in fact a very difficult design to make work compared to the allocation happening externally. It is a general requirement that allocations and deallocations happen in the same library/module (especially if you want any hope of working on Windows, where we don't compile against the same libc as Python would), which also means that handing long-lived pointers between modules is fraught in general. Especially when one side is garbage collected, it is usually infinitely easier to have that side be in charge of memory that needs to be shared between them, otherwise you will end up with use-after-frees, double-frees, or lots of additional copy operations.

One way to see this is to think about RAII and where the eigen matrix you're storing the draws in would get freed by C++. If you wrote wrapper calls to services like cmdstan does that create these in function scope, this will be dropped at return time. So you either need to have Python manage a pointer to the entire writer, or return a copy that needs to be separately freed later. Note that placing that copy into a numpy array usually requires another copy to avoid numpy trying to free it on the wrong side of the module boundary...

This is why tinystan operates the way that it does. RStan lets R manage the memory (it gets this more or less 'for free' by using Rcpp) and Pystan writes back into python using a socket (Pystan2 was much more similar to RStan)

Languages like R/Python often want column-oriented access

This is a more minor point, but this is false. Python is largely agnostic but actually defaults to row-major.

@mitzimorris mitzimorris changed the title in-memory output of samples only add output dispatcher class to simplify services API Mar 7, 2025
@mitzimorris mitzimorris changed the title add output dispatcher class to simplify services API Dispatcher object to coordinate sampler outputs Mar 7, 2025
@mitzimorris mitzimorris changed the title Dispatcher object to coordinate sampler outputs Add dispatcher object to callbacks to coordinate sampler outputs Mar 7, 2025
@mitzimorris
Copy link
Member Author

Closing this PR.
will reopen on renamed branch.

@mitzimorris mitzimorris closed this Mar 8, 2025
@mitzimorris mitzimorris deleted the feature/in-memory-writer branch March 8, 2025 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants