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

731–740 of 819 posts

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

#731

Post by kaba0 »

acoard wrote: post #661
m1el wrote: post #538

Earlier quoted context omitted.

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…

I would say that the tool should reason about it at compile time, a la SolidJS.

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

#732

Post by paskozdilar »

morelisp wrote: post #710
paskozdilar wrote: post #683

Earlier quoted context omitted.

While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well. The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.

The ability of read/write to communicate via errors as well as the actual data transferred is significant - there's a reason Go's i/o model is io.Reader/io.Writer and not chan []byte. You might as well explain channels in terms of any blocking operation if the bar for "isomorphic" (now backtracked to "intuitively" I guess) is that low.

I don't know what's the bar for "isomorphism", but I know that the word literally means "same shape", so just because some nerd that got killed in a duel over a girl used the same word in a mathematical context doesn't give him dibs over its general use.

Unless, of course, system calls can be modeled as operators over sets. In which case, please tell me how.

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

#733

Post by kaba0 »

jcranmer wrote: post #300
_gabe_ wrote: post #243

Earlier quoted context omitted.

> secure C code. There is unsecure code hidden in every project that uses any programming language ;) I get what you're saying here, you're specifically talking about security vulnerabilities from memory related errors. I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in…

> I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in a different manner. Memory safety vulnerabilities basically boil down to following causes: null pointer dereferences, use-after-free (/dangling stack pointers), uninitialized memory, array out-of-bounds, and type conf…

It depends on what you mean by mitigated. Java mitigates null pointers by deterministically raising an exception (as well as out of range situations), but indeed it doesn’t handle them at compile time (though the latter can’t even be solved in the general case, and only with dependent types)

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

#734

Post by kaba0 »

saagarjha wrote: post #260
slotrans wrote: post #252

Earlier quoted context omitted.

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.

Any idea what it’s doing during those several seconds?

It’s just a too long animation.

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

#735

Post by jcelerier »

throwaway894345 wrote: post #720
gpderetta wrote: post #667

Earlier quoted context omitted.

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?

You need to provide all of the libraries referenced by the core dump (at the specific versions and compiled with debug symbols) to get gdb to produce a useful backtrace. It's been a decade since I've done professional C++ development, so I'm a bit foggy on the particulars.

we're in 2022, gdb asks me "can i download missing symbols from the internet" when it loads a binary and does it

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

#736

Post by Tostino »

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

Yes, it is.

While I agree that databases could absolutely be improved to make streaming query results as described better, that isn't a limiting factor here IMO. I'd tackle that problem by batching my queries to the database into some logical batch size and send them as table valued parameters. If I had 10k phone numbers to check and minimum latency matters, why not batch into queries of 500-1000 values per-query? That cuts down time to first response, while reducing the network roundtrips.

The issue with taking this out of the database, is you lose consistency. I don't know about your industry, but I don't think mine would be terribly happy if I was using stale data to validate my Do Not Call/Email list. Now there are some situations where you can just update your list of numbers nightly/weekly/monthly, etc. If you don't need any concurrency or other guarentees, might as well save the time/resources on your DB server.

That's just not the world I have worked in.

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

#737

Post by blub »

charlie0 wrote: post #712
blub wrote: post #524

Earlier quoted context omitted.

Performance is something that needs to be considered throughout the development cycle. If optimization happens at the end then it’s either a rewrite or a minor concern anyway because the building blocks like frameworks and libraries were already optimized. Or the software is just slow but still sells for other reasons.

Totally depends in the business. Most businesses just don't need ultra low ms response times. Rewriting an app because is too slow is a rather extreme approach. Most of the times it's just a small part of the application that needs optimization and not the entire app. I'd argue that if the app experiences huge growth, then that's a good problem to have and a rewrite is in order.

This is not about ultra-low responses or anything. Performance is just as much part of an application’s architecture as security or usability are. You can’t add those things at the end, they need to be done iteratively.

So when you say you optimize at the end as needed, you get away with that because somebody already did that job for you.

A) The frameworks and libs are heavily optimized, so that developers deploying them will get the best possible performance just by idiomatic usage and connecting those libraries together.

+

B) The software itself is not technically challenging.

When A and B don’t hold, ignoring performance will get the project in big trouble.

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

#738

Post by Tostino »

treeman79 wrote: post #671
jiggawatts wrote: post #397

Earlier quoted context omitted.

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.

Yes, that is a good explainer on the horrors of single value lookups to a database. It isn't the only way to do that though, as explained in my other post.

I absolutely agree that a DB (even an extremely efficient one) is going to use many more clock cycles to return results there than a local data structure + application. No questions asked.

But how is that list kept up to date? If a user wants to be placed on the list, do you do that in real time to your local data structure? Do you wait for a batch process to sync that data structure with your source of truth?

I'm just saying that a simple program like that will be faster because it lacks a lot of the features that people would consider necessary in today's world.

The database is an amazing general tool that can be used to tackle whole classes of problems that used to require specialized solutions.

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

#739

Post by LoveMortuus »

kcartlidge wrote: post #669
LoveMortuus wrote: post #202

Earlier quoted context omitted.

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

That's very good to hear, I've been looking at MacBook Air also because they're pretty much the kings when it comes to battery life for a handbag sized laptop. I think the bidder MacBooks have slightly better battery, but you can't really fit those in a smaller bag, you do kinda need a backpack for it or a laptop specific bag.

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

#740

Post by djmips »

Bingo. It's not that software engineers are stupid, it's that they don't 'see' when they do something stupid and don't have a good mental model because of that lack of sight. Everyone figures out quickly to efficiently clean out their garage or other repetitive chores because it's personally painful to do it poorly and it's right in front of your nose. If only computers were more transparent and/or people learned and used profilers daily...
Post reply on HN