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

621–630 of 819 posts

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

#621

Post by sgillen »

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…

Ironically as a Phd in an ECE department, almost everyone has heard of and uses numpy, but many people have never even heard of pandas!

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

#622

Post by swiftcoder »

skohan wrote: post #497
flohofwoe wrote: post #485

Earlier quoted context omitted.

It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…

Doesn't Rust mostly abstract the memory management away as well? It tends to be low overhead, and has sensible defaults with respect to memory management, but it's built around RAII and for instance if you use a lot of reference types as far as I know there's nothing keeping you from having fragmented memory the same way you would with another high level language. I know Rust also offers arenas and other purpose buil…

One of the big differences memory-wise between the C/C++/Rust family and the Javas of the world is having first class support for by-value object types (and collections thereof).

Yes, you can trash your cache in all these languages if you choose to do everything with references to a multitude of individual heap allocations... but in Java-likes you don't have the choice not to do that

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

#623

Post by swyx »

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…

blaming popular webapps being sluggish after spending a whole paragraph on Redux is a bit of a non sequitur imo. performance issues are multicausal, i hope you can separate criticism of one library from emergent properties of complete products

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

#624

Post by jazzyjackson »

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…

I've started using micropython to interact with embedded arm chips, it's a revelation to interact with hardware through a REPL instead of compiling, transferring, resetting, and writing print statements to serial...

This talk by the creator of micropython [0] gives his reasoning for why to implement python on microcontrollers despite it being hundreds of times slower than C. Starts @ 3:00

- it has nice features like list comprehension, generators, and good exception handling

- it has a big, friendly, helpful community with lots of online learning resources

- it has a shallow but long learning curve. It's easy to get started as a beginner, but you never get bored of the language, there's always more advanced features to learn.

- it has native bitwise operations

- has good distinction between ints and floats, and floats are arbitrary precision, you're not restricted to doubles or even long longs. (I'll add that built in complex numbers is a plus)

- compiled language, so it can be optimized to improve performance

[0] https://www.youtube.com/watch?v=EvGhPmPPzko

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

#626

Post by doctor_eval »

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…

Although I 100% agree with you, the problem is that these costs don't affect the original developer; it is an externality; a lot like carbon pollution. It's cheaper for the organisation to optimise for developer speed, even if the cost of that is borne by all the users.

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

#627

Post by pdimitar »

jazzyjackson wrote: post #624
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…

I've started using micropython to interact with embedded arm chips, it's a revelation to interact with hardware through a REPL instead of compiling, transferring, resetting, and writing print statements to serial... This talk by the creator of micropython [0] gives his reasoning for why to implement python on microcontrollers despite it being hundreds of times slower than C. Starts @ 3:00 - it has nice features like…

Ha, that actually looks pretty cool and good tech. I'd wonder if that can even be called Python anymore but still, it looks to be very useful. Thanks for the tidbit!

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

#628

Post by hoseja »

Gigachad wrote: post #507
justsomeuser wrote: post #501

I imagine for most web dev’s using a fast memory unsafe language is like taking a bullet train to the local shop to get milk.

It also doesn’t stop when you reach your destination so you have to jump and roll out. Get it wrong and you die. Questioning this method is widely frowned on.

The alternative is crawling around with your tongue and circling the shop hundred times before coming in. So intuitive!

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

#629

Post by gilbetron »

gpm wrote: post #359
gilbetron wrote: post #355

Earlier quoted context omitted.

Aren't the fast parts of numpy written in C?

And fortran. Which really doesn't matter that much as long as that doesn't leak to the users of numpy, and it doesn't really. The only issue is that it means if you're doing something that doesn't fit the APIs exposed by the native code (in a way where the hot loops are in native code) it's roughly as slow as normal python.

But it does for the argument of a language being fast, which is what we are talking about here. I don't think it is an appropriate argument to say "Python is fast, look at numpy", when the core pieces are written in C/Fortran. It is disingenuous, at least to me.

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

#630

Post by doctor_eval »

chowells wrote: post #430
LoveMortuus wrote: post #187

Earlier quoted context omitted.

I personally find C++ more friendly, just because of the formatting that python forces upon you. But I do have to say that I never managed to really get into python, it always just felt like to much of a hassle, thus I always avoided it if possible.

The formatting python enforces is just "layout reflects control flow". It's really not any more difficult than that, and it's a lot better than allowing layout to lie about control flow. https://www.synopsys.com/blogs/software-security/understandi...

To each their own, but Python's use of indenting for structure is why I never tried it. It just felt, to me, like it was solving one problem with another.

I think Go gets this right: it consistently uses braces for structure, but has an idiomatic reformatting tool that is applied automatically by most IDEs. This ensures that the format and indentation always perfectly matches the code structure, without needing to use invisible characters.

Post reply on HN