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

231–240 of 819 posts

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

#231

Post by shadowofneptune »

staticassertion wrote: post #193
zozbot234 wrote: post #136

Earlier quoted context omitted.

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.

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…

Go comes from a different school of compiler design where the code generation is decent in most cases, but struggles with calculations and more specific patterns. Delphi is a similar compiler. Looking at benchmarks, the performance is only a few times worse than optimized C. That's on par with the most optimized JITed languages like Java, while being overall a much simpler compiler. I feel it is is fair to say 'good enough' in this situation.

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

#232

Post by skybrian »

zozbot234 wrote: post #192
skybrian wrote: post #178

Earlier quoted context omitted.

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.

> I mean, he just explained that after rewriting his program in Dart, it was fast enough? Yes, and that makes his C advocacy even less sensible. Dart is a perfectly fine language, even though it seems to be a bit underused compared to others.

Spending "a little time writing some programs in C" is not the same as advocating that people write most of their code in C, or that you use it in production.

Maybe try reading Crafting Interpreters, half of which is in Java and half in C.

http://craftinginterpreters.com/

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

#233

Post by spc476 »

tester756 wrote: post #93
jcelerier wrote: post #73

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. Conversely when 99.9% of the software you use in your daily life is blazing fast C / C++, having to do anything in other stacks is a complete exer…

Is performance inversely proportional to dev experience? because what you wrote could be said about using C++ in the context of dev experience 10 compilers, IDEs, debuggers, package managers and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware I don't believe that this is the best we can get.

TCC is a fast compiler. So fast, that at one time, one could use it to boot Linux from source code! But there's a downside: the code is produces is slow. There's no optimization done. None. So the trade off seems to be: compile fast but slow program, or compile slow but fast program.

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

#234

Post by xcdzvyn »

tomrod wrote: post #221
vlovich123 wrote: post #207

> extra_compile_args = ["-O3", "-ffast-math", "-march=native", "-fopenmp" ], > Some say -O3 flag is dangerous but that's how we roll No. O3 is fine. -ffast-math is dangerous.

Why?

It reorders instructions in ways that are mathematically but not computationally equivalent (as is the nature of FP). This also breaks IEEE compliance.

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

#235

Post by aeonik »

edbaskerville wrote: post #121
generalizations wrote: post #108

Earlier quoted context omitted.

I ran across an animation once that showed graphically the time it takes light to travel between the planets and the sun. It's weird, but light doesn't seem that fast anymore.

The thing that did for me is realizing that people on opposite sides of the United States can't play music together if it requires any rhythmic coordination, even with a true speed-of-light signal with no other sources of latency.

jamtaba and ninjam are an open source solutions to this problem.

They allow you to buffer everyone's playing, at a user specified interval, then replays the last measure of music to everyone.

It's definitely not the same as live playing, but it's still pretty fun, and actually forces you to get creative on different ways.

https://jamtaba-music-web-site.appspot.com/

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

#236

Post by [deleted] »

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…

[deleted]

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

#237

Post by eterm »

dataflow wrote: post #215
eterm wrote: post #211

Earlier quoted context omitted.

The ToArray is unneccessay, it's much more idiomatic dotnet to deal with IEnumerable all the way through. The only meaningful difference in lengths is that C# doesn't have an Enumable.Range(start, stop, increment) overload but it's easy enough to write one, and then it'd be essentially the same length.

"Unnecessary"? You can't just change the problem! I was asking for the equivalent of some particular piece of code using a list, not a different one using a generator. Sometimes you want a generator, sometimes you want an array. In either language.

This is a silly argument, you're asking for a literal translation of a pythonic problem without allowing the idioms from the other languages.

If you were actually trying to solve the problem in dotnet, you'd almost certainly structure it as the Queryable result and then at the very end after composing run ToList, or ToArray or consume in something else that will enumerate it.

We can also shorten it further to:

    Enumerable.Range(1, 50)
        .Where(e => e % 12 == 1)
        .Skip(2)
        .ToList()
Now even including the ToList it's now just four basic steps:

Range, Filter, Skip, Enumerate.

Those are the very basics, all one line if wanted. It doesn't get much more basic than that, and I'd still argue it's easier for someone new to programming to see what's going on in the C# than the python example.

edit: realised the maths simplifies it even further.

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

#238

Post by ineedasername »

reedjosh wrote: post #205

Python and Pandas are absolutely excellent until you notice you need performance. I say write everything in Python with Pandas until you notice something take 20 seconds. Then rewrite it with a more performant language or cython hooks. Developing features quickly is greatly aided by nice tools like Python and Pandas. And these tools make it easy to drop into something better when needed. Eat your cake and have it too…

Yes, there have been times that I have called linux command line utilities from python to process something rather do it in python.

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

#239

Post by TheRealPomax »

tomrod wrote: post #221
vlovich123 wrote: post #207

> extra_compile_args = ["-O3", "-ffast-math", "-march=native", "-fopenmp" ], > Some say -O3 flag is dangerous but that's how we roll No. O3 is fine. -ffast-math is dangerous.

Why?

Some really good reasons: https://stackoverflow.com/a/22135559/740553

It basically assumes all maths is finite and defined, then ignores how floating point arithmetic actually works, optimizing based purely on "what the operations suggest should work if we wrote them on paper" (alongside using approximations of certain functions that are super fast, while also being guaranteed inaccurate)

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

#240

Post by dmitriid »

dataflow wrote: post #225
dmitriid wrote: post #220

Earlier quoted context omitted.

What you're missing is that C# example works on any Enumerable . And it's very hard to explain how damn important and impressive this is without trying it first. Yes, it's more verbose, but I can swap that initial array for a List, or a collection, or even an external async datasource, and my code will not change. It will be the same Select.Where....

> What you're missing I'm not missing it. > is that C# example works on any Enumerable. And it's very hard to explain how damn important and impressive this is without trying it first. Believe me I've tried (by which I mean used it a ton). I'm not a newbie to this. C# is great. Nobody was saying it's unimportant or unimpressive or whatever. > Yes, it's more verbose, but I can swap that initial array for a List, or a…

> Excellent. And when you want that flexibility, the verbosity pays off. When you don't, it doesn't. Simple as that.

It's rarely as simple as that. For example, this entire conversation started with "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".

And this became a discussion of straw men :) Because I could just as easily come up with "replace a range of numbers with data that is read from a database or from async function that then goes through the same transformations", and the result might not be in Python's favor.

Post reply on HN