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

671–680 of 819 posts

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

#671

Post by treeman79 »

jiggawatts wrote: post #397
Tostino wrote: post #374

Earlier quoted context omitted.

That's a quite simple query to just about any database.

Is it though? This goes back to my point of architects and developers having internalised thoroughly outdated rules of thumb that are now wrong by factors of tens of thousands or more . This is not a simple problem to solve efficiently using traditional RDBMS query APIs because they're all rooted in 1980s thinking of: "The network is fast, and this is used by human staff doing manual data entry into a GUI form." Let'…

Brilliant explanation.

If I was to rebuild that python script application today.

to try and match 100,000 records against 10 million. If I were to do it in a database driven micro architecture solution. I’m not sure if I could come up with that returns results faster even using up probably a million times more clock cycles.

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

#672

Post by kcartlidge »

perryizgr8 wrote: post #505
grishka wrote: post #77

Earlier quoted context omitted.

I remember a video of a guy running an old version of Visual C++ on an equally old version of Windows, in a VM on modern hardware, to try Windows development "the old way". It took about one frame to launch. One. Frame. By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max. edit: probably this video https://youtu.be/j_4iTovYJtc?t=282

> It took about one frame to launch. One. Frame. I really liked Win 2000 because of this feeling of speed. Most programs would simply "open" when you clicked their icon. There wouldn't be a loading screen. I remember getting frustrated because I could not look at the pretty spalsh screen that Excel had added because it would flash and disappear in milliseconds. Amd this was on hardware of that time.

> I really liked Win 2000 because of this feeling of speed

Upvoted for bigging up my favourite (relatively speaking) Windows version. Still have my original disks.

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

#673

Post by BeFlatXIII »

kllrnohj wrote: post #315
fleddr wrote: post #65

Earlier quoted context omitted.

I think it's even stronger than a habit. When you're exposed to the typical "performance" of the web and apps for a decade or so, you may have forgotten about raw performance entirely. Young people may have never experienced it at all. I once owned a small business server with a Xeon processor, Linux installed. Just for kicks I wrote a C program that would loop over many thousands of files, read their content, sort i…

Shit performance is what happens when every response to optimizations or overhead is immediately answered with "premature optimization is the root of all evil." Or the always fun "profile it!" or "the runtime will optimize it" when discussing new language features and systems. So often performance isn't just ignored, it's actively preached against. Don't question how that new runtime feature performs today or even da…

Wouldn't "profile it!" be the exact opposite if ignoring performance wins? It tells you which optimizations will noticeably improve your performance and which are theoretical gains that made no difference to realistic workloads.

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

#674

Post by BeFlatXIII »

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.

As the poster child of poor performance even on new iPhones, there is always Pokémon Go (produced with Niantic levels of competence)

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

#675

Post by BeFlatXIII »

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…

How many of the better languages have equal or better readability than Python? IMO, that's the #1 reason for its continued popularity. Python is not full of parentheses, like a lisp, nor is it full of semicolons and brackets for bookkeeping, like most other C-style languages.

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

#676

Post by morelisp »

khalladay wrote: post #639
von_lohengramm wrote: post #603

Earlier quoted context omitted.

I'd argue that SSDs have done more harm than good. Since the worst-case is now far superior that it used to be (HDDs), most developers see no need to optimize any further. For example, plenty of video game engines will stream copious amounts of data from disk instead of optimizing memory usage, asset size, and in general more creative solutions (i.e. shader effects instead of GBs of redundant assets). If hitting the…

Ah yes game engine development, where we herd all the lazy folks who hate efficient solutions to problems.

It's not about (in)efficiency but creativity and development budgets.

If you have "unlimited" fast storage, the most technically efficient way to render highly-detailed realistic assets is to underpay a bunch of artists to make a metric ton of highly-detailed realistic assets, then stream them in off disk.

If you don't have that storage, the most efficient way might be to make a smaller number of assets modulated by some technical work, which is more accessible to smaller teams who have one top-shelf programmer but no army of contract artists. Or, the team is forced into a non-realistic art style which gives artists and the industry as a whole more space to design in.

It also means that when you do blow your technical budgets for whatever reason (e.g. nobody upgrades their SSDs for 2 years due to a chip shortage so your median performance projections for release were way off), it starts getting much worse very fast.

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

#677

Post by necovek »

throwaway894345 wrote: post #642
necovek wrote: post #560

Earlier quoted context omitted.

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 inv…

> even though there are workarounds to make that 1-10x slower rather than 100-1000X (eg. C-based implementations, including all the itertools stuff). These only apply for specific problems, and very few applications are purely CSV parsing or purely matrix math operations. In the real world, you often spend more time marshaling your Python data to C than you save by doing your computation in C. > But as you note, bott…

> The bottleneck in a static site generator is I/O. The fact that Python, Ruby, etc based implementations take tens of seconds or more while Go and Rust finish instantly for an I/O bound problem is pretty damning.

My point was that if this was the case, your Python code is probably suboptimal.

Sure, you are comparing against naive implementation as well, but if performance is a concern, don't do naive Python :)

> I gave the example earlier of a web service that was struggling to complete requests in even 60s (despite using Numpy under the hood where possible) while a naive Go implementation completed in hundreds of ms.

Yes, it's easy and sometimes even idiomatic to write non-performant Python code. Getting the most out of pure Python is hard and it means avoiding some common patterns.

Eg. simply using sqlalchemy ORM (to construct rich dynamic ORM objects) instead of sqlalchemy core (tuples) to get 100k+ rows from DB is 20x slower, and that's still 2x slower from pure psycopg (also tuples using basic types). There are plenty of examples like this in Python, unfortunately.

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

#678

Post by corrral »

moffkalast wrote: post #36
Guest19023892 wrote: post #26

Earlier quoted context omitted.

I upgraded a desktop machine the last time I visited my family. It was a Windows 7 computer that was at least 10 years old with 4GB of ram. They wanted to use it online for basic web browsing, so I thought I'd install Windows 10 for security reasons and drop in a modern SSD to upgrade the old 7200rpm drive to make it more snappy. Well, it felt slower after the "upgrade". Clicking the start menu and opening something…

That's interesting, I cloned a Win10 installation on a HDD to a sata SSD a year or two back and the speed difference was considerable. Especially something like Atom that took minutes to open before was ready to go in like 10 seconds afterwards. A lot of things remained slow though.

Somewhere around IIRC Win8 Microsoft must have gotten really lax about minimizing disk access. Windows started being slow as molasses on an HDD, even for stuff like opening the start menu.

This hurts performance a ton on SSDs, too, it's just less noticeable. Something that should happen so fast you can hardly measure how long it takes, takes... just long enough to notice, which may amount to 100x as long as it should take, but 100x a small number is still pretty small.

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

#679

Post by morelisp »

bheadmaster wrote: post #551
moffkalast wrote: post #528

Earlier quoted context omitted.

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 i…

> Channel reading and writing is isomorphic to read() and write() syscalls

This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).

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

#680

Post by imtringued »

danybittel wrote: post #419
cozzyd wrote: post #414

Earlier quoted context omitted.

That branch predictor is working really well!

Isn't it crazy how the branch predictor is something like 99% percent correct. Which means a computer is almost deterministic, it almost knows the future. A tiny bit better and we wouldn't need to show up in office. Of course multiply this by the sheer number of calculations and even that little misprediction results in huge differences. The reality is actually quite sobering: a computer mostly calculates the same th…

When you execute a loop 1000 times it is only going to change branches once the loop finishes. If you always predict that the loop didn't finish, your branch predictor will correctly predict 99.9% of branches.
Post reply on HN