Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The computers are fast, but you don't know it

shvbsle.in

Post reply on HN
Print view View original

571–580 of 819 posts

Re: The computers are fast, but you don't know it

#571

Post by inkblotuniverse »

floucky wrote: post #510
justsomeuser wrote: post #501

I imagine for most web dev’s using a fast memory unsafe language is like taking a bullet train to the local shop to get milk.

I would say to the local farm, then you have to wait for the cow to be milked (like an external api call...). At the end you just reduced you journey time by 0.1%, and incread you code complexity by 100%.

On the other hand, to non-webdevs, webdevs are like an obese american woman trundling down the road on her mobility scooter, giving the evil eye to people overtaking her on foot as she takes a bite out of a hunk of RAMcheese.

Re: The computers are fast, but you don't know it

#572

Post by mellavora »

jiggawatts wrote: post #337
bombcar wrote: post #329

Earlier quoted context omitted.

Or another way to look at it - the computer can do an absolute insane amount of math in the time it takes to roundtrip a single byte to the datacenter in US-West.

The more generic way I like to put it is that throughput has been improving exponentially for decades thanks to Moore's law, but latency hasn't changed much at all and has a hard limit due to the speed of light. Hence the ratio between latency and compute has been changing exponentially. Even a linear or quadratic change would be dramatic, but exponential is something people just can't wrap their heads around. They'r…

> slower than a network hope.

Sometimes typos contain wisdom

Re: The computers are fast, but you don't know it

#573

Post by gpderetta »

knorker wrote: post #287
pjvsvsrtrxc wrote: post #99

Earlier quoted context omitted.

> But here's the thing: it's cheaper to waste thousands of CPU cores on bad performance than to have an engineer spend a day optimizing it. No, it really isn't. It's only cheaper for the company making the software (and only if they don't use their software extensively, at that).

It depends. Run the lifetime cost of a CPU, and compare it to what you pay your engineers. It's shocking how much RAM and CPU you can get for the price of an hour of engineer time. And that's not even all! Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent. And if it has a bug because it sacrificed some simplicity? That's human hours or days. And that's not eve…

> Next time someone reads the code, if it's "clever" (but much much faster) then that's more human time spent.

yet piles and piles of abstractions are considered acceptable and even desirable while having significant negative effects on code readability.

Re: The computers are fast, but you don't know it

#574

Post by soco »

carlmr wrote: post #532
moffkalast wrote: post #529

Earlier quoted context omitted.

> that results in more education time for programers, which no company is willing to pay for That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things. Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

I program Java to earn my living and any hierarchy deeper than two is a bad smell for me. Not that it cannot have its place, but most of the time you're right, some find so fascinating to inherit everything from everything...

Re: The computers are fast, but you don't know it

#575

Post by pjmlp »

bayindirh wrote: post #531
pjmlp wrote: post #526

Earlier quoted context omitted.

> Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you. I always find this remark amusing, given that Java adopted the common patterns in C++ toolkits that precedded Java. If anything they are writting C++ like it used to be on Turbo Vision, Object Windows Library, MPW, PowerPlant, MFC, wxWindows,....

The remark is rooted from variable naming and code organization mostly. I've seen a C++ codebase transferred to a java developer, and he disregarded everything from the old codebase. Didn't refactor the old code, and the new additions were done Java Style. CamelCase file/variable/function names, every class on its own file with ClassName.cpp files littered everywhere, it was a mess. The code was math-heavy, and becam…

So basically " like it used to be on Turbo Vision, Object Windows Library, MPW, PowerPlant, MFC, wxWindows,..."

Re: The computers are fast, but you don't know it

#576

Post by gpderetta »

doliveira wrote: post #322
pelorat wrote: post #262

Earlier quoted context omitted.

But who compares Python with C#, they are not even in the same league? Python is a glorified bash scripting replacement with a mediocre JIT engine. Modern C# is faster than Go which is what it is competing against.

Does Python even have JIT?

certainly not the standard CPython.

Re: The computers are fast, but you don't know it

#577

Post by carlmr »

soco wrote: post #574
carlmr wrote: post #532

Earlier quoted context omitted.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things. Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

I program Java to earn my living and any hierarchy deeper than two is a bad smell for me. Not that it cannot have its place, but most of the time you're right, some find so fascinating to inherit everything from everything...

I remember sitting in these lectures thinking, why not just use a function without all the boilerplate? And a decade later the programming world finally came back to some semblance of sanity.

Re: The computers are fast, but you don't know it

#578

Post by kllrnohj »

loup-vaillant wrote: post #511
kllrnohj wrote: post #325

Earlier quoted context omitted.

That is a radically gross misunderstanding of what undefined behavior is and how it can (and mostly how it cannot) propagate.

Actually it's not, Chandler Carruth notwithstanding. If your C++ program exhibit undefined behaviour, the compiler is allowed to format your entire hard drive. Or encrypt it and display a "plz pay BTC" message. That's called a vulnerability. Real and meaningful security checks have been removed as "dead code" because of signed integer overflow (which is undefined behaviour by default). If anything, I would guess the…

> If your C++ program exhibit undefined behaviour, the compiler is allowed to format your entire hard drive. Or encrypt it and display a "plz pay BTC" message.

No, it isn't. That's a completely made up fabrication. And if you had a compiler that was going to do that, then what the standard says or if there's undefined behavior is obviously not relevant or significant in the slightest.

The majority of the UB optimization complaints are because the compiler couldn't tell that UB was happening. It didn't detect UB and then make an evil laugh and go insane. That's not how this works.

Compilers cannot detect UB and then do things in response within the rules of the standard. Rather, they are allowed to assume UB doesn't happen. That's it, that's all they do. They just behave as though your source has no UB at all. As far as the compiler is concerned, UB doesn't exist and can't happen.

When a compiler can detect that UB is happening it'll issue a warning. It never silently exploits it.

> Real and meaningful security checks have been removed as "dead code" because of signed integer overflow (which is undefined behaviour by default).

Real and meaningful security checks have been removed because the security check happened after the values were already used in specific ways, not because of UB. The values were already specified in the source code to be a particular thing via earlier usage. UB is just the shield for developers who wrote a bug to hide behind to avoid admitting they had a bug.

Use UBSAN next time.

> even if it could easily be well defined, like signed integer overflow on 2's complement platforms.

Signed integer overflow is defined behavior, that's not UB. Also platform specific behavior is something the standard doesn't define - that's why it was UB in the first place.

It is kinda ridiculous it took until C++20 for this change, though

Re: The computers are fast, but you don't know it

#579

Post by 2143 »

reacharavindh wrote: post #440
dragontamer wrote: post #60

Earlier quoted context omitted.

> 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. The latency on multiplication (register input to register output) is 5-clock ticks, and many computers are 4GHz or 5GHz these days. 5-clock cycles at 5GHz is 1ns, which is 30-centimeters of light travel. If we include L1 cache read and L1 cache write, IIRC its 4 clock cycles for read + 4…

This reminds me of that “todo” I wrote for myself a long time ago. These days processors come with bigger L1,L2, and L3 caches. Would it be possible for a program that works on a tiny bit of data(few KB) to load it all up in the cache and provide ultimate response times?! Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

> Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

I'm probably the worst person to explain this.

Long long ago, I took a parallel programming class in grad school.

It turns out the conventional way to do matrix multiplication results in plenty of cache misses.

However, if you carefully tweak the order of the loops and do certain minor modifications — I forget the details — you could substantially increase the cache hits and make matrix multiplication go noticeably faster on benchmarks.

Some random details that may be relevant:

* When the processor loads a single number M[x][y], it sort of loads in the adjacent numbers as well. You need to take advantage of this.

* Something about row-major/column-major array is an important detail.

What I'm trying to say is, it is possible to indirectly optimize cache hits by careful manual hand tweaking. I don't know if there's a general automagic way to do this though.

This probably wasn't very useful, but I'm just putting it out there. Maybe more knowledgeable folks can explain this better.

Re: The computers are fast, but you don't know it

#580

Post by dzaima »

kaba0 wrote: post #552
dzaima wrote: post #540

Earlier quoted context omitted.

It's not even just memory access patterns. It's any and all abstractions - C doesn't provide any, so you write things manually, and thus won't do things that are not required for your use-case (whether it be separated loops for actions, pre-initialization/zeroing, multiple allocations where one or none could do, and higher-level stuff like no need for iterator stability, a vector push that assumes reserved space, etc…

Well, lack of abstraction can easily hinder performance as well. Just compare C’s string management story with that of C++. (Also, for very performance-oriented workloads, C++ will be preferred). In case of C you only have dumb c strings, on which you will iterate many many times completely needlessly. It is both error prone, and less performant than C++’s strings, which can do small string optimizations (storing the…

I'd say the case of C strings is more a case of a bad abstraction C has (at least historically), rather than lack of one. But the things that expect them are just the standard library (which doesn't have many useful general-purpose things anyway), so you can write your strings as a pair/struct of char*+length or whatever else you may want just fine.

Small string optimizations, while nice (and probably do average out to being beneficial), aren't always needed, and the extra generated code for handling both cases could make it not worth it if you've got a fast allocator, and can even make some operations just outright slower. (and if your code doesn't actually have strings anywhere near hot loops, all you get is a larger binary). File paths, for example, are often large enough to not fit the small case, but still small enough where even the check for whether it is small can be a couple percent of allocation/freeing.

Being error-prone, though, is something that I can agree with. That's the cost of doing things manually.

(I'd also like to note that malloc/free are a much more important case of a bad abstraction - they have quite a bit of overhead for being able to handle various lengths & multithreading, while a big portion of allocations is on the same (often, only) thread with a constant size, and said size being known at free-time, which is a lot more trivial to handle; not even talking about the cost of calling a non-inlined function spilling things to the stack)

Post reply on HN