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

fix data to use managed memory instead of naked pointer #96

Merged
merged 1 commit into from
Jun 15, 2024

Conversation

cometkim
Copy link
Contributor

@cometkim cometkim commented May 1, 2024

as following ocaml/ocaml#13141

I tried to fix it but let me ask if this doesn't ruin your intentions.

@cometkim cometkim changed the title fix memory management to use managed memory instead of naked pointer fix data to use managed memory instead of naked pointer May 1, 2024
@dmtrKovalenko
Copy link
Owner

dmtrKovalenko commented May 1, 2024

Thanks for your investigation I been to dive into this.

Did you try to run benchmarks for this? And also measure GC stats in the end comparing to the main branch?

@cometkim
Copy link
Contributor Author

cometkim commented May 1, 2024

Did you try to run benchmarks for this? And also measure GC stats in the end comparing to the main branch?

I'm not sure if I did it right, but it doesn't seem to make a noticeable difference on a simple usecase.

❯ hyperfine -i './odiff-main.exe images/donkey.png images/donkey-2.png 2>/dev/null' './odiff-fix.exe images/donkey.png images/donkey-2.png 2>/dev/null'
Benchmark 1: ./odiff-main.exe images/donkey.png images/donkey-2.png 2>/dev/null
  Time (mean ± σ):     203.9 ms ±   1.7 ms    [User: 125.9 ms, System: 77.3 ms]
  Range (min … max):   202.0 ms … 207.6 ms    14 runs

  Warning: Ignoring non-zero exit code.

Benchmark 2: ./odiff-fix.exe images/donkey.png images/donkey-2.png 2>/dev/null
  Time (mean ± σ):     204.1 ms ±   0.6 ms    [User: 132.7 ms, System: 71.3 ms]
  Range (min … max):   203.0 ms … 205.1 ms    14 runs

  Warning: Ignoring non-zero exit code.

Summary
  ./odiff-main.exe images/donkey.png images/donkey-2.png 2>/dev/null ran
    1.00 ± 0.01 times faster than ./odiff-fix.exe images/donkey.png images/donkey-2.png 2>/dev/null

Are there any scenarios where GC can be critical?

@cometkim
Copy link
Contributor Author

cometkim commented May 1, 2024

If the intention is to use the codec's buffer as is, I think a completely different approach is also possible.

Instead of copying the buffer into a bigarray, create a custom block pointer and register the finalizer on it. Although odiff will be less dependent on OCaml, it will boot faster with less copying.

Either way, it will have roughly the same lifetime as the program, so major GC (of the image data) will occur rarely I guess.


Note: This change should not trigger additional GC, it just moves the buffer's location.

@gasche
Copy link

gasche commented May 2, 2024

I didn't review the details but the change broadly matches what I had in mind. Did you manage to test that the project now works with OCaml 5 ?

@cometkim
Copy link
Contributor Author

cometkim commented May 2, 2024

Yep, i tested it for work with OCaml 5 in my branch https://github.com/cometkim/odiff/tree/ocaml5

@cometkim
Copy link
Contributor Author

cometkim commented May 3, 2024

btw the OCaml 5 build is about 10% larger (5_148_720 -> 5_725_304 bytes)

perf is not changed

❯ hyperfine --warmup 3 -i './ODiffBin-main images/water-4k.png images/water-4k-2.png 2>/dev/null'  './ODiffBin-ocaml5 images/water-4k.png images/water-4k-2.png 2>/dev/null'

Benchmark 1: ./ODiffBin-main images/water-4k.png images/water-4k-2.png 2>/dev/null
  Time (mean ± σ):      1.003 s ±  0.011 s    [User: 0.779 s, System: 0.223 s]
  Range (min … max):    0.993 s …  1.024 s    10 runs

  Warning: Ignoring non-zero exit code.

Benchmark 2: ./ODiffBin-ocaml5 images/water-4k.png images/water-4k-2.png 2>/dev/null
  Time (mean ± σ):      1.016 s ±  0.007 s    [User: 0.792 s, System: 0.222 s]
  Range (min … max):    1.010 s …  1.032 s    10 runs

  Warning: Ignoring non-zero exit code.

Summary
  ./ODiffBin-main images/water-4k.png images/water-4k-2.png 2>/dev/null ran
    1.01 ± 0.01 times faster than ./ODiffBin-ocaml5 images/water-4k.png images/water-4k-2.png 2>/dev/null

Copy link
Owner

@dmtrKovalenko dmtrKovalenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally I've got some time to investigate and play around with this change. I think is pretty nice and thank you for diving into this!

@dmtrKovalenko dmtrKovalenko merged commit 05447f4 into dmtrKovalenko:main Jun 15, 2024
5 checks passed
@cometkim cometkim deleted the memory-mgnt branch June 15, 2024 13:18
@cometkim
Copy link
Contributor Author

Great! Migrating to OCaml 5 is now very simple.

I haven't tried parallelization yet, but I guess it shouldn't be too difficult. Considering the anti-aliasing feature, some pixels may be processed redundantly, or additional optimization may be required.

@dmtrKovalenko
Copy link
Owner

Tried to update the ocaml 5 but I am getting esy permissoin issues. I see you have ocaml5 branch in your fork, were you able to build it with esy @cometkim ?

@cometkim
Copy link
Contributor Author

yep, I already did upstream it reasonml/reason-native#271

let me file a PR to this repo too

@cometkim
Copy link
Contributor Author

error: build failed with exit code: 1
  build log:
    # esy-build-package: building: @opam/ocamlfind@opam:1.9.6
    # esy-build-package: pwd: /Users/tim/.esy/3/b/opam__s__ocamlfind-opam__c__1.9.6-975bcba1
    # esy-build-package: running: 'patch' '--strip' '1' '--input' '0001-Harden-test-for-OCaml-5.patch'
    patch: **** patch file 0001-Harden-test-for-OCaml-5.patch not found: No such file or directory
    error: command failed: 'patch' '--strip' '1' '--input' '0001-Harden-test-for-OCaml-5.patch' (exited with 2)
    esy-build-package: exiting with errors above...

  building @opam/ocamlfind@opam:1.9.6
esy: exiting due to errors above

resolving esy dependencies with bunch of overrides is non-trivial .. 😅 I'm fixing effects that started appearing in a completely unrelated place after changing the esy.lock.

@cometkim
Copy link
Contributor Author

cometkim commented Jun 15, 2024

Found this ocaml/opam-repository#25961

I think I should try again after rm -rf ~/.opam/repo/default && opam update default 😅

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.

3 participants