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

551–560 of 819 posts

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

#551

Post by bheadmaster »

moffkalast wrote: post #528
paskozdilar wrote: post #515

Earlier quoted context omitted.

Go fills that spot for me. I've done video4linux stuff in Go, and passing an unsafe.Pointer to a Go struct in an ioctl() worked fine, which tells me that Go structs are isomorphic to C structs. Even though Go has garbage collection, it allocates everything it can on the stack, so only long-lived shared-between-goroutines objects are subject to garbage collection. Go abstracts concurrency, completely removing all conc…

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 if there is another goroutine blocked on a write operation, and ready for writing if there is another goroutine blocked on a read operation.

You say you're from C background - if you've ever worked will file descriptors you will notice that channels are basically userspace file descriptors. Channel reading and writing is isomorphic to read() and write() syscalls, and select keyword is isomorphic to select() syscall.

Hopefully this clears up the whole channel syntax thing. I just hope you weren't trolling.

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

#552

Post by kaba0 »

dzaima wrote: post #540
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…

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 string inside the structure if it fits, and being a pointer to it otherwise).

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

#553

Post by necovek »

Panzer04 wrote: post #412
w0mbat wrote: post #392

Article says at one point, "We have reduced the time for the computation by ~119%!", which is impossible. If you reduce it by 100% it is taking zero time already.

"faster" vs "reduced time". Many people confuse rate of work with reduction in time, and it's exceptionally annoying :(

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).

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

#554

Post by xigoi »

ben_w wrote: post #83
hamstergene wrote: post #58

On mobile devices it is more serious than just bad craftsmanship & hurt pride, bad code is short battery life. Think mobile game that could last 8 hours instead of 2 of it wasn’t doing unnecessary linear searches on timer in JavaScript.

There was one place where a coworker had written a function that converted data from a proprietary format into a SQL database. On some data, this took 20 minutes on the test iPhone. The coworker swore blind it was as optimised as possible and could not possibly go faster, even though it didn't take that long to load from either the original file format or the database in normal use. By the next morning, I'd found it…

This is why all programmers should know their asymptotic complexity.

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

#555

Post by bbojan »

remuskaos wrote: post #105
bbojan wrote: post #18

Earlier quoted context omitted.

I recently ported some very simple combinatorial code from Python to Rust. I was expecting around 100x speed up. I was surprised when the code ended running only 14 times faster.

Did you use python specific functions like list comprehensions, or "classic" for/while loops? Because I've found the former to be surprisingly fast, while naive for loops are incredibly slow in python.

I've used list comprehensions where they make sense. But it's a non-trivial (although a simple) program, so there are for loops too.

So I'm using a mix of chain and permutations from itertools, list comprehensions and for loops.

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

#556

Post by hermitcrab »

hnhn wrote: post #484
hermitcrab wrote: post #469

I have written some data wrangling software in pure C++. I would like to benchmark it again Pandas to see how the speed compares. Does anyone know if there is a good set of Pandas benchmarks that I can create a comparison to? Even better if it has an R comparison.

The data.table package in R often produces benchmarks that include pandas, e.g. https://h2oai.github.io/db-benchmark/

Thanks.

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

#557

Post by bheadmaster »

kaba0 wrote: post #544
skohan wrote: post #522

Earlier quoted context omitted.

Go strikes me as one of the best "good enough" languages we have right now. You're not going to do HPC in Go, but it's performant enough to run circles around a lot of high level languages and dynamic languages. It abstracts away the stuff that's super error prone about manual memory management, and it's so brutally simple that it's hard for one of your colleagues to write code you're not going to be able to understa…

> but it's performant enough to run circles around a lot of high level languages and dynamic languages It ain’t running circles around any managed language, with perhaps the exception of Python. C#, Java, JS all have comparably good performances, sometimes much better - e.g. when GC can’t be avoided.

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.

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

#558

Post by necovek »

munificent wrote: post #68
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…

I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

In a sense, knowing this can also hurt you.

At all my recent jobs, I grow frustrated with how slow running a single unit test is locally on a codebase. We are talking 5+ seconds for even the most trivial of trivial unit tests (say, purely functional arithmetic unit test).

And this is even with dynamic languages like Python (you see pytest reporting how your unit test completed in 0.00s, and wall time is 7s).

And then I get grumpy if they don't let me go and fix it because I am the only one who is that annoyed with this :D

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

#559

Post by xaedes »

korla wrote: post #517
journey_16162 wrote: post #514

As a front-end developer, I can't help but notice how much useless computation is going on in a fairly popular library - Redux. It's a store of items, if just one tiny items change in the whole store, every subscriber of every item gets notified and a compare function is ran to check if it changes. Perhaps I'm misunderstanding something and not to bash on Redux - I'm sure there are well-deserved reasons it got popula…

I think developer speed is more important than optimising clock cycles unnecessarily. Generally writing to dom is much much slower than evaluting a few thousand expressions. For the cases when it's not, use memo.

> I think developer speed is more important than optimising clock cycles unnecessarily.

Developer time is spent once. Users will always have to pay the price of additional run time. For. Each. Single. User. Always.

It scales!

Due to the scale of, e.g. slow front-ends, with millions of users, this takes a HUGE amount of time. Only to save a few hours or days to develop it better.

Having 1 million users each wait a single second is already 11 days. If they have to wait that single second for each interaction, it quickly adds up.

It is also bad for the environment due to scaled up inefficiency and resulting increase of power usage.

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

#560

Post by necovek »

throwaway894345 wrote: post #163
munificent wrote: post #68

Earlier quoted context omitted.

I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

Yeah, I've written static site generators in Go and Rust among other languages (it's my goto project for learning a new language). Neither needed incremental builds because they build instantly. The bottlenecks are I/O. I've also worked in Python shops for the entirety of my career. There are a lot of Python programmers who don't have experience with and thus can't quite believe how much faster many other languages a…

Python is slow in many things like pure looping and arithmetic, even though there are workarounds to make that 1-10x slower rather than 100-1000X (eg. C-based implementations, including all the itertools stuff).

I am sometimes frustrated that I can't just loop over a string character by character and not get crappy performance, but the "problem" you (and me) are seeing in existing codebases is that Python is very inviting to beginners, and they are not frustrated with this because they don't know it :)

But as you note, bottleneck is the I/O, and a program waiting for I/O in Python and I/O in C will wait the same time after the computation is done.

If you are writing software that can parallelize well independently (eg. web apps) and your memory pressure is not the most important thing, you simply run multiple Python processes to max out the CPU (this avoids the GIL unlike async Python). And you keep your dependencies low.

Post reply on HN