Specialize Vec::from_elem to use calloc #40409

mbrubeck · 2017-03-10T04:42:20Z

Fixes #38723. ~~This specializes the implementation for u8 only, but it could be extended to other zeroable types if desired.~~

I haven't tested this extensively, but I did verify that it gives the expected performance boost for large vec![0; n] allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)

rust-highfive · 2017-03-10T04:42:31Z

r? @BurntSushi

(rust_highfive has picked a reviewer for you, use r? to override)

leonardo-m · 2017-03-10T10:13:08Z

What's the performance for short (n <= 8)?

mbrubeck · 2017-03-10T15:49:28Z

For the following benchmarks, using the default allocator (alloc_jemalloc) on Linux:

#[bench]
fn bench_big(b: &mut Bencher) {
    b.iter(|| vec![0u8; 1024 * 1024]);
}
#[bench]
fn bench_medium(b: &mut Bencher) {
    b.iter(|| vec![0u8; 1024]);
}
#[bench]
fn bench_small(b: &mut Bencher) {
    b.iter(|| vec![0u8; 8]);
}

Before this PR:

test bench_big    ... bench:     231,338 ns/iter (+/- 97,246)
test bench_medium ... bench:          34 ns/iter (+/- 1)
test bench_small  ... bench:          24 ns/iter (+/- 3)

After this PR:

test bench_big    ... bench:         853 ns/iter (+/- 47)
test bench_medium ... bench:          37 ns/iter (+/- 2)
test bench_small  ... bench:          25 ns/iter (+/- 1)

clarfonthey · 2017-03-10T16:45:37Z

Is there a reason why this can't be specialised for all integer types if the value is zero?

mbrubeck · 2017-03-10T18:20:26Z

Is there a reason why this can't be specialised for all integer types if the value is zero?

It can, and I'm working on a patch to do that. It could also be specialized for floats, and for some less-common types like Option<&T> and raw pointers; I'm not sure where the point of diminishing returns is.

clarfonthey · 2017-03-10T18:29:02Z

I think that specialising for integer zeroes is definitely reasonable (because [0; n] is the most common way of initialising an array). I personally would like to see the others you mentioned too, although that's just my opinion. :P

solson · 2017-03-14T21:21:11Z

@whitequark made a good point on IRC: If we had a Pod (plain old data) trait, you could make this specialization for all T: Pod in a single impl. This would handle many of the types mentioned above but it would also handle arbitrary user-defined types that meet the Pod requirements.

Previous discussions here and here.

nagisa

(damn github review didn’t get posted)

nagisa · 2017-03-11T16:12:16Z

src/liballoc_jemalloc/lib.rs

+        } else {
+            let flags = align_to_flags(align);
+            unsafe {
+                let ptr = mallocx(size as size_t, flags);


Use MALLOCX_ZERO flag instead.

sfackler · 2017-03-15T05:26:49Z

@solson how would that work here though? This only handles the case of an all-zero initial bit pattern.

sfackler · 2017-03-15T05:29:36Z

src/liballoc_system/lib.rs

+        } else {
+            let ptr = aligned_malloc(size, align);
+            if !ptr.is_null() {
+                ptr::write_bytes(ptr, 0, size);


This fallback seems a bit unfortunate, but I guess there's no other option?

solson · 2017-03-15T05:38:29Z

@sfackler My understanding is that for T: Pod, it's safe to use std::mem::zeroed::<T>(), so it's also safe to allocate an array of them with something like calloc (when the value is represented by the zero bit pattern).

EDIT: See this sentence from this issue description:

The trait can only be implemented by a subset of all types and identifies objects that are valid when they contain arbitrary bit patterns.

clarfonthey · 2017-03-15T13:55:18Z

Also one thing to consider is that Zeroable is already part of libcore and could be useful here for this optimisation.

bluss · 2017-03-15T13:59:20Z

@solson the missing part of the explanation is how to identify that x is equivalent to (all bits) zero in vec![x; n] for T: Pod.

mbrubeck · 2017-03-15T15:31:08Z

Added a patch to specialize vec![0; n] for other integer types.

solson · 2017-03-15T17:05:55Z

@bluss One basic way would be to iterate over the bytes of x and check that they are all zero (which seems like something the optimizer could easily simplify). We could perhaps do something a bit more direct with [0; size_of::<T>()] in the future when size_of is a const fn.

sfackler · 2017-03-15T17:18:47Z

src/liballoc_jemalloc/lib.rs

@@ -92,6 +98,16 @@ mod imp {
    }

    #[no_mangle]
+    pub extern "C" fn __rust_allocate_zeroed(size: usize, align: usize) -> *mut u8 {
+        if align <= MIN_ALIGN {


I am not super familiar with jemalloc - is calloc faster than unconditionally calling mallocx here?

Yes, mallocx is parsing the options out from flags’ bitmask, whereas calloc sets them directly. Difference likely negligible though.

Cool, thanks. Seems fine either way.

sfackler · 2017-03-15T17:20:20Z

r=me other than one dumb question about jemalloc.

sfackler · 2017-03-15T17:53:29Z

@bors r+

bors · 2017-03-15T17:53:30Z

📌 Commit 4961f6c has been approved by sfackler

Specialize Vec::from_elem to use calloc Fixes rust-lang#38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)

bors · 2017-04-16T10:43:38Z

⌛ Testing commit aad2062 with merge 966a32a...

bors · 2017-04-16T13:44:19Z

💔 Test failed - status-travis

Mark-Simulacrum · 2017-04-16T13:56:16Z

Timed out, presumably spurious. Retrying.

@bors retry

Specialize Vec::from_elem to use calloc Fixes rust-lang#38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)

bors · 2017-04-16T16:30:23Z

⌛ Testing commit aad2062 with merge 31bbdc1...

bors · 2017-04-16T16:47:16Z

💔 Test failed - status-appveyor

Mark-Simulacrum · 2017-04-16T16:53:24Z

@bors retry

Spurious failures on AppVeyor due to ar.exe errors #40546: ar.exe failed to rename: C:\projects\rust\mingw64\bin\ar.exe: unable to rename 'lib\libLLVMARMInfo.a'; reason: Permission denied

[1139/1629] Building CXX object lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/Thumb2ITBlockPass.cpp.obj
[1140/1629] Building CXX object lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/Thumb2SizeReduction.cpp.obj
[1141/1629] Building CXX object lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/ThumbRegisterInfo.cpp.obj
[1142/1629] Building CXX object lib/Target/ARM/CMakeFiles/LLVMARMCodeGen.dir/Thumb1InstrInfo.cpp.obj
[1143/1629] Building CXX object lib/Target/ARM/TargetInfo/CMakeFiles/LLVMARMInfo.dir/ARMTargetInfo.cpp.obj
[1144/1629] Linking CXX static library lib\libLLVMARMInfo.a
FAILED: lib/libLLVMARMInfo.a 
cmd.exe /C "cd . && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E remove lib\libLLVMARMInfo.a && C:\projects\rust\mingw64\bin\ar.exe qc lib\libLLVMARMInfo.a  lib/Target/ARM/TargetInfo/CMakeFiles/LLVMARMInfo.dir/ARMTargetInfo.cpp.obj && C:\projects\rust\mingw64\bin\ranlib.exe lib\libLLVMARMInfo.a && cd ."
C:\projects\rust\mingw64\bin\ar.exe: unable to rename 'lib\libLLVMARMInfo.a'; reason: Permission denied
[1145/1629] Linking CXX static library lib\libLLVMARMCodeGen.a
ninja: build stopped: subcommand failed.
thread 'main' panicked at '
command did not execute successfully, got: exit code: 1
build script failed, must exit now', C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.22\src\lib.rs:617
note: Run with `RUST_BACKTRACE=1` for a backtrace.
	finished in 282.127
Build completed unsuccessfully in 0:04:43

bors · 2017-04-16T19:13:57Z

⌛ Testing commit aad2062 with merge 7627e3d...

Specialize Vec::from_elem to use calloc Fixes #38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)

bors · 2017-04-16T22:24:32Z

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing 7627e3d to master...

This is fallout from rust-lang/rust#40409 which requires that all allocators provide a `__rust_alloc_zeroed` function. Fixes japaric#136.

rust-lang/rust#40409 requires a __rust_alloc_zeroed function.

rust-highfive assigned BurntSushi Mar 10, 2017

bluss added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Mar 11, 2017

aturon assigned sfackler and unassigned BurntSushi Mar 14, 2017

nagisa reviewed Mar 14, 2017

View reviewed changes

sfackler reviewed Mar 15, 2017

View reviewed changes

mbrubeck force-pushed the calloc branch from 0920efc to 4961f6c Compare March 15, 2017 15:30

mbrubeck changed the title ~~Specialize Vec::from_elem<u8> to use calloc or memset~~ Specialize Vec::from_elem to use calloc Mar 15, 2017

sfackler reviewed Mar 15, 2017

View reviewed changes

bluss mentioned this pull request Mar 15, 2017

Remove the ownership requirement from the into Cholesky factorization… masonium/linxal#8

Open

bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Mar 16, 2017

frewsxcv mentioned this pull request Mar 17, 2017

Rollup of 15 pull requests #40615

Closed

frewsxcv mentioned this pull request Apr 16, 2017

Rollup of 2 pull requests #41330

Closed

Mark-Simulacrum added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Apr 16, 2017

bors merged commit aad2062 into rust-lang:master Apr 16, 2017

bors mentioned this pull request Apr 16, 2017

Add top level sections to the Unstable Book. #41295

Merged

tbu- added a commit to tbu-/steed that referenced this pull request Apr 19, 2017

Add __rust_alloc_zeroed to naive_ralloc

1484864

This is fallout from rust-lang/rust#40409 which requires that all allocators provide a `__rust_alloc_zeroed` function. Fixes japaric#136.

tbu- mentioned this pull request Apr 19, 2017

Add __rust_alloc_zeroed to naive_ralloc japaric/steed#139

Merged

ranma42 mentioned this pull request Apr 21, 2017

Implement Vec::from_elem specialization for all Copy types #41335

Closed

oli-obk mentioned this pull request Apr 28, 2017

Update alloc API to latest nightly rust-embedded/embedded-alloc#5

Merged

anatol pushed a commit to anatol/steed that referenced this pull request May 3, 2017

Add __rust_alloc_zeroed to naive_ralloc

9045052

This is fallout from rust-lang/rust#40409 which requires that all allocators provide a `__rust_alloc_zeroed` function. Fixes japaric#136.

kaedroho mentioned this pull request May 9, 2017

allocate_vec returns uninitialised memory quickwit-oss/tantivy#139

Closed

dwrensha mentioned this pull request May 21, 2017

implement __rust_allocate_zeroed C ABI function rust-lang/miri#168

Merged

kmindg added a commit to kmindg/jemallocator that referenced this pull request May 24, 2017

Fix test failure.

368c895

rust-lang/rust#40409 requires a __rust_alloc_zeroed function.

kmindg added a commit to kmindg/jemallocator that referenced this pull request May 24, 2017

Fix test failure.

5db9ce1

rust-lang/rust#40409 requires a __rust_alloc_zeroed function.

kmindg added a commit to kmindg/jemallocator that referenced this pull request May 24, 2017

Fix test failure

f916af3

rust-lang/rust#40409 requires a __rust_alloc_zeroed function.

kmindg mentioned this pull request May 24, 2017

Fix test failure gnzlbg/jemallocator#8

Merged

RReverser mentioned this pull request Feb 22, 2019

Optimise vec![false; N] to zero-alloc #58628

Merged

ruseinov mentioned this pull request Jun 28, 2023

feat: CAR-backed Blockstore ChainSafe/forest#3085

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Specialize Vec::from_elem to use calloc #40409

Specialize Vec::from_elem to use calloc #40409

mbrubeck commented Mar 10, 2017 •

edited

Loading

rust-highfive commented Mar 10, 2017

leonardo-m commented Mar 10, 2017

mbrubeck commented Mar 10, 2017 •

edited

Loading

clarfonthey commented Mar 10, 2017 •

edited

Loading

mbrubeck commented Mar 10, 2017

clarfonthey commented Mar 10, 2017

solson commented Mar 14, 2017

nagisa left a comment

nagisa Mar 11, 2017

mbrubeck Mar 15, 2017

sfackler commented Mar 15, 2017

sfackler Mar 15, 2017

solson commented Mar 15, 2017 •

edited

Loading

clarfonthey commented Mar 15, 2017

bluss commented Mar 15, 2017

mbrubeck commented Mar 15, 2017

solson commented Mar 15, 2017

sfackler Mar 15, 2017

nagisa Mar 15, 2017

sfackler Mar 15, 2017

sfackler commented Mar 15, 2017

sfackler commented Mar 15, 2017

bors commented Mar 15, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

Mark-Simulacrum commented Apr 16, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

Mark-Simulacrum commented Apr 16, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

Specialize Vec::from_elem to use calloc #40409

Specialize Vec::from_elem to use calloc #40409

Conversation

mbrubeck commented Mar 10, 2017 • edited Loading

rust-highfive commented Mar 10, 2017

leonardo-m commented Mar 10, 2017

mbrubeck commented Mar 10, 2017 • edited Loading

clarfonthey commented Mar 10, 2017 • edited Loading

mbrubeck commented Mar 10, 2017

clarfonthey commented Mar 10, 2017

solson commented Mar 14, 2017

nagisa left a comment

Choose a reason for hiding this comment

nagisa Mar 11, 2017

Choose a reason for hiding this comment

mbrubeck Mar 15, 2017

Choose a reason for hiding this comment

sfackler commented Mar 15, 2017

sfackler Mar 15, 2017

Choose a reason for hiding this comment

solson commented Mar 15, 2017 • edited Loading

clarfonthey commented Mar 15, 2017

bluss commented Mar 15, 2017

mbrubeck commented Mar 15, 2017

solson commented Mar 15, 2017

sfackler Mar 15, 2017

Choose a reason for hiding this comment

nagisa Mar 15, 2017

Choose a reason for hiding this comment

sfackler Mar 15, 2017

Choose a reason for hiding this comment

sfackler commented Mar 15, 2017

sfackler commented Mar 15, 2017

bors commented Mar 15, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

Mark-Simulacrum commented Apr 16, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

Mark-Simulacrum commented Apr 16, 2017

bors commented Apr 16, 2017

bors commented Apr 16, 2017

mbrubeck commented Mar 10, 2017 •

edited

Loading

mbrubeck commented Mar 10, 2017 •

edited

Loading

clarfonthey commented Mar 10, 2017 •

edited

Loading

solson commented Mar 15, 2017 •

edited

Loading