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

511–520 of 819 posts

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

#511

Post by loup-vaillant »

kllrnohj wrote: post #325
rot13xor wrote: post #280

Earlier quoted context omitted.

The biggest weakness of C++ (and C) is non-localized behavior of bugs due to undefined behavior. Once you have undefined behavior, you can no longer reason about your program in a logically consistent way. A language like Python or Java has no undefined behavior so for example if you have an integer overflow, you can debug knowing that only data touched by that integer overflow is affected by the bug whereas in C++ y…

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 gross misunderstanding sprouted somewhere between the specs and the compiler writers. Originally, UB was mostly about bailing out when the underlying platform couldn't handle this particular case, or explicitly ignoring edge cases to simplify implementations. Now however it's also a performance thing, and if anything is marked as UB then it's fair game for the optimiser — even if it could easily be well defined, like signed integer overflow on 2's complement platforms.

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

#512

Post by knorker »

Dylan16807 wrote: post #461
lmm wrote: post #407

Earlier quoted context omitted.

If faster software was worth anything to people surely they'd pay for it.

That only applies to homo economicus.

And ones with a choice.

Given the choice between program X and program X plus higher speed at higher cost, some will choose the latter.

But that's never the choice. All else is not equal.

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

#513

Post by denzil »

forinti wrote: post #22

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

This comparison reminds me of Grace Hopper explaining how long nanosecond is: https://www.youtube.com/watch?v=9eyFDBPk4Yw

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

#514

Post by journey_16162 »

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 popular, but to me that just sounds insane and the fact that it got so much widespread adoption perfectly reflects how little care about performance is given nowadays.

I don't use a high-end laptop and I'm not eager to upgrade is because I can relate to the average user of the software I develop. I saw plenty of popular web apps feeling really sluggish.

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

#515

Post by paskozdilar »

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?

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 concurrent features from a language except for the "go" keyword (that launches a goroutine - which is basically a tiny virtual thread), channels (which are selectable queues) and "select" keyword that waits for the first "input" from a static set of channels.

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

#516

Post by saberience »

d110af5ccf wrote: post #434
CMCDragonkai wrote: post #432

Earlier quoted context omitted.

Is the speed of light really the speed of causality? Would the effect of gravity (the lack of) affect Earth earlier than us perceiving the lack of light.

Nope. All physical effects are bounded by the speed of light. (As far as anyone knows, anyway.) The only weird one is quantum entanglement, but even then information transfer doesn't travel faster than light and that's about all I know on that subject.

Why does gravity travel at the speed of light?

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

#517

Post by korla »

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.

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

#518

Post by anfelor »

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?

Ocaml 5 and Koka (https://koka-lang.github.io/koka/doc/index.html) can get quite close to the speed of C...

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

#519

Post by enriquto »

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?

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

Fortran is fine. Also lua (using the luajit interpreter you get really close to C speed) and julia (except for the atrocious startup time).

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

#520

Post by pjmlp »

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?

Pascal dialects, Modula-2 are of a similar age, while other like JOVIAL are a decade older but they did not come with a very big killer feature, an OS like UNIX.

Then there were BLISS, Mesa and PL/I, but the OSes that made use of them lost to UNIX, so.

With exception of Mac OS, written in Object Pascal and later ported to a mix of Object Pascal and C++.

Having said this, plenty of alternatives with AOT compilers exist nowadays.

The only thing C has going for it, is historical weight, UNIX/POSIX ecosystem, and some domains that are closed to any alternative suggestions, due to tooling or cargo cult against alternatives.

Post reply on HN