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

661–670 of 819 posts

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

#661

Post by acoard »

m1el wrote: post #538
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…

Hi, I believe I understand you. If you look at immutable data structures implemented using JS primitives, it will surely look terrible. However, there's a lot of benefit to using a FP approach like Redux. It's much easier to reason about state updates if all you have is pure functions. It allows you avoid very annoying and hard to catch bugs. I've seen this personally, when replacing a spaghetti component with a stra…

Right it’s basically just developer convenience.

So from your post it follows that if a developer can reason about the state changes of their app without redux, they should do so if there are performance concerns. Right?

I say this as a webdev who has written pure vanilla Js SPAs a decade ago, and someone who often uses Redux now on most projects today. So I know it’s totally possible to have performant mutable state management on a project that isn’t a mess - that’s how we always did stuff before redux.

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

#662

Post by jodrellblank »

reacharavindh wrote: post #440
dragontamer wrote: post #60

Earlier quoted context omitted.

> 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. The latency on multiplication (register input to register output) is 5-clock ticks, and many computers are 4GHz or 5GHz these days. 5-clock cycles at 5GHz is 1ns, which is 30-centimeters of light travel. If we include L1 cache read and L1 cache write, IIRC its 4 clock cycles for read + 4…

This reminds me of that “todo” I wrote for myself a long time ago. These days processors come with bigger L1,L2, and L3 caches. Would it be possible for a program that works on a tiny bit of data(few KB) to load it all up in the cache and provide ultimate response times?! Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

One of the claimed advantages of the array programming language "K" is that the interpreter is small enough for the hot paths to stay in the CPU cache. It's hard to Google but claims come from people/places like this thread: https://news.ycombinator.com/item?id=15908394

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

#663

Post by throwaway894345 »

gpderetta wrote: post #563
throwaway894345 wrote: post #173

Earlier quoted context omitted.

I was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).

Python is a powerful yet beginner friendly language with a very gentle learning slope, but I would still take C++ tooling and debuggability any day over Python.

Nah man, I've spent way too much time trying to piece together libraries to turn core dumps into a useful stack trace. Similarly, as miserable as Python package management is, at least it has a package manager that works with virtually every project in the ecosystem. I actually really like writing C++, but there are certain obstacles that slow a developer down tremendously--I could forgive them if they were interesting obstacles (e.g., I can at least amuse myself pacifying Rust's borrow checker), but there's no joy in trying to cobble together a build system with CMake/etc or try to get debug information for a segfault.

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

#664

Post by kaba0 »

paskozdilar wrote: post #659
kaba0 wrote: post #619

Earlier quoted context omitted.

We are talking about business logic. The infrastructure is already in a lower level language, so the performance is not a concern. And we will have to disagree on C#/Java/Python being unreadable mess. In my experience all 3 can be written in a really well maintainable way. I don’t have much experience with Go, but out of these, I would vote for it as the least maintainable (as just because each line is trivial to und…

> In my experience all 3 can be written in a really well maintainable way. That's true, but that is generally true of any (non-toy) language. But in the modern world of rapid development, it matters how hard is it to write code in a non-maintainable way - i.e. how well it tolerates modifications by different people. And to me, it seems easier to write readable code in Go than it is to write unreadable code. It seems…

Could you expand a bit on why do you think Java has too many features? It is a very small language, that is often berated because it picks up features way too slowly if anything.

I would go as far to claim that Java is an easier language than Go, or at least in the same ballpark.

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

#665

Post by kllrnohj »

loup-vaillant wrote: post #658
kllrnohj wrote: post #578

Earlier quoted context omitted.

> 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. No, it isn't. That's a completely made up fabrication. And if you had a compiler that was going to do that, then what the standard says or if there's undefined behavior is obviously not relevant or significant in the slightest. The majority of the UB optimizat…

> > UB allows the to format/encrypt your entire hard drive. > No, it isn't. That's a completely made up fabrication. Ever heard of viruses exploiting buffer overflows to make arbitrary code execution? One cause of that can be a clever optimisation that noticed that the only way the check fails is when some UB is happening. Since UB "never happens", the check is dead code and can be removed. And if the compiler notice…

> C is what it is, and we live with it. Still, it would be unreasonable to say that the amount of UB it harbours isn't absolutely ludicrous.

There's a lot of ludicrous stuff about C and I wouldn't recommend anyone use it for anything. Not when Rust and C++ exist.

But UB really isn't the scary boogie man. There could probably stand to be a `as-is {}` block extension for security checks, but that's really about it.

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

#666

Post by BeFlatXIII »

slotrans wrote: post #252
BeFlatXIII wrote: post #242

Earlier quoted context omitted.

I have an M1 Air right I'm typing on right now and have not had any sluggishness concerns besides when switching between Spaces. Even that is more of a visual stutter instead of actually lagging to the point the animation takes longer than usual. This is the first thin & light computer I've owned that I'm 100% happy with its performance.

Switching between spaces on this M1 takes multiple seconds. It's almost unbearable. My 8-core 64GB Windows machine fares no better. Switching between OLVWM desktops on my 200MHz Pentium Pro twenty years ago was instantaneous.

What are all the apps you have open? Perhaps your use case is far more memory-intensive than mine.

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

#667

Post by gpderetta »

throwaway894345 wrote: post #663
gpderetta wrote: post #563

Earlier quoted context omitted.

Python is a powerful yet beginner friendly language with a very gentle learning slope, but I would still take C++ tooling and debuggability any day over Python.

Nah man, I've spent way too much time trying to piece together libraries to turn core dumps into a useful stack trace. Similarly, as miserable as Python package management is, at least it has a package manager that works with virtually every project in the ecosystem. I actually really like writing C++, but there are certain obstacles that slow a developer down tremendously--I could forgive them if they were interesti…

I won't spend any positive words on cmake (I'm a plain make fan), but...

> or try to get debug information for a segfault

what's the problem with opening the core dump with gdb and looking at the backtrace?

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

#668

Post by loup-vaillant »

kllrnohj wrote: post #665
loup-vaillant wrote: post #658

Earlier quoted context omitted.

> > UB allows the to format/encrypt your entire hard drive. > No, it isn't. That's a completely made up fabrication. Ever heard of viruses exploiting buffer overflows to make arbitrary code execution? One cause of that can be a clever optimisation that noticed that the only way the check fails is when some UB is happening. Since UB "never happens", the check is dead code and can be removed. And if the compiler notice…

> C is what it is, and we live with it. Still, it would be unreasonable to say that the amount of UB it harbours isn't absolutely ludicrous. There's a lot of ludicrous stuff about C and I wouldn't recommend anyone use it for anything. Not when Rust and C++ exist. But UB really isn't the scary boogie man. There could probably stand to be a `as-is {}` block extension for security checks, but that's really about it.

I'm sorry, C++?!?

Granted, C is underpowered and I would like namespaces and generics. But from a safety standpoint nowadays, C++ is just as bad. Not only is is monstrously complex, it still has all the pitfalls of C. C++ may have been "more strongly typed" back in the day, but now compiler warnings made up for that small difference.

Granted, C++ can be noticeably safer if you go RAII pointer fest, but then you're essentially programming in Java with better code generation and a worse garbage collector.

---

There's also a reason to still write C today: its ubiquity. Makes it easier to deploy everywhere and to talk to other languages. It's mostly a library thing though, and the price in testing effort and bugs is steep.

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

#669

Post by kcartlidge »

LoveMortuus wrote: post #202
kossTKR wrote: post #132

Earlier quoted context omitted.

I hope one day latency in general will be "back to normal". I still remember how fast console based computing, an old gameboy or a 90's macintosh would be - click a button and stuff would show up instantly. There was a tactility present with computers that's gone today. Today everything feels sluggish - just writing this comment on my $3000 Macbook Pro and i can feel the latency, sometimes there's even small pauses.…

May I ask if you're using the M1 based MacBook or the Intel one? I'm asking because I've been thinking of getting a MacBook Air in the future with the intent to use it for writing.

I'm on an M1 Air (cheapest base model), and I use it largely for writing (also dev but I get that that's not your question).

- For native M1 apps like Pages, Sublime, or Highland there's no lag at all. For example, with Highland 2 from double-clicking a file to editing it is less than a second and there's no lag during use even with a 49,000 word book manuscript open.

- For x86 apps like the not-quite-latest Office there's a couple of seconds at first launch (for that session) whilst Rosetta does its x86 translation work, but after that it launches without lag for the remainder of that session and it stays snappy in use (snappy for Word that is).

- Native VS Code goes from launch to editing in under two seconds and never lags, even with something like side-by-side Markdown preview going.

- If you're using Vellum for publishing it's about 1.5 seconds from double-clicking a file to editing it.

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

#670

Post by knorker »

loup-vaillant wrote: post #636
knorker wrote: post #475

Earlier quoted context omitted.

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…

> Like I said, the vast majority of code optimization opportunities are not worth taking. Some are, but only after running the numbers. Casey Muratori said it best: there are 3 philosophies of optimisation. You're talking about the first: actual optimisation where you measure and decide what to tackle. It's rarely used, and with good reason. The second philosophy however is very different: it's non-pessimisation . Th…

I'm actually also talking about the second.

> avoid having the CPU do useless work all the time

It's not worth an engineer spending 1h a year even investigating this, if it's less than 20 CPU cores doing useless work.

The break even for putting someone full time on this is if you can expect them to save about fourty thousand CPU cores.

YMMV. Maybe you're a bank who has to have everything under physical control, and you are out of DC floor space, power budget, or physical machines.

There are other cases too. Maybe something is inherently serial, and the freshness of a pipeline's output has business value. (e.g. weather predictions for tomorrow are useless the day after tomorrow)

But if you're saying that this second way of optimizing is that things should be fast for its own sake, then you are not adding maximum value to the business, or the mission.

Performance is an instrumental goal of an effort. It's not the ultimate goal, and should not be confused for it.

Post reply on HN