|
𝖉𝖊𝖍𝖚𝖒𝖆𝖓𝖎𝖟𝖊 𝖞𝖔𝖚𝖗𝖘𝖊𝖑𝖋 𝖆𝖓𝖉 𝖋𝖆𝖈𝖊 𝖙𝖔 𝖇𝖎𝖐𝖊𝖘𝖍𝖊𝖉
|
#
?
Mar 2, 2015 01:15
|
|
|
|
| # ? May 13, 2024 19:46 |
|
|
bucketmouse posted:from looking through it while trying to figure out how to port over random functionality the slowdown seems to be because a big chunk of the template functions do something like this for every single variable: tl;dr: it's not just a vc compiler thing c++ has very rigid behavioral semantics: the language gives precise rules for deciding which operator or constructor or whatever any particular code is using, and the implementation has to do exactly that. for example, the compiler can't assume that it's okay to use a move constructor instead of a copy constructor just because it sees that the original object is about to be destroyed, or a copy constructor instead a copy assignment operator just because it sees that you never used the old value in the variable. you wrote something, type-checking says it's implemented by calling such-and -such function, the compiler has to assume that calling some other function might have completely different semantics, no matter how related they might seem in general this extends to order of execution as well. if two things are sequenced, they have to happen in that order, no matter how unrelated they might seem. the language says that you destroy local variables in the reverse order of their construction as you leave a scope, and it says that the operand of a return statement is evaluated within the scope in which it appears, and that means that those local variables must still exist during that evaluation there are a few different things that let the compiler optimize despite that:
in your example, the formal series of operations is: construct a temporary from const lvalue "number", construct "Number" from rvalue temporary, destroy temporary, call operator* with address of "Number" (assuming it takes it by const reference) and consider the result to be another temporary, construct function result from rvalue temporary, destroy temporary, destroy "Number", return. both the temporaries are elidable, but "Number" is not. even if inlining shows that "number" is clearly bound to a temporary, tough luck, you're still constructing "Number"; and you're copy-constructing it, not move-constructing now, if the matrix happens to be POD — if it stores its elements in a big inline array — the compiler has a chance of being smart about this, because compilers are sometimes smart about memcpys; but if it stores its data on the heap, you are probably screwed. but regardless you are screwed in unoptimized builds, presumably as in your test suite; compilers will do copy-elision and NRVO because they are easy and essentially amount to language guarantees, but they do not do interprocedural analysis and copy propagation because not doing that poo poo is what makes it an unoptimized build
|
|
#
?
Mar 2, 2015 10:53
|
|
|
Eclipse is a POScode:
|
|
#
?
Mar 4, 2015 03:43
|
|
|
never use an ide
|
|
#
?
Mar 4, 2015 03:51
|
|
|
rjmccall posted:in general this extends to order of execution as well. if two things are sequenced, they have to happen in that order, no matter how unrelated they might seem. the language says that you destroy local variables in the reverse order of their construction as you leave a scope, and it says that the operand of a return statement is evaluated within the scope in which it appears, and that means that those local variables must still exist during that evaluation is this more true of c++ than c? my understanding was that a c compiler can reorder anything that doesn't change the program's observable behavior, including some things the programmer might not expect to be reordered. are the rules stricter in c++ because of destructors etc?
|
|
#
?
Mar 4, 2015 03:56
|
|
|
i dont get how eclipse would want to add so many of the entry though. eclipse devs are smokign some dank poo poo i guess
|
|
#
?
Mar 4, 2015 03:58
|
|
|
MALE SHOEGAZE posted:never use a text editor
|
|
#
?
Mar 4, 2015 04:08
|
|
|
JewKiller 3000 posted:is this more true of c++ than c? my understanding was that a c compiler can reorder anything that doesn't change the program's observable behavior, including some things the programmer might not expect to be reordered. are the rules stricter in c++ because of destructors etc? you can always do anything that doesn't change the program's observable behavior, in any language.
|
|
#
?
Mar 4, 2015 04:14
|
|
|
bobbilljim posted:Eclipse is a POS that's not an eclipse problem. none of those are valid java folder names.
|
|
#
?
Mar 4, 2015 04:42
|
|
|
also lol don't use git
|
|
#
?
Mar 4, 2015 04:43
|
|
|
Subjunctive posted:you can always do anything that doesn't change the program's observable behavior, in any language. so in haskell i can just delete the entire program?  hmm, checks out
|
|
#
?
Mar 4, 2015 04:44
|
|
|
Shaggar posted:that's not an eclipse problem. none of those are valid java folder names. sorry for expecting the eclipse git plugin to not poo poo itself 
|
|
#
?
Mar 4, 2015 04:48
|
|
|
lol if you're not manually hand-charging every bit in the register to the proper voltage of 1.374V to achieve the bespoke artisinal computations society needs
|
|
#
?
Mar 4, 2015 04:48
|
|
|
Necc0 posted:lol if you're not manually hand-charging every bit in the register to the proper voltage of 1.374V to achieve the bespoke artisinal computations society needs lol, i'm the 1.374 volt logic.
|
|
#
?
Mar 4, 2015 04:54
|
|
|
they're getting pretty low nowadays but idk what the standard actually is when i was still in school it was ~2.5
|
|
#
?
Mar 4, 2015 04:58
|
|
|
oh turns out they're even lower now lol
|
|
#
?
Mar 4, 2015 04:59
|
|
|
JewKiller 3000 posted:so in haskell i can just delete the entire program? no side-effects, no conviction
|
|
#
?
Mar 4, 2015 05:52
|
|
|
haskell has side effects it's called virginity lol
|
|
#
?
Mar 4, 2015 05:53
|
|
|
JewKiller 3000 posted:is this more true of c++ than c? my understanding was that a c compiler can reorder anything that doesn't change the program's observable behavior, including some things the programmer might not expect to be reordered. are the rules stricter in c++ because of destructors etc? like subjunctive said, the implementation can do anything it wants if you're not legally allowed to observe the difference there's no major difference between c and c++ on this point, but that's kindof my point. c's implicit behavior is basically restricted to fitting scalars to the size of the type you're trying to shove them into. c++ turns innocuous bits of syntax into function calls with arbitrary side-effects, but for the most part, the semantics are exactly as if you'd written those calls out in c: the compiler has to execute exactly those calls in exactly that order, unless it can prove that moving them around or doing something different has no observable effect. so e.g. that's why you sometimes have to tell the compiler what to do with std::move whereas in contrast, swift says a value is a value, i'm doing whatever i want, if you've got crazy dependencies between values you'd better own up; so if you pass the value of some local variable to a function and then never use that variable again the compiler will just hand that value straight to the function instead of copying it, formal lifetimes be damned. that's why swift has value types but isn't completely dependent on an explicit move operation and we can be much more aggressive about this kind of thing precisely because we're statically compiled and don't use gc, because if we were making these optimizations dynamically and your code was subtly broken (or ours was) it would be way more likely to only blow up in crazy nondeterministic situations and it would be completely impossible for normal developers to ever figure out what was wrong by direct debugging that turned more into a rant about swift than about c++ at the end
|
|
#
?
Mar 4, 2015 06:03
|
|
|
swift doesn't use gc? what does it use, then? I don't have to allocate and free memory manually.
|
|
#
?
Mar 4, 2015 06:30
|
|
|
automatic reference counting, essentially like objc but with conventions that are better for being enforced by a compiler. it gets screwed by reference cycles the same as objc (and plenty of other languages). you can even switch to manual reference counting with Unmanaged<T> if you want "gc" is generally reserved for something that analyzes the actual object reference graph and is capable of deallocating objects even if they're part of a reference cycle. at its core this always involves walking the heap following references, usually asynchronously or at least unpredictably, although most of the last 20+ years of research in gc has been focused on doing fewer complete heap walks or doing them iteratively or at least not needing to shut down the rest of the process while they're happening
|
|
#
?
Mar 4, 2015 07:00
|
|
|
i am a bad programmer, i don't know how to use multithreading and i am using stuff like code:but maybe without the lambda function because i have no idea how that works either. also no one i've talked to that Knows Java knows how to use them so maybe I am just a teardrop in the ocean of badprogrammers around me? also I use eclipse and javafx (which i am pretty sure is just oracle acknowledging that there's a ton of java developers that are too bad to use html5 or whatevs)
|
|
#
?
Mar 4, 2015 07:59
|
|
|
reference counting (especially compiler-managed) is GC: dynamic maintenance of object lifecycles. it can give you pauses and heap thrash and all that, conservative marking rhymes with reference cycles, we are all one indeterminate finalization order under jones&lins. it's more similar to mark-and-sweep than to malloc/free in programming model.
|
|
#
?
Mar 4, 2015 08:12
|
|
|
Subjunctive posted:reference counting (especially compiler-managed) is GC: dynamic maintenance of object lifecycles. it can give you pauses and heap thrash and all that, conservative marking rhymes with reference cycles, we are all one indeterminate finalization order under jones&lins. http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
|
|
#
?
Mar 4, 2015 08:24
|
|
|
yeah, it's a great paper.
|
|
#
?
Mar 4, 2015 08:26
|
|
|
MALE SHOEGAZE posted:haskell has side effects it's called virginity lol in other words, it enforces purity?
|
|
#
?
Mar 4, 2015 08:44
|
|
|
Subjunctive posted:yeah, it's a great paper. i agree that it's a cool paper, but i don't really agree with unifying the terms, and i would still argue that a ref-counting model is prone to cause deterministic, immediate finalization in ways that expose mistakes much more reliably than the alternatives, even if the inter-ordering of finalizers is still too complex to reasonably understand
|
|
#
?
Mar 4, 2015 09:56
|
|
|
it's almost like there are no perfect solutions when it comes to gc and it's up to the developer to choose the best model for their particular needs  ref count supremacy
|
|
#
?
Mar 4, 2015 14:55
|
|
|
drat
|
|
#
?
Mar 4, 2015 14:58
|
|
|
god VBA is such a piece of poo poo some of the students today wrote stuff like "Dim range As Range". fair enough. not the best name but whatever. now however because vba is sometimes case-sensitive and sometimes case-insensitive, and the auto-correct is insensitive, Range will correct to range. range is not a valid type but Range is. this will cause an error because it expected a type where there's a variable name. this will continue to happen even if you rename the range variable to something else, auto-correct remembers this will continue to happen even after closing and reopening excel.
|
|
#
?
Mar 4, 2015 15:06
|
|
|
Marzzle posted:i am a bad programmer, i don't know how to use multithreading and i am using stuff like 101 multithreading : don't let threads touch except where they are explicitly allowed. pick the one or two places to exchange info and touch nothing else 102 multithreading : don't use threads explicitly. fumbling around in the "compile->run->check" cycle does not make threaded code that consistently works. in your case you want to use SwingWorkers as the threads. there's a tutorial, go read it e: all the GC chat tricked me into thinking this was the other thread Brain Candy fucked around with this message at 15:23 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 15:20
|
|
|
gonadic io posted:god VBA is such a piece of poo poo ahhhhh
|
|
#
?
Mar 4, 2015 15:34
|
|
|
i've never seen anyone defend refcount gc before
|
|
#
?
Mar 4, 2015 15:47
|
|
|
rjmccall posted:i agree that it's a cool paper, but i don't really agree with unifying the terms, and i would still argue that a ref-counting model is prone to cause deterministic, immediate finalization in ways that expose mistakes much more reliably than the alternatives, even if the inter-ordering of finalizers is still too complex to reasonably understand i was always told not to rely on finalizers in java, because they might not run what is up with your code that you require certain finalization
|
|
#
?
Mar 4, 2015 15:47
|
|
|
Notorious b.s.d. posted:i've never seen anyone defend refcount gc before it's real simple to implement, cycles aren't that common (i've rarely had to use a weakref/ephemeron), has predictable runtime behaviour
|
|
#
?
Mar 4, 2015 15:55
|
|
|
finalizers in java will run if the objects gets GCed but when and if that happens is always up in the air so don't rely on them. apparently java has some really kludgy implementation of the IDisposable/using pattern. Your object implements AutoClosable and you create it in a try-with-resources block. its just like java lambdas. a good idea copied from c# without taking usability into account.
|
|
#
?
Mar 4, 2015 15:57
|
|
|
Shaggar posted:its just like java... a ... idea ... without taking usability into account.
|
|
#
?
Mar 4, 2015 16:10
|
|
|
tef posted:it's real simple to implement, cycles aren't that common (i've rarely had to use a weakref/ephemeron), has predictable runtime behaviour it's definitely not predictable runtime behavior. dropping the last ref happens unpredictably, and can lead to arbitrary computation (most often a cascade of decrefing destructors paging in your otherwise-dead heap, sometimes flushing buffers and similar). we had problems like this in Firefox where something would get evicted from the document cache and cause a pause while it was torn down, in the middle of an otherwise-innocuous operation. the real advantage of refcounting, IMO, is that you get prompt reclamation.
|
|
#
?
Mar 4, 2015 16:12
|
|
|
Marzzle posted:maybe I am just a teardrop in the ocean of badprogrammers around me? its this.
|
|
#
?
Mar 4, 2015 17:34
|
|
|
|
| # ? May 13, 2024 19:46 |
|
|
Subjunctive posted:it's definitely not predictable runtime behavior. dropping the last ref happens unpredictably, and can lead to arbitrary computation (most often a cascade of decrefing destructors paging in your otherwise-dead heap, sometimes flushing buffers and similar). we had problems like this in Firefox where something would get evicted from the document cache and cause a pause while it was torn down, in the middle of an otherwise-innocuous operation. yeah but firefox isn't exactly a canonical example, refcounts works on my machine quote:the real advantage of refcounting, IMO, is that you get prompt reclamation. same, this was the "predictable" part i was meaning tef fucked around with this message at 17:44 on Mar 4, 2015 |
|
#
?
Mar 4, 2015 17:40
|
|