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

681–690 of 819 posts

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

#681

Post by dr_zoidberg »

xaedes wrote: post #559
korla wrote: post #517

Earlier quoted context omitted.

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.

> I think developer speed is more important than optimising clock cycles unnecessarily. Developer time is spent once. Users will always have to pay the price of additional run time. For. Each. Single. User. Always. It scales! Due to the scale of, e.g. slow front-ends, with millions of users, this takes a HUGE amount of time. Only to save a few hours or days to develop it better. Having 1 million users each wait a sin…

> Having 1 million users each wait a single second is already 11 days.

This will sound like a nitpick, but it's actually worse. 1 million users waiting a single second is 11,000,000 seconds, right? A day has 86,400 seconds. 11 million divided by 86k is 127.31.

That means million users combined just spent 127 days and 8 hours because of the "just one second" delay.

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

#682

Post by corrral »

knorker wrote: post #54
marcosdumay wrote: post #19

Earlier quoted context omitted.

It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.

Not that it invalidates anything you said, but it was 750ms vs 200 microseconds. But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all? And that's not even mentioning the RAM elephant in the room: chrome. Younglings today don't understand what a mindbogglingly large amount of data a GB is. But here's the thing: it's cheaper to waste thousands of CPU cores on…

We shouldn't let people obtain CS degrees until they've had to write at least one fairly-complex program on a platform with little enough RAM that the amount of code in the program starts to be something they have to optimize (because the program itself takes up space in memory, not just the data it uses, which is something we hopefully all know but rarely think about in practice on modern machines). Tens or low hundreds of KB of memory. Get 'em questioning every instruction and every memory allocation.

I'm only half-joking.

[EDIT] For extra lulz let them use a language with a bunch of fancy modern language features so they get a taste of what those cost, when they realize they can't afford to use some of them.

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

#683

Post by paskozdilar »

morelisp wrote: post #679
bheadmaster wrote: post #551

Earlier quoted context omitted.

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

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.

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

#684

Post by pkolaczk »

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…

The number of ways to write something is only very loosely correlated with maintainability. The ease of maintenance is IMHO more a function of how much information about the properties of the code you can easily read from the text, and how well the abstractions in the code map to the abstractions you'd use when describing the solution to a friend. Lack of features doesn't help in that regard. That's why probably Go has just added generics, despite the long tradition of Go promoters claiming "lack of generics is a good thing" ;)

Languages with very little type information, e.g. dynamic ones, tend to be quite hard to maintain, unless the original developers kept the discipline of good naming and verbose commenting. Go and Java with their somewhat static, but limited typing and elements of dynamism (interface{}, Object, reflection), sit somewhere in the middle between PHP/JS and Rust/Scala/Haskell.

Languages with little expressive / abstraction power, so the ones limited in features or low-level are also often hard to maintain, because you have to reverse-engineer the high-level stuff from all the details you see. Take assembly as an example - while it may be quite obvious what the program is doing at the bits and bytes level, understanding the sense of that bit-level manipulation may be a much harder task. The assembly language might actually be very simple, but that does not help. I remember when we had a MIPS class, the whole specs was just a few pages, could be learned in an hour.

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

#685

Post by kortex »

tpoacher wrote: post #609

The point about pandas resonates with me. Don't get me wrong, pandas is a nice library ... but the odd thing is, numpy already has, like, 99% of that functionality built in in the form of structured arrays and records, is super-optimised under the hood, and it's just that nobody uses it or knows anything about it. Most people will have never heard of it. To me pandas seems to be the sort of library that because popul…

> numpy already has, like, 99% of that functionality built in in the form of structured arrays and records

Respectfully, this is pretty wrong. Pandas does vastly more out of the box than numpy. Off the top of my head: I/O from over a dozen of data formats, joins/merges, sql queries directly to dataframes, sql-like queries on dataframes, index slicing by time, multi-indexes, much more ergonomic grouping/aggregation functions, ergonomic wrappers around common graphing use-cases, rolling windows.

I'm not even really a power user of it, so there's probably a zillion more things it does that numpy can't out of the box, and I don't wanna spend time writing time and validating if an implementation exists.

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

#686

Post by dr_zoidberg »

Dylan16807 wrote: post #456
babypuncher wrote: post #111

Earlier quoted context omitted.

Throw in more RAM and Windows 10 will likely feel snappier than Windows 7 did. It's probable the old Windows 7 install was 32-bit while your fresh install of 10 would have defaulted to 64-bit. That combined with 10's naturally higher memory requirements means the system has less overhead to work with.

If it was 32-bit, then it's probable the windows 7 install wasn't using all the memory, so there shouldn't have been a big difference. And 4GB is enough for a blank windows 10 install doing some OS things and browsing. I don't think more memory helps that scenario.

32bit PAE was supported since Windows XP and initially allowed for more than 4GB of RAM to be supported, but driver issues made Microsoft put a soft-cap in 4GB under this mode[0]. But Win7 32 bits with PAE would've surely been able to use all of those 4GB fine.

[0] https://en.wikipedia.org/wiki/Physical_Address_Extension#Mic...

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

#687

Post by wbsss4412 »

pjvsvsrtrxc wrote: post #331
wbsss4412 wrote: post #313

Earlier quoted context omitted.

Nitpick: software optimization isn’t an example of an externality. Externalities are costs/benefits that accrue to parties not involved in a transaction.

Yes, it is. > ex·ter·nal·i·ty: a side effect or consequence of an industrial or commercial activity that affects other parties without this being reflected in the cost of the goods or services involved The buyer is an "other part[y]" from the seller's (edit: or better yet, developer, who might just be contracted by the ultimate seller...) perspective, and performance is basically impossible to quantify, therefore pri…

That’s an incredible stretch of the definition.

The other parties are other parties besides the buyer and seller.

> Moreover, even if you want to limit externalities to being completely third-party... sure: Pollution. More electrical generation capacity needed.

^this is an externality, everything else is just a poor understanding of the concept.

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

#688

Post by wbsss4412 »

pjvsvsrtrxc wrote: post #356
xupybd wrote: post #349

Earlier quoted context omitted.

So would a less efficient engine in a car be an externality?

The pollution from such a car is undeniably an externality. Just Google "is pollution an externality". The less efficient engine itself is not because it is priced in. Because the government made them put it on the window of every single car sold.

“Priced in” means that the full social cost is reflected in the price.

A window sticker is not “pricing in” the externality.

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

#689

Post by wbsss4412 »

xupybd wrote: post #349
pjvsvsrtrxc wrote: post #331

Earlier quoted context omitted.

Yes, it is. > ex·ter·nal·i·ty: a side effect or consequence of an industrial or commercial activity that affects other parties without this being reflected in the cost of the goods or services involved The buyer is an "other part[y]" from the seller's (edit: or better yet, developer, who might just be contracted by the ultimate seller...) perspective, and performance is basically impossible to quantify, therefore pri…

So would a less efficient engine in a car be an externality?

Pollution is the externality.

A less efficient car engine means that the magnitude of the externality (in this case, the externalized cost, you can have externalized benefits as well) is larger.

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

#690

Post by pdimitar »

BeFlatXIII wrote: post #675
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.

If that's a blocker to productivity to anyone I'd seriously argue their programming prowess. Especially nowadays with LSP auto-formatting, snippet management, and such.

Syntax is a subjective preference. I didn't like that fact for the longest time but it's a fact regardless.

Post reply on HN