Feature request
It would be useful if concatenating multiple IterableDatasets could preserve the shard information from each input dataset, so that:
- the total number of shards equals the sum of the input shards;
split_dataset_by_node() and worker sharding continue to work efficiently;
- downstream distributed dataloaders can fully exploit the available parallelism.
Motivation
Currently, it's straightforward to concatenate multiple streaming datasets using interleave_datasets or other approaches. However, after concatenation, the resulting dataset does not preserve the original sharding information from each input dataset.
For distributed training, especially with large-scale datasets, this leads to a reduced number of effective shards compared to the sum of the input datasets' shards. Consequently, data loading parallelism may be limited, and the available worker concurrency cannot fully utilize the original dataset partitioning.
For example:
- IterableDataset A: 1 shard
- IterableDataset B: 1 shard
After concatenation, we would expect the resulting streaming dataset to expose 2 shards, allowing distributed workers to shard the combined dataset naturally.
Your contribution
I'd be happy to work on this feature and submit a PR if the maintainers think this would be a useful addition.
Any feedback on the proposed design would be greatly appreciated.
Feature request
It would be useful if concatenating multiple
IterableDatasets could preserve the shard information from each input dataset, so that:split_dataset_by_node()and worker sharding continue to work efficiently;Motivation
Currently, it's straightforward to concatenate multiple streaming datasets using
interleave_datasetsor other approaches. However, after concatenation, the resulting dataset does not preserve the original sharding information from each input dataset.For distributed training, especially with large-scale datasets, this leads to a reduced number of effective shards compared to the sum of the input datasets' shards. Consequently, data loading parallelism may be limited, and the available worker concurrency cannot fully utilize the original dataset partitioning.
For example:
After concatenation, we would expect the resulting streaming dataset to expose 2 shards, allowing distributed workers to shard the combined dataset naturally.
Your contribution
I'd be happy to work on this feature and submit a PR if the maintainers think this would be a useful addition.
Any feedback on the proposed design would be greatly appreciated.