Specialize Vec::from_elem to use calloc by mbrubeck · Pull Request #40409 · rust-lang/rust

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]fnbench_big(b:&mutBencher){
b.iter(|| vec![0u8;1024*1024]);}#[bench]fnbench_medium(b:&mutBencher){
b.iter(|| vec![0u8;1024]);}#[bench]fnbench_small(b:&mutBencher){
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

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

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

 }

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


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 Fixesrust-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 Fixesrust-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. Fixesjaparic#136.

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

rust-highfive assigned BurntSushi Mar 10, 2017

bluss added the T-libs-api [DEPRECATED; DO NOT USE] 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

Comment threadsrc/liballoc_system/lib.rs Outdated
sfacklerMar 15, 2017
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fallback seems a bit unfortunate, but I guess there's no other option?

mbrubeck force-pushed the calloc branch from 0920efc to 4961f6cCompare 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 callocMar 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:masterApr 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. Fixesjaparic#136.

tbu- mentioned this pull request Apr 19, 2017
Add __rust_alloc_zeroed to naive_rallocjaparic/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. Fixesjaparic#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

Uh oh!

Uh oh!

Conversation

mbrubeck commented Mar 10, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Mar 10, 2017

Uh oh!

leonardo-m commented Mar 10, 2017

Uh oh!

mbrubeck commented Mar 10, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clarfonthey commented Mar 10, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbrubeck commented Mar 10, 2017

Uh oh!

clarfonthey commented Mar 10, 2017

Uh oh!

solson commented Mar 14, 2017

Uh oh!

nagisa left a comment

Choose a reason for hiding this comment

Uh oh!

nagisaMar 11, 2017

Choose a reason for hiding this comment

Uh oh!

mbrubeckMar 15, 2017

Choose a reason for hiding this comment

Uh oh!

sfackler commented Mar 15, 2017

Uh oh!

sfacklerMar 15, 2017

Choose a reason for hiding this comment

Uh oh!

solson commented Mar 15, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clarfonthey commented Mar 15, 2017

Uh oh!

bluss commented Mar 15, 2017

Uh oh!

mbrubeck commented Mar 15, 2017

Uh oh!

solson commented Mar 15, 2017

Uh oh!

sfacklerMar 15, 2017

Choose a reason for hiding this comment

Uh oh!

nagisaMar 15, 2017

Choose a reason for hiding this comment

Uh oh!

sfacklerMar 15, 2017

Choose a reason for hiding this comment

Uh oh!

sfackler commented Mar 15, 2017

Uh oh!

sfackler commented Mar 15, 2017

Uh oh!

bors commented Mar 15, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

Mark-Simulacrum commented Apr 16, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

Mark-Simulacrum commented Apr 16, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

bors commented Apr 16, 2017

Uh oh!

Reviewers

Assignees

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