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

701–710 of 819 posts

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

#701

Post by dorgo »

d110af5ccf wrote: post #434
CMCDragonkai wrote: post #432

Earlier quoted context omitted.

Is the speed of light really the speed of causality? Would the effect of gravity (the lack of) affect Earth earlier than us perceiving the lack of light.

Nope. All physical effects are bounded by the speed of light. (As far as anyone knows, anyway.) The only weird one is quantum entanglement, but even then information transfer doesn't travel faster than light and that's about all I know on that subject.

> All physical effects are bounded by the speed of light.

The universe expands faster than light. So this expansion is not a physical effect?

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

#702

Post by julius_deane »

mulmboy wrote: post #274

Doubtful that moving from vectorised pandas & numpy to vanilla python is faster unless the dataset is small (sub 1k values) or you haven't been mindful of access patterns (that is, you're bad at pandas & numpy)

but how else do you get to the front page of hn?

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

#703

Post by tcfhgj »

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.

C++ isn't remotely user friendly.

Have you ever tried Rust? Compared to C++, it's like heaven

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

#704

Post by julius_deane »

dfgqeryqe wrote: post #198
bornfreddy wrote: post #9

Earlier quoted context omitted.

Yes. Apparently they have used Python lists to beat highly optimized library which builds upon numpy, in C. Yeah right. Note that I'm not saying that their second version of the code wasn't faster, just that this has nothing to do with python vs. pandas.

You would think that, wouldn't you? But every time I've worked on a Python code base I have torn out Pandas and replaced it with simple procedural code, getting at least an order of magnitude. Pandas is spectacularly slow. I don't understand how or why, but it is.

the reason is here:

> I don't understand how or why

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

#706

Post by meshaneian »

winternett wrote: post #698
skohan wrote: post #453

I remember the moment I realized how fast computers are at uni. I was in an algorithms course, and one of our projects was to make a program which would read in the entire dataset from IMDB of films and actors, and calculate the shortest path between any actor and Kevin Bacon using actors and movies as nodes and roles as edges. I was working in C, and looking back I came up with a quite performant solution mostly by…

I was working at my UNI library around 97 when a fresh t3 (~45MBPS) line was just installed... We also got brand new top of the line Micron computers as well there. I was the first person to test the connection and after years of working on 56k modems I couldn't believe how everything I clicked suddenly worked at the speed of light. Videos I clicked on (on MTVs web site back then) loaded instantly, almost felt as if…

Just like freeways - add more traffic lanes, get more traffic.

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

#707

Post by julius_deane »

Someone wrote: post #562

FTA: Note that the output of this function needs to be computed in less than 500ms for it to even make it to production. I was asked to optimize it. […] Took ~8 seconds to do 1000 calls. Not good at all :( Isn’t that 8ms per call, way faster than the target performance? Or should that “ 500ms ” be “*500 μs”?

percentages in the post are wrong too

no surprise pandas was "slow"

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

#708

Post by igouy »

gilbetron wrote: post #643
kaba0 wrote: post #569

Earlier quoted context omitted.

Go can be faster at small, specific programs where memory lifetimes are deterministic and you can use value types. Otherwise, Java will beat every other managed language by a huge margin when it comes to GC-related workflows. Sure, it does so at higher memory usage, but that is a good tradeoff for many use-cases (especially server). Benchmarks are hard to do right but this one does actually measure GC quite well: htt…

You picked binary trees, which has java better than Go, I'm guessing something about the implementation. If you look at other examples on that site, Go and Java are roughly the same, but with some variance: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> … guessing something about the implementation.

The source code is shown —

    binary-trees Java #7 program
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

    binary-trees Go #2 program
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#709

Post by dragontamer »

reacharavindh wrote: post #440
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…

This reminds me of that “todo” I wrote for myself a long time ago. These days processors come with bigger L1,L2, and L3 caches. Would it be possible for a program that works on a tiny bit of data(few KB) to load it all up in the cache and provide ultimate response times?! Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

> Are there any directives to the Operating System to say - “here keep this data in the fastest accessible L[1,2,3] please”?

Not for general purpose programs, because L1 caches change so quickly each year there is no point.

For embedded real-time processors, yes. For GPUs, yes. (OpenCL __local, CUDA __shared__).

This is because Microsoft's DirectX platform guarantees 32kB or something of __shared__ / tiled memory, so all GPU providers who want a DirectX11 certification are guaranteed to have that cache-like memory that programmers can rely upon. When DirectX12 or DirectX13 comes about, the new minimum specifications are published and all graphics programmers can then take advantage of it.

-------

No sane Linux/Windows programmer however would want these kinds of guarantees for normal CPU programs, outside of very strict realtime settings (at which point, you can rely upon the hardware being constant). Linux/Windows are designed as general purpose OSes.

DirectX 9 / 10 / 11 / 12 however, is willing to tie itself to the "GPUs of the time", and includes such specifications.

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

#710

Post by morelisp »

paskozdilar wrote: post #683
morelisp wrote: post #679

Earlier quoted context omitted.

> Channel reading and writing is isomorphic to read() and write() syscalls This is a very bad mental model because channels operations cannot be canceled (without using select on two channels) or return any error status (at all).

While technically true, I don't really see the impact of the difference. It is idiomatic to use contexts for any kind of cancellation during channel operations, and it works well. The syscall comparison was made to give intuition about general behavior of channels to someone with a background in C. Of course it's not completely identical.

The ability of read/write to communicate via errors as well as the actual data transferred is significant - there's a reason Go's i/o model is io.Reader/io.Writer and not chan []byte.

You might as well explain channels in terms of any blocking operation if the bar for "isomorphic" (now backtracked to "intuitively" I guess) is that low.

Post reply on HN