Earlier quoted context omitted.
The Java and Python runtimes, which have much better test coverage and higher correctness standards than most enteprise applications, shipped a broken sort method for decades because it was a few percent faster. Never mind that for some inputs the returned value wouldn't actually be sorted. As an industry we're not qualified to even start caring about performance when our record on correctness is so abysmal. If you h…
What? Where can I read more about that?
The computers are fast, but you don't know it
741–750 of 819 posts
Re: The computers are fast, but you don't know it
#742On a 3GHz CPU, one clock cycle is enough time for light to travel only 10cm. If you hold up a sign with, say, a multiplication, a CPU will produce the result before light reaches a person a few metres away.
I ran across an animation once that showed graphically the time it takes light to travel between the planets and the sun. It's weird, but light doesn't seem that fast anymore.
Edit: found it: https://www.youtube.com/watch?v=nQUwHdSAhmw
Re: The computers are fast, but you don't know it
#743Earlier quoted context omitted.
He said "easy to read" not "filled with weird syntax choices that make anyone from a C background barf". What the hell are those channel arrows and why do they point the wrong way.
Channel arrows are basically just read/write operations. If `ch` is a channel, then this expression means "value obtained from reading from the channel": And this expression means "write value x into the channel": ch Both expressions can be used as a case inside select statement: select { case val := Which will execute exactly one case, depending on which channel becomes "ready" first - channel is ready for reading i…
It was a rhetorical question.
Re: The computers are fast, but you don't know it
#744Re: The computers are fast, but you don't know it
#745Earlier quoted context omitted.
> C is what it is, and we live with it. Still, it would be unreasonable to say that the amount of UB it harbours isn't absolutely ludicrous. There's a lot of ludicrous stuff about C and I wouldn't recommend anyone use it for anything. Not when Rust and C++ exist. But UB really isn't the scary boogie man. There could probably stand to be a `as-is {}` block extension for security checks, but that's really about it.
I'm sorry, C++ ?!? Granted, C is underpowered and I would like namespaces and generics. But from a safety standpoint nowadays, C++ is just as bad. Not only is is monstrously complex, it still has all the pitfalls of C. C++ may have been "more strongly typed" back in the day, but now compiler warnings made up for that small difference. Granted, C++ can be noticeably safer if you go RAII pointer fest, but then you're e…
> I'm sorry, C++?!?
C++ had a defined multithreaded memory model and 2's compliment behavior before C did. Since you're all about UB, that kinda matters. A lot.
Re: The computers are fast, but you don't know it
#746Earlier quoted context omitted.
> Performance only goes downhill from here if the function does more work, Doesn't this mean it's less of a problem? Like, isn't that good?
The phrase "goes downhill" means things only get worse. The OP is suggesting that since the ping is already slow, a function that does something is going to be much worse.
But as performance gets worse, the ping being slow matters less, relatively, right?
Re: The computers are fast, but you don't know it
#747Yup. We have gotten into the habit of leaving a lot of potential performance on the floor in the interest of productivity/accessibility. What always amazes me is when I have to work with a person who only speaks Python or only speaks JS and is completely unaware of the actual performance potential of a system. I think a lot of people just accept the performance they get as normal even if they are doing things that ta…
> only speaks Python or only speaks JS and is completely unaware of the actual performance potential of a system If you stick to only doing arithmetic and avoid making lots of small objects, javascript engines are pretty fast (really!). The tricky part with doing performance-sensitive work in JS is that it’s hard to reason about the intricacies of JITs and differences between implementations and sometimes subtle mist…
To be fair, giant towers of indirection are hard to profile since everything is going to be sort of lukewarm.
Re: The computers are fast, but you don't know it
#748Earlier quoted context omitted.
But it's not only that. Nothing can be improved to be 119% faster either. Maybe the new result makes the old one 119% slower. It's about language use and what of are those per-cents (per-hundredths).
If I travel 25 miles in 1 hour, my speed was 25mph. If I go 100% faster, I'm going 50mph and get there in 30 minutes. If I go 200% faster, I'm going 75mph and get there in 20 minutes. However, the original statement of "We have reduced the time for the computation by ~119%!" is still wrong-seeming, I agree. It should be "We have increased the speed for the computation by 119%" or "We have reduced the time for the com…
Language is, as you nicely point out, very tricky.
Yeah, when talking of speed, you can clearly go more than 100% faster.
But when talking of something taking a certain amount of time, like done in most benchmarks, it can't be made more than 100% faster.
Re: The computers are fast, but you don't know it
#749Earlier quoted context omitted.
> … guessing something about the implementation. The source code is shown — binary-trees Java #7 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/... binary-trees Go #2 program https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Alright, I guess I'll admit this just sniped me. Having read the rules it's difficult to know what's considered "fair" for this test - all GC tuning is off the table, sure. But what's bugging me is "Leaf nodes must be the same as interior nodes - the same memory allocation." So what constitutes "the same memory allocation" - literally the exact same call to some opaque internal allocator? If so, shouldn't Java also h…
And then the Java etc programs are re-written to do the same and the test value is increased (to compensate for the reduced memory allocation) and we're back where we started?
Seems like moving the furniture around.
No doubt I've misunderstood.
Re: The computers are fast, but you don't know it
#750Earlier quoted context omitted.
> Like I said, the vast majority of code optimization opportunities are not worth taking. Some are, but only after running the numbers. Casey Muratori said it best: there are 3 philosophies of optimisation. You're talking about the first: actual optimisation where you measure and decide what to tackle. It's rarely used, and with good reason. The second philosophy however is very different: it's non-pessimisation . Th…
I'm actually also talking about the second. > avoid having the CPU do useless work all the time It's not worth an engineer spending 1h a year even investigating this, if it's less than 20 CPU cores doing useless work. The break even for putting someone full time on this is if you can expect them to save about fourty thousand CPU cores. YMMV. Maybe you're a bank who has to have everything under physical control, and y…
In the specific case of batch processing, I hear you. Machine time is extremely cheap compared to engineer time.
Then there are interactive programs. With a human potentially waiting on it. Someone's whose time may be just as valuable as the engineer's time (morally that's 1/1, but even financially the difference is rarely more than a single order of magnitude). If you have as few as 100 users, shaving off seconds off their work is quickly worth a good chunk of your time.
Machine time is cheap, but don't forget that user's time is not.