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

271–280 of 819 posts

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

#271

Post by radicalbyte »

dataflow wrote: post #143
radicalbyte wrote: post #124

Earlier quoted context omitted.

If you're using an IDE (Rider or Visual Studio) and avoid the Enterprise frameworks, then it's much easier to use than Python. Tooling makes a huge difference, no more digging through the sometimes flakey Python documentation and cursing compatibility issues with random dependencies not supporting Apple Silicon.

I agree tooling makes a huge difference but I specifically said this with the understanding that you're using C# with Visual Studio. Some stuff will be easier in C#, but a lot of other stuff just isn't as easy as in Python. At the risk of setting up a strawman for people to punch down, try comparing how easy it is to do the equivalent of something like this in C#, and feel free to use as much IDE magic as you'd like:…

There's very little difference between the two as long as you're using modern versions of both and add your own functions to fill any API gaps and are using type hinting properly in Python. My C# tends to be "larger" because I use more vertical whitespace and pylint is rather opinionated.. :)

Where you can complain about C# - and I do - is where you're having to write (or work with) code which has been force to stick to strict architectural and style standards. That makes code-bases which are very hard to understand for newbies and are verbose.

On the flip side, once you start doing anything even slightly interesting with Python you run into the crappy package management. The end result of which is lots of frustration getting projects working and a lot of time wasted on administration vs work.

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

#272

Post by V1ndaar »

mrtranscendence wrote: post #42
jerf wrote: post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

> And in the end, the code seems to run "fast enough" and nobody involved really notices that what is running in 750ms really ought to run in something more like 200us. Nobody has created a language that is both thousands of times faster than Python and nearly as straightforward to learn and to use. The closest thing I know of might be Julia, but that has its own performance problems and is tied closely to its AI/ML…

I don't know, but imo Nim begs to differ.

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

#273

Post by jiggawatts »

moonchild wrote: post #138
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…

> The latency on multiplication (register input to register output) is 5-clock ticks 3 https://www.agner.org/optimize/instruction_tables.pdf

Back in the days, an integer division took something like 46 clocks (original Pentium), and now on Ice Lake it's just 12 with a reciprocal throughput of 6. Multiply that by the clock speed increase and a modern CPU can "do division" about 300-400 times faster than a Pentium could. Then multiply that by the number of cores available now versus just one core, and that increases to about 2000 times faster!

I used to play 3D games on Pentium-based machines and I thought of them as a "huge upgrade" from 486, which in turn were a huge upgrade from 286, etc...

Now, people with Ice Lake CPUs in their laptops and servers complain that things are slow.

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

#275

Post by egypturnash »

contravariant wrote: post #268
porcoda wrote: post #11

Yup. We have gotten into the habit of leaving a lot of potential performance on the floor in the interest of productivity/accessibility. What always amazes me is when I have to work with a person who only speaks Python or only speaks JS and is completely unaware of the actual performance potential of a system. I think a lot of people just accept the performance they get as normal even if they are doing things that ta…

While I would certainly welcome awareness when it comes to performance it's not always useful to make something 1000x faster if it takes even as little as 25% longer to develop. Taking an extra day to make something take 1s instead of an hour is just not always worth it. Though I will never understand webpages that use more code than you'd reasonably need to implement a performant lisp compiler and build the webpage…

It depends on how often you need to do the thing and how long it takes to do it. There’s an XKCD that’s just a chart of that.

Sadly any concept of performance seems to completely go out the window for most programmers once it leaves their hands; taking 2-3x longer to write a performant app in a compiled language would save a ton of time and cycles on users’ machines but Programmer Time Is Expensive, let’s just shit out an Electron app, who cares that it’s five orders of magnitude larger and slower.

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

#276

Post by 1vuio0pswjnm7 »

jerf wrote: post #6

I've been lightly banging the drum the last few years that a lot of programmers don't seem to understand how fast computers are, and often ship code that is just miserably slower than it needs to be, like the code in this article, because they simply don't realize that their code ought to be much, much faster. There's still a lot of very early-2000s ideas of how fast computers are floating around. I've wondered how m…

"I have a hard time using (pure) Python anymore for any task that speed is even remotely a consideration anymore. Not only is it slow even at the best of times, but so many of its features beg you to slow down even more without thinking about it."

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

#277

Post by staticassertion »

zozbot234 wrote: post #199
staticassertion wrote: post #193

Earlier quoted context omitted.

Unqualified "fast enough" is pretty much exactly the problem being pointed out. Most developers have no idea what "fast" is let alone "fast enough". If they were taught to benchmark at with a lower level language, see what adding different abstractions causes, that would help a ton. I would personally suggest C++ though because there is such a huge amount of knowledge around performance and abstraction in that commun…

It's not an "unqualified" claim, Go really is fast enough compared to the likes of Python and Ruby. I'm not saying that rewriting a Go program in a faster language (C/C++/Rust) can't sometimes be effective, but that's due to special circumstances - it's not something that generalizes to any and all programs.

"Fast enough" is inherently unqualified since what "enough" is is going to be case specific.

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

#278

Post by 369548684892826 »

Jtsummers wrote: post #219
eterm wrote: post #165

Earlier quoted context omitted.

Here's a one liner in c# for that: Enumerable.Range(1,50).Where((x,i) => i % 4 == 0).Where(e => e % 3 == 0).Skip(1).Select(e => e+4) Okay, so you might consider that last e+4 cheating and against the spirit, but I couldn't be bothered to spend money upgrading my linqpad to support the latest .net with Enumerable.Chunk which makes taking two at a time easier for the first part. Edit: more in spirit: Enumerable.Range(1…

If I understand dataflow's example correctly you don't need the Select at the end: var x = Enumerable.Range(1,50) .Where((num, index) => num % 4 == 1 && index % 3 == 0) .Skip(2) .ToArray(); That computes the same thing as their Python snippet: [25,37,49]. Of course, what this is actually computing is whether the number is congruent to 1 modulo 4 and 3 so it was a weird example, but here's how you'd really want to wri…

> LINQ, to generate only every 4th number in a range

Maybe something like this?

    Enumerable.Range(0,49).Select(x => 4*x + 1)

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

#279

Post by twobitshifter »

spatley wrote: post #63
porcoda wrote: post #11

Yup. We have gotten into the habit of leaving a lot of potential performance on the floor in the interest of productivity/accessibility. What always amazes me is when I have to work with a person who only speaks Python or only speaks JS and is completely unaware of the actual performance potential of a system. I think a lot of people just accept the performance they get as normal even if they are doing things that ta…

Agreed that switching to lower level languages give the potential of many orders of magnitude. But the thing that was most enlightening was that removing pandas made a 9900% increase in speed without even a change to language. 20 minutes down to 12 seconds is a very big deal, and I still don't have to remember how to manage pointers.

I think that should be emphasized. The rest of the optimizations are entirely unneeded and added complexity to the code base. The next guy to work on this needs to be a cpp dev, but the requirements were only asking for 500ms which was more than met by the first fix. What the payoff of this added performance with and at what cost?

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

#280

Post by rot13xor »

bayindirh wrote: post #170
bb88 wrote: post #158

Earlier quoted context omitted.

Java and Go were both responses to how terrible C++ actually is. While there are footguns in python, java, and go, there are exponentially more in C++.

As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C…

The biggest weakness of C++ (and C) is non-localized behavior of bugs due to undefined behavior. Once you have undefined behavior, you can no longer reason about your program in a logically consistent way. A language like Python or Java has no undefined behavior so for example if you have an integer overflow, you can debug knowing that only data touched by that integer overflow is affected by the bug whereas in C++ your entire program is now potentially meaningless.
Post reply on HN