Visitar URL original
Document that random_shuffle shuffles only locally by MaxFreedomPollard · Pull Request #6491 · NVIDIA/DALI · GitHub
Skip to content

Document that random_shuffle shuffles only locally - #6491

Merged
JanuszL merged 3 commits into
NVIDIA:mainfrom
MaxFreedomPollard:docs-random-shuffle-buffer
Sep 21, 2026
Merged

JanuszL merged 3 commits into
NVIDIA:mainfrom
MaxFreedomPollard:docs-random-shuffle-buffer

Conversation

@MaxFreedomPollard

Copy link
Copy Markdown
Contributor

Category:

Other (e.g. Documentation, Tests, Configuration)

Description:

Closes #3088.

random_shuffle draws samples from a buffer of initial_fill samples that is filled sequentially, so it only shuffles locally. Readers of container formats (TFRecord, MXNet, Caffe, Caffe2, WebDataset) read the samples in the order in which they are stored, which means a dataset sorted by label comes out mostly sorted with the default buffer. #3088 ran into this when switching from the file reader to TFRecord, and the reply there suggested proposing wording for loader.cc.

This adds a note to the random_shuffle and initial_fill arguments, and two paragraphs to the Shuffling section added in #6484. They also explain why the file-based readers are not affected: they shuffle the whole file list once when random_shuffle is set.

To check the wording against real behavior, I read a TFRecord with 20 classes of 1000 samples each, stored class after class, using DALI 2.3.0 on CPU with a batch size of 256 (loader.h has not changed since that release). With the default initial_fill=1024, the first batch contained 2 of the 20 classes, on average 80% of a batch came from just two classes, and no sample was returned more than 1023 positions ahead of its stored position. With initial_fill equal to the dataset size, every batch contained all 20 classes.

Additional information:

Affected modules and functionalities:

Documentation only: the random_shuffle and initial_fill argument docs in the LoaderBase schema, which all readers share, and docs/advanced_topics_sharding.rst.

Key points relevant for the review:

The list of readers that read in the stored order. I went through the loaders: every list-based one (file, numpy, fits, coco, sequence, nemo_asr, video) shuffles its whole list once under if (shuffle_), while the indexed-file (TFRecord), RecordIO, LMDB and WebDataset loaders do not.

Tests:

  • Existing tests apply
  • New tests added
    • Python tests
    • GTests
    • Benchmark
    • Other
  • N/A

Checklist

Documentation

  • Existing documentation applies
  • Documentation updated
    • Docstring
    • Doxygen
    • RST
    • Jupyter
    • Other
  • N/A

DALI team only

Requirements

  • Implements new requirements
  • Affects existing requirements
  • N/A

REQ IDs: N/A

JIRA TASK: N/A

The random_shuffle buffer is a local shuffle: a sample is never returned
more than initial_fill positions ahead of where it is read. Readers of
container formats (TFRecord, MXNet, Caffe, Caffe2, WebDataset) read the
samples in the stored order, so a dataset sorted by label stays mostly
sorted with the default buffer. The documentation did not mention this.

Add a note to the random_shuffle and initial_fill arguments and explain
the behavior in the Sharding and Shuffling guide.

Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>
@copy-pr-bot

copy-pr-bot Bot commented Sep 19, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@greptile-apps

greptile-apps Bot commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerConfidence Score: 5/5

The documentation-only changes appear safe to merge, with no outstanding actionable findings.

Summary

Documents the local nature of reader shuffling.

  • Explains how initial_fill limits mixing across distant samples.
  • Describes the behavior of file-list and container-format readers.
  • Clarifies the memory and startup-latency tradeoffs of larger shuffle buffers.
  • Qualifies complete shuffling as applying to the shard read by the pipeline.

Reviews (3) · Last reviewed commit: "Clarify shuffling of container datasets"

Comment thread dali/operators/reader/loader/loader.cc Resolved
Comment thread docs/advanced_topics_sharding.rst Resolved
The buffer only draws samples from the shard that is currently being
read, so it is the shard, not the whole dataset, that has to fit into
the buffer for a complete shuffle. With one shard the two are the same.

Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>
@JanuszL JanuszL self-assigned this Sep 19, 2026
Signed-off-by: Max Freedom Pollard <272618364+MaxFreedomPollard@users.noreply.github.com>

@jantonguirao jantonguirao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Documentation-only change. Verified the shuffle-buffer behavior and reader list against the loader implementation — matches. Prior review comments (Greptile, JanuszL) already addressed in the current HEAD.

@JanuszL

JanuszL commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

!build

@dali-automaton

Copy link
Copy Markdown
Collaborator

CI MESSAGE: [69031371]: BUILD STARTED

@dali-automaton

Copy link
Copy Markdown
Collaborator

CI MESSAGE: [69031371]: BUILD PASSED

@JanuszL
JanuszL merged commit 834e1b4 into NVIDIA:main Sep 21, 2026
10 checks passed
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.

Propose to add note about default behaviour of TFRecord Reader to documentation

4 participants