14,641 reputation
13460
bio website
location
age
visits member for 4 years, 6 months
seen 8 mins ago

Feb
2
comment How is atomicity of reference operations enforced?
Oh, you're using "atomic" in the sense of "it can't ever happen that only half of the data was written". Usually atomicity refers to more than just that.
Feb
2
comment How is atomicity of reference operations enforced?
Which operations, and which languages? I can't think of a single language that guarantees atomicity for any operation on references (or other data) unless one explicitly opts in with an AtomicReference type or something like that.
Jan
30
comment Why can we use the same name for local variable in different scopes?
Removed my downvote, but I think explaining it with implementation details (call stack and frame offsets) is not very helpful.
Jan
30
comment Why can we use the same name for local variable in different scopes?
The stack has nothing to do with variable names in the source code.
Jan
26
comment Any reasons NOT to write self testing Python code?
Ensuring that everything has a test is far more effectively done via code coverage (run the tests, check what code got executed).
Jan
24
comment Situations when O(n^2) better than O(n*log(n))
@AlexFilatov Oh, the "usually" is hidden away at the beginning. I drop the claim of contradiction, downgrading it to misleading (no computer scientist worth their salt will simply describe Quicksort as quadratic and neglect the distinction between worst and average case).
Jan
24
comment Why do mainstream OO languages not have immutability on class-level built-in?
@faif Implicitly so (as far as the language), since it is carefully written so that (1) none of the code in the class itself modifies an instance's value and (2) all state is properly hidden and not aliased, so that (non-malicious) outside of the class can't modify it either. What Ruudjah is getting at is some language feature that automated or checks or otherwise supports these properties.
Jan
24
comment Situations when O(n^2) better than O(n*log(n))
The second part is simply false, contradictory. The very fact that we know the average complexity shows that other cases than the worst case are considered. If anything, you should chide OP for being imprecise about whether they mean worst case or some other case.
Jan
24
comment Situations when O(n^2) better than O(n*log(n))
@malejpavouk That's precisely what I'm saying. Quicksort is not an answer because for the class of inputs where its time complexity is O(n²), it is not better than the algorithms with O(n log n) time complexity.
Jan
24
comment Situations when O(n^2) better than O(n*log(n))
Quicksort is a bad example, as you say its average complexity is O(n log n), so it's no surprise that it's competitive on average. In the non-average cases where it actually takes O(n²) time, most worst-case O(n log n) algorithms do in fact perform better.
Jan
22
comment What type of neural network is suitable for simulating brain of virtual organism?
What is the objective function? Unless you're chasing some pipe dream of modelling real evolution and getting a strong AI out of it, you're trying to generate a NN that performs well at some specific task. What is that task?
Jan
22
comment Why don't we see (more) widespread adoption of lock-free dynamic memory allocators?
I'm not saying that. I'm saying that the "not completely lock-free" approaches work well enough that most people aren't out actively looking for more scalable approaches, and that any allocator has to overcome significant hurdles to prove its worth and force itself onto the market.
Jan
22
comment Why don't we see (more) widespread adoption of lock-free dynamic memory allocators?
But does it beat jemalloc and the TBB allocator? Does it beat the current versions of ptmalloc and Hoard? Allocator performance is very tricky, no single paper can settle it definitely. If Intel wanted to adopt a new allocator, they'd probably run their own extensive benchmark suite and collaborate with important customers to test more real-world programs. There's little incentive to do that if their current allocator scales near-linearly in all applications they care about. (Also, there's more to an allocator than throughput: Fragmentation and metadata overhead also matter.)
Jan
22
comment Why don't we see (more) widespread adoption of lock-free dynamic memory allocators?
As you say, some widely used allocators are quite scalable without being lock free. Why go the extra mile (and risk regressions in actual performance) to be completely lock-free?
Jan
21
awarded  Guru
Jan
20
comment Is address 0000000C a special address?
@LorenPechtel Oh, now I get it. You're saying there's a null pointer, as my answer suggested, but the 12 bytes being skipped over don't come from other parts of the struct but from allocator metadata. I don't think that's particular likely either. If such metadata exists, it's before the pointer that's used as handle on the object (i.e. if an object pointer points at 0, we'd expect the metadata at -12). Stashing the metadata and adding that number of bytes to the pointer is generally done once, by the allocator — the program's more robust against allocator changes that way.
Jan
20
comment Is address 0000000C a special address?
@LorenPechtel I understood that part perfectly well. What I'm saying is that there almost certainly won't be a memory allocation at 0000000C, or at any other address below at least 4096 (decimal), because that range of addresses is reserved and not mapped to any physical memory (see also: other comments and answers).
Jan
20
comment Is address 0000000C a special address?
@LorenPechtel I was reading this as "addresses 0 and following are used for allocations rather than protected, and something with a 12 byte header is allocated at address 0". Please elaborate if that is not the case, as I can't muster any other interpretation of either of your comments.
Jan
20
awarded  Good Answer
Jan
20
comment Is address 0000000C a special address?
@LorenPechtel I'm not even sure whether a language implementation (read: reasonably privileged library) could change the protection of page 0. Even then, I'm not aware of anyone doing this (and I'm very certain no C++ implementation does it). Catching null pointers is just far too useful, and the consequences if that metadata is overwritten by some wayward code are very severe. It doesn't even free any significant amount of memory (only < 100 KiB of address space and no physical memory at all). So, in brief, your guess is totally off.