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

611–620 of 819 posts

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

#611

Post by knorker »

inkblotuniverse wrote: post #593
knorker wrote: post #475

Earlier quoted context omitted.

I'm of course aware of all this. If you don't want to take the advise of running the numbers that's up to you. E.g. if end user latency is 10ms (and it's not voip or VR or something) then that's fast enough. Doesn't matter if it's optimizable to 10 us. If this is code running on your million CPU farm 24/7, then yeah. But always run the numbers first. Like I said, the vast majority of code optimization opportunities a…

You should, however, not pessimize. People make cargo-cult architecture choices that bloat their codebase, make itnless readable, and make it 100x slower.

Maybe.

Using actual numbers vetted by actual expenses in an actual company, if you can save 100 CPU cores by spending 3h a year keeping it optimized, then it is NOT worth it.

It is cheaper to burn CPU, even if you could spend one day a year making it max out one CPU core instead of 100.

It can be better for the business to cargo cult.

Not always. But you should remember that the point of the code is to solve a problem, at a low cost. Reducing complexity reduces engineer cost in the future and may also make things faster.

Put it this way: Would you hire someone at $300k doing nothing but optimizing your pipeline so that it takes one machine instead of one rack, or would you spend half that money (TCO over its lifetime) just buying a rack of machines?

If you wouldn't hire them to do it, then you shouldn't spend current engineers time doing it.

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

#612

Post by megous »

throwaway894345 wrote: post #194
KronisLV wrote: post #164

Earlier quoted context omitted.

C and C++ both have excellent library support, perhaps the best interop of any language out there and platform support that cannot be beat. That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Thus, unless you have a good reason (of which, admittedly, there are plenty) to use C or C++, somet…

> That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought. > Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good lib…

Many PHP and JS programmers can't write secure code either.

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

#614

Post by dzaima »

kaba0 wrote: post #600
dzaima wrote: post #580

Earlier quoted context omitted.

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…

Well the reason this one may be a good example is that you couldn’t do this optimization in C even if you wanted to. You would have to call a function at every use-site to handle your “abstraction”. And the same thing applies in other cases. Also, I’m not sure the added conditional branch will increase the binary too much, and the reason it is inside the c++ stdlib is that it was likely measured and proved beneficial…

Right; making abstractions in C when you really know you should can be messy, but still possible (not with the same syntax, but I personally like the fact that a[b] is 100% guaranteed to be, at most, a single load; similarly for all operations other than function calls; makes it easier to reason about performance at a glance).

Recommending a GC is hard for me though; over your system malloc/free, maybe, but alternative allocators can be very fast, without the drawbacks of pauses (or slower execution as a result from a non-pausing GC).

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

#615

Post by paskozdilar »

kaba0 wrote: post #604
skohan wrote: post #596

Earlier quoted context omitted.

Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response? It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.

But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.

Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.

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

#616

Post by Tomis02 »

solatic wrote: post #455
jerf wrote: post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

> any task that speed is even remotely a consideration for anymore How do you know whether or not speed is a consideration? Yes, OP delivered impressive efficiency gains. I'm sure he could improve the efficiency even more by dropping into pure Assembly. But is it worth it? The prime consideration is not execution speed but maintainability. The further that OP got away from pure Python, the more difficult to maintain…

> The prime consideration is not execution speed but maintainability.

Why? And how did you measure this drop in maintainability? I'm asking because I see developers prioritize _perceived_ maintainability over _measurable_ things that matter to the user (like performance).

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

#617

Post by bernds74 »

qikInNdOutReply wrote: post #509
flohofwoe wrote: post #485

Earlier quoted context omitted.

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…

So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for. What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum me…

> Like, strip those OO-bjects into arrays, or directly pack them into hot-loop structs that have little regard for the Objects they started out with.

I think Jonathan Blow's JAI is trying to do something like this. Unfortunately it isn't exactly available yet, or it wasn't last time I looked.

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

#618

Post by pdimitar »

While I find this comment section fascinating and will read it top to bottom, I can't help but make an observation that such articles often comply with:

    +-------------------------------------------------+
    | People really do love Python to death, do they? |
    +-------------------------------------------------+
I find that extremely weird. As a bystander who never relied on Python for anything important, and as a person who regularly had to wrestle with it and tried to use it several times, the language is non-intuitive in terms of syntax, ecosystem, package management, different language version management, probably 10+ ways to install dependencies by now, subpar standard library and an absolute cosmic-wide Wild West state of things in general. Not to mention people keep making command-line tools with it, ignoring the fact that it often takes 0.3 seconds to even boot.

Why would a programmer that wants semi-predictable productivity choose Python today (or even 10 years ago) remains a mystery to me. (Example: I don't like Go that much but it seems to do everything that Python does, and better.)

Can somebody chime in and give me something better than "I got taught Python in university and never moved on since" or "it pays the bills and I don't want to learn more"?

And please don't give me the fabled "Python is good, you are just biased" crap. Python is, technically and factually and objectively, not that good at all. There are languages out there that do everything that it does much better, and some are pretty popular too (Go, Nim).

I suppose it's the well-trodden path on integrating with pandas and numpy?

Or is it a collective delusion and a self-feeding cycle of "we only ever hired for Python" from companies and "professors teach Python because it's all they know" from universities? Perhaps this is the most plausible explanation -- inertia. Maybe people just want to believe because they are scared they have to learn something else.

I am interested in what people think about why is Python popular regardless of a lot of objective evidence that as a tech it's not impressive at all.

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

#619

Post by kaba0 »

paskozdilar wrote: post #615
kaba0 wrote: post #604

Earlier quoted context omitted.

But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.

Go is much faster than Python, uses less memory, and compiles down to a statically-linked native binary, making containerization trivial. And (IMHO) it's even more readable than Python - nowdays Python code is as easily turned into an unreadable mess as Java or C# code. Just try reading Python standard library and Go standard library - the difference is monumental.

We are talking about business logic. The infrastructure is already in a lower level language, so the performance is not a concern.

And we will have to disagree on C#/Java/Python being unreadable mess. In my experience all 3 can be written in a really well maintainable way. I don’t have much experience with Go, but out of these, I would vote for it as the least maintainable (as just because each line is trivial to understand, doesn’t make the whole program flow easy to read. Otherwise why not just write assembly, every line is even more trivial there)

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

#620

Post by bigDinosaur »

mcbuilder wrote: post #500
ano88888 wrote: post #462

Earlier quoted context omitted.

Why can't we have a language easy to read and maintain but also have the speed of C?

Haskell has an elegance, and can be written as simply as C. Usually fast enough, and can be optimized as well. The downside is that you will be sucked into a rabbit hole of academic type theory and wonder how best to express your system as a Free Monad instead of bashing it out like any sane C programmer. Just kidding, someone already figured out those hard parts for you, you just forgot to browse for it on Hackage.

It's a fair criticism of Haskell that you can fairly easily blow up your time/space complexity without realising it though. I think in many ways it's better but Haskell specifically demands a lot even for a functional language.
Post reply on HN