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

171–180 of 819 posts

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

#171

Post by geysersam »

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…

More important than the language, is using the right tool for the job. If you are using the scientific Python stack, correctly, you'll have a difficult time beating that with c++. For many applications. While producing way simpler and more maintainable code.

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

#172

Post by latenightcoding »

munificent wrote: post #68
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 agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

off topic but I initially didn't notice your username but the second I read "I wrote my own template language in Dart" I knew who it was.

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

#173

Post by throwaway894345 »

bayindirh wrote: post #113
p1esk wrote: post #81

Earlier quoted context omitted.

Conversely when 99.9% of the software you use in your daily life is user friendly Python, having to do anything in C/C++ is a complete exercise in frustration, it feels like going back a few decades in time

As a person who uses both languages for various needs, I disagree. Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I implement in C++. Lastly, people think C++ is not user friendly. No, it certainly is. It needs being careful, yes, but a lot of things can be done in less lines then people expect.

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

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

#174

Post by dekhn »

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 don't really find python slow for what I do (typically writing UIs around computer vision systems) but also, several years back I made a microcontroller-based self-balancing robot. It was hard to debug the PID and the sensor, so I replaced it with a Pi Zero and the main robot loop ran in python- enough to read the accelerometer, compute a PID update, and send motor instructions- 100 times a second. If there was a problem (say, another heavy process, like computer vision, running on the single CPU) it would eventually not respond fast enough and the robot would fall over.

Most of the time it's not that you need a faster language, it's that you need to write faster code. I was working on a problem recently where random.choices was slow but I realized that due to the structure of my problem I could convert it to numpy and get a 100X speedup.

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

#175

Post by dataflow »

eterm wrote: post #165
dataflow wrote: post #143

Earlier quoted context omitted.

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

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…

Nah that part I'm not worried about. The "cheating" is omitting the rest of the line. What you really needed was:

  var y = Enumerable.Range(1, 50).Where((x, i) => i % 4 == 0).Where(e => e % 3 == 0).Skip(1).Select(e => e + 4).ToArray();
Compare that against:

  y = [t[1] for t in enumerate(range(1, 50, 4)) if t[0] % 3 == 0][2:]
It's almost twice as long, and doesn't exactly make up for it with readability either.

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

#176

Post by throwaway894345 »

bb88 wrote: post #158
bayindirh wrote: post #113

Earlier quoted context omitted.

As a person who uses both languages for various needs, I disagree. Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I implement in C++. Lastly, people think C++ is not user friendly. No, it certainly is. It needs being careful, yes, but a lot of things can be done in less lines then people expect.

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

I've written a whole bunch of all of those languages, and they each occupy a different order of magnitude of footguns. From fewest to most: Go (1X), Java (10X), Python (100X), and C++ (1000X).

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

#177

Post by 41b696ef1113 »

tiffanyh wrote: post #23

NIM NIM should be part of the conversation. Typically, people trade slower compute time for faster development time. With NIM, you don’t need to make that trade-off. It allows you to develop in a high-level but get C like performance. I’m surprise its not more widely used.

>I’m surprise its not more widely used.

It's a ~community language without the backing of an 800lb gorilla to offer up both financial and cheerleading support.

I love the idea of Nim, but it is in a real chicken-and-egg problem where it is hard for me to dedicate time to a language I fear will never reach a critical mass.

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

#178

Post by skybrian »

zozbot234 wrote: post #136
munificent wrote: post #68

Earlier quoted context omitted.

I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

Please don't write programs in bare C. Use Go if you're looking for something very simple and fast-enough for most uses; it's even memory safe as long as you avoid shared-state concurrency.

I mean, he just explained that after rewriting his program in Dart, it was fast enough? That's not really the point here.

On the other hand, I tried writing a Wren interpreter in Go and it was considerably slower than the C version. Even programming languages that are usually pretty fast aren't always fast, and interpreter inner loops are a weak spot for Go.

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

#179

Post by bb88 »

KronisLV wrote: post #164
michaelsshaw wrote: post #156

Earlier quoted context omitted.

Nothing wrong with any of these languages, especially C. It's been around since the early 70s and is not going anywhere. There's a very good reason it (and to an extent C++) is still is the default language for doing a lot of things since everyone understands it.

C and C++ both have excellent library support, perhaps the best interop of any language out there and platform support that cannot be beat. That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Thus, unless you have a good reason (of which, admittedly, there are plenty) to use C or C++, somet…

> perhaps the best interop of any language out there and platform support that cannot be beat.

Disagree here. The C++ ABI has pretty much been terrible for the last 20 years.

C is fine in this regard though.

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

#180

Post by eterm »

dataflow wrote: post #175
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…

Nah that part I'm not worried about. The "cheating" is omitting the rest of the line. What you really needed was: var y = Enumerable.Range(1, 50).Where((x, i) => i % 4 == 0).Where(e => e % 3 == 0).Skip(1).Select(e => e + 4).ToArray(); Compare that against: y = [t[1] for t in enumerate(range(1, 50, 4)) if t[0] % 3 == 0][2:] It's almost twice as long, and doesn't exactly make up for it with readability either.

It's not "twice as long" in any syntactic sense, and readability is easily fixed:

    Enumerable.Range(1,50)
        .Where(e => e % 4 == 0 && e % 3 == 0)
        .Skip(1)
        .Select(e => e + 1)
That's very understandable, it's clear what it does, and if your complaint is that dotnet prefers to name expressions like Skip rather than magic syntax, we can disagree on what make things readable and easy to maintain.
Post reply on HN