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

261–270 of 819 posts

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

#261

Post by hashingroll »

david38 wrote: post #33
user_7832 wrote: post #15

I wonder how much power (and resulting CO2 emissions) could be saved if all code had to go through such optimization. And on a slightly ranty note, Apple's A12z and A14 are still apparently "too weak" to run multiple windows simultaneously :)

Worse CO2 emissions. You think optimizations are energy free?

Not all optimizations are more energy consuming. For an analogy, does a using a car consume more energy than a bicycle? Yes. But a using a bicycle does not consume more energy than a man running on feet.

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

#262

Post by pelorat »

dataflow wrote: post #97
Gibbon1 wrote: post #74

Earlier quoted context omitted.

C# is faster than python and as easy to use.

As nice as it is, C# is definitely not as easy to use as Python.

But who compares Python with C#, they are not even in the same league? Python is a glorified bash scripting replacement with a mediocre JIT engine. Modern C# is faster than Go which is what it is competing against.

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

#263

Post by radicalbyte »

dataflow wrote: post #182
eterm wrote: post #180

Earlier quoted context omitted.

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.

It's literally "twice as long" syntactically. 120 vs. 67 characters. And again, you keep omitting the rest of the line. (Why?) What you should've written in response was: var y = Enumerable.Range(1,50) .Where(e => e % 4 == 0 && e % 3 == 0) .Skip(1) .Select(e => e + 1) .ToArray(); Compare: y = [t[1] for t in enumerate(range(1, 50, 4)) if t[0] % 3 == 0][2:] And (again), my complaint isn't about LINQ or numbers or these…

There's not a lot of difference if you use the query syntax in C# (assuming you add an overload to Enumerable.Range() to take the skip) - only no-one uses that because it's ugly. Also really nice that the types are checked + shown by tooling, as is the syntax.

I use Python a lot for scripting - what it lacks in speed of development/runtime it gains in being more accessible to amateurs and having less "enterprise" style libraries (particularly with cryptographic libraries, MS abstract way too much whilst Python just has think wrappers around C). That makes Python a strong scripting language for me. PyCharm is really nice too.

For real work? C# is better as long as you have either VS or Rider. Really dislike the VS Code experience (these JS-based editors are slow and nowhere near as nice a Rider) so then I can understand why people would avoid it.

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

#264

Post by gpm »

rubyskills wrote: post #244
gpm wrote: post #161

Earlier quoted context omitted.

This is because numpy and friends are really good at matmul's. As soon as you step out of the happy path and need to do any calculation that isn't at least n^2 work for every single python call you are looking at order of magnitude speed differences. Years ago now (so I'm a bit fuzzy on the details) a friend asked me to help optimize some python code that took a few days to do one job. I got something like a 10x spee…

Have you tried porting the problem into postgres? Not all big data problems can be solved this way but I was surprised what a postgres database could do with 40 million rows of data.

I didn't, I don't think using a db really makes sense for this problem. The program was simulating a physical process to get two streams of timestamps from simulated single-photon detectors, and then running a somewhat-expensive analysis on the data (primarily a cross correlation).

There's nothing here for a DB to really help with, the data access patterns are both trivial and optimal. IIRC it was also more like a billion rows so I'd have some scaling questions (a big enough instance could certainly handle it, but the hardware actually being used was a cheap laptop).

Even if there was though - I would have been very hesitant to do so. The not-a-fulltime-programmer PhD student whose project this was really needed to be able to understand and modify the code. I was pretty hesitant to even introduce a second programming language.

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

#265

Post by AnimalMuppet »

orzig wrote: post #256
ineedasername wrote: post #230

Earlier quoted context omitted.

The speed of light has really not kept pace with Moore's Law. Engineers have focused overly much on clock speed and transistor density and completely ignored C, and it's really beginning to show.

Another consequence of our society’s reduced investment in fundamental physics - instead we go ether.

I recently read a science fiction short story on reddit, where humans had developed faster-than-light communication because they needed to reduce lag in networked games.

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

#266

Post by scarmig »

orzig wrote: post #256
ineedasername wrote: post #230

Earlier quoted context omitted.

The speed of light has really not kept pace with Moore's Law. Engineers have focused overly much on clock speed and transistor density and completely ignored C, and it's really beginning to show.

Another consequence of our society’s reduced investment in fundamental physics - instead we go ether.

Perhaps the solution is more on the bioengineering side of things: make smaller people so they can fit in smaller rooms.

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

#267

Post by 867-5309 »

babypuncher wrote: post #111
Guest19023892 wrote: post #26

Earlier quoted context omitted.

I upgraded a desktop machine the last time I visited my family. It was a Windows 7 computer that was at least 10 years old with 4GB of ram. They wanted to use it online for basic web browsing, so I thought I'd install Windows 10 for security reasons and drop in a modern SSD to upgrade the old 7200rpm drive to make it more snappy. Well, it felt slower after the "upgrade". Clicking the start menu and opening something…

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.

recently I've seen new laptops being shipped with 4GB. possibly with a slightly lighter (but not fully debloated) version of 10 (Home? Starter? Edu?)

I'm not sure if this is because Windows memory usage is a lot more efficient now, or if the newer processors' performances can cancel out the RAM capacity bottleneck, or if PC4-25600 + NVMe pagefiles are simply fast enough, or if manufacturers are spreading thinly during the chip shortage. but it's certainly an ongoing trend

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

#268

Post by contravariant »

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 in that (not that I'm saying that's what they should have done, I just don't understand how they use more code)

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

#269

Post by dylan604 »

grishka wrote: post #210
dylan604 wrote: post #197

Earlier quoted context omitted.

One. Frame. Of. What? I've never heard of someone describing how long something took like this without at least defining the frame rate.

Of video. Which probably was 30 fps. I mean, the splash screen just blinked for a barely noticeable split second before the main window appeared. You double click the shortcut, and it's already done launching before you realize anything. That's how fast modern computers are. (actually, some things on the M1 are fast enough that I'm now getting annoyed at networking taking what feels like ages)

Why would you assume video is at 30fps? Geographic location? People not in the US (and a handful of other countries) would assume video framerate of 25fps.

Does the refresh rate of a computer monitor get referred to as frames? Usually, it's just the frequency like 120Hz type units. Sorry for the conversation break, but I've just never heard app start up times with a framerate reference. Was just an unusual enough thing that I let me brain wonder on it longer than necessary

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

#270

Post by tester756 »

spc476 wrote: post #233
tester756 wrote: post #93

Earlier quoted context omitted.

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.

is this actually this binary?

I mean what if there are features that take significant % of whole time

What if getting rid of them could decrease perf by e.g 4%, but also decrease comp. time by 30%

would it be worth?

Post reply on HN