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

761–770 of 819 posts

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

#761

Post by stuffbyspencer »

Balgair wrote: post #759
rufus_foreman wrote: post #752

Earlier quoted context omitted.

>> The first time I ran the program, it finished in a couple seconds. I was sure something must have failed At one of my first jobs I was a DBA supporting a CRUD app in the finance industry. The app had one report that took forever and usually timed out, I was told to take a look at it. The DB query was just missing a couple indexes so I added those. After I added them, my boss told one of the users of the app to try…

If I recall correctly, the first few ATMs near Wall Street had the same issue. They were too fast and people were suspicious. They had to add in a delay so folks would feel alright using them.

That's pretty funny, and is literally what I did with a CLI tool I made once. It was supposed to loop through something that was over 10,000 entries long. It finished in under a second.

I decided to add a small fraction of a second every X iterations and output some garbled data to the terminal. I got paid a nice little sum because of that. Sometimes, knowing how to make something look complicated is as important as doing something complicated.

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

#762

Post by Too »

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.

Memory write errors (some times induced by UB) in one place of the program can easily propagate and later fail in a very different location of the program, with absolutely zero diagnostics of why your variable suddenly had a value out of possible range.

This is why valgrind, asan and friends exist. They move the error diagnostic to the place where error actually happened.

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

#763

Post by morelisp »

igouy wrote: post #749
morelisp wrote: post #717

Earlier quoted context omitted.

Alright, I guess I'll admit this just sniped me. Having read the rules it's difficult to know what's considered "fair" for this test - all GC tuning is off the table, sure. But what's bugging me is "Leaf nodes must be the same as interior nodes - the same memory allocation." So what constitutes "the same memory allocation" - literally the exact same call to some opaque internal allocator? If so, shouldn't Java also h…

And then the Java etc programs are re-written to do the same and the test value is increased (to compensate for the reduced memory allocation) and we're back where we started? Seems like moving the furniture around. No doubt I've misunderstood.

A null value in Java has no methods / is not an object. I didn’t precompute anything.

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

#764

Post by Too »

Spivak wrote: post #203
dgan wrote: post #67

Earlier quoted context omitted.

at that point, almost anything compiled will be at least an order of magnitude faster than python

The dichotomy between "compiled/interpreted" languages is completely meaningless at this point. You can argue that Python is compiled and Java is interpreted. I mean one of our deployment stages is to compile all our Python files. The thing that makes the difference isn't the compilation steps, it's how dynamic the language is and how much behind the scenes work has to be done per line and what tools the language giv…

No, compiling JIT like Java/.NET/V8 becomes real cpu machine instructions on the fly.

Compiling to .pyc files is still byte code that later the python interpreter will read in what is more or less a gigantic while(true)switch/case (operation_type). What you save with pyc compilation is just the text parsing of the source code.

How dynamic the language is, does however affect how feasible it is to do JIT compilation and here python has done itself a big disfavor of simply being too dynamic. Some attempts at JITing it have been done before (pypy, ironpy), usually by nerfing the language a bit to get rid of the most dynamic parts - something that is probably for the better anyway.

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

#765

Post by hinkley »

gilbetron wrote: post #758
necovek wrote: post #748

Earlier quoted context omitted.

Language is, as you nicely point out, very tricky. Yeah, when talking of speed, you can clearly go more than 100% faster. But when talking of something taking a certain amount of time, like done in most benchmarks, it can't be made more than 100% faster.

You can because when you say 100% faster, it is referring to speed, and so you convert to speed than calculate time from that. Language matters :)

> We have reduced the time for the computation by ~119%!

You can say 100% faster when you are talking about speed. You can't say 100% faster when you are talking about duration. "Reduced the time" is talking about duration.

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

#766

Post by hinkley »

pindab0ter wrote: post #487
Panzer04 wrote: post #412

Earlier quoted context omitted.

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

Bonus points if the 'speed is faster'.

Oh, but we let people say "acceleration is faster". It's like we've reserved 'faster' for a single derivative and banned it for all the others.

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

#767

Post by hinkley »

necovek wrote: post #558
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…

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…

How on earth are you getting 5 seconds for simple tests? Simple tests should be running in 8ms, and those are my 2015 numbers that I've been too lazy to update.

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

#768

Post by rboes »

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…

I did that assignment. Did you go to uw?

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

#769

Post by hinkley »

vbezhenar wrote: post #21
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…

Back in time all you needed for perfect performance is to use C and proper algorithms. It was easy. Nowadays you need vector operations, you need to utilise GPU, you need to utilise various accelerators. For me it is black magic.

Brian Cantrill has a video out there where he rewrote some C code in Rust and the benchmark was enough faster that he couldn't make sense of it. After much digging it turned out that it was because Rust was using a better data structure to represent the data, one that's difficult to get right in C.

In the end his test was comparing algorithms not compilers, but there is still something to that: we always make algorithmic compromises based on what is robust and what is brittle in our language of choice. The speed limits don't matter if only a madman would ever drive that fast.

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

#770

Post by Too »

pdimitar wrote: post #618

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…

Completely agree that objectively, Python has really bad underlying tech.

Emotionally though (once you have the environment set up), it’s just such a breeze to write it. It’s like executable pseudo code with zero boilerplate. You can focus purely on the algorithms and business logic. Compared to many other languages the line count is often 50-80%, even if you include type annotations! This doesn’t only apply to plain imperative code, using the dynamic features you can also turn it into your own DSL where needed.

Then there is obviously the huge eco-system around it, there is not a single service, file format or database that doesn’t have a good python library for it. While go might have equally wide library choices, I wouldn’t be so sure about nim, go on the other hand has a lot of other wtfs even though it provides a lot of good fresh tech.

Would I use it for a big service with potentially lots of performance requirements? No. But there is no doubt why it’s so popular. For many applications where the the outcome of the program is more important than the performance or environment, like glue code, simple intranet applications or exploratory coding, it is still the perfect choice. You also have to consider what it is replacing, often the alternative would be even worse; bash-scripts, Excel or Matlab.

Another way to put it is that it’s a very good Swiss Army knife that is good at everything but not best at anything.

Post reply on HN