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

591–600 of 819 posts

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

#591

Post by tester756 »

archi42 wrote: post #545
tester756 wrote: post #206

Earlier quoted context omitted.

>No one uses ten different tools to build one application. I meant you have a lot of choices to make Instead of having one strong standard which everyone uses, you have X of them which makes changing projects/companies harder, but for solid reason? I don't know. >"and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated...…

Compiling a large number of files on Windows is slow, no matter what language/compiler you use. It seems to be a problem with the program invocation, which takes "forever" on Windows. It's still fast for a human, but it's slow for a computer. Quite apt this comes up here ;-) Source for claim: That's a problem we actually faced in the Windows CI at my old job. Our test suite invoked about 100k to 150k programs (our pr…

It's crazy that they have multiplied files count by 7 meanwhile the code just by 2

is it some C++ header file overhead? or they do something specific?

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

#592

Post by [deleted] »

knorker wrote: post #475
pjvsvsrtrxc wrote: post #333

Earlier quoted context omitted.

Servers are expensive, too. Humans waiting on servers to process something is even more expensive. No software runs in a vacuum; someone is waiting on it somewhere. Adding more servers doesn't generally make things faster (latency). It only raises capacity (bandwidth). It does, however, generally cost quite a bit on development. Just about the only thing worse than designing a complex system is designing a complex di…

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…

[deleted]

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

#593

Post by inkblotuniverse »

knorker wrote: post #475
pjvsvsrtrxc wrote: post #333

Earlier quoted context omitted.

Servers are expensive, too. Humans waiting on servers to process something is even more expensive. No software runs in a vacuum; someone is waiting on it somewhere. Adding more servers doesn't generally make things faster (latency). It only raises capacity (bandwidth). It does, however, generally cost quite a bit on development. Just about the only thing worse than designing a complex system is designing a complex di…

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.

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

#594

Post by thanzex »

If anything this is a testament to how slow python can be, and most importantly how easily it pushes you to write miserably unoptimized code.

It could be a bit overkill, but whenever I'm writing code on top of optimizing data structures and memory allocations I always try to minimize the use of if statements to reduce the possibility of branch prediction errors. Seeing woefully unoptimized python code being used in a production environment just breaks my heart.

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

#595

Post by [deleted] »

ano88888 wrote: post #462
skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

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

[deleted]

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

#596

Post by skohan »

kaba0 wrote: post #569
bheadmaster wrote: post #557

Earlier quoted context omitted.

Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.

Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server). Benchmarks are hard to do right but this one does actually measure GC quite well: htt…

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.

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

#597

Post by baobob »

thanzex wrote: post #594

If anything this is a testament to how slow python can be, and most importantly how easily it pushes you to write miserably unoptimized code. It could be a bit overkill, but whenever I'm writing code on top of optimizing data structures and memory allocations I always try to minimize the use of if statements to reduce the possibility of branch prediction errors. Seeing woefully unoptimized python code being used in a…

the CPU branch predictor is so many levels down it will have almost no discernible effect on anything you might call a branch in Python code. Even a statement like "a = 1" likely executes a few tens if not a few hundred branches

That is not to say aiming for generally unbranchy code is not a good thing - that often implies well designed code and well chosen data structures anyway

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

#599

Post by zinodaur »

kaba0 wrote: post #569
bheadmaster wrote: post #557

Earlier quoted context omitted.

Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.

Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server). Benchmarks are hard to do right but this one does actually measure GC quite well: htt…

Wow, I had no idea that java was so fast. One thing I like about go is that you can cram many thousands of concurrent requests into the same process. But it looks like java has some pretty robust async tools... So I bet you could do something similar

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

#600

Post by kaba0 »

dzaima wrote: post #580
kaba0 wrote: post #552

Earlier quoted context omitted.

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…

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.

But I do agree that maybe your allocation example is a better one, though the solution to that is perhaps a full GC, which does have a few tradeoffs (which are worthy to take more often than not).

Post reply on HN