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

811–819 of 819 posts

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

#811

Post by rasz »

hinkley wrote: post #767
necovek wrote: post #558

Earlier quoted context omitted.

In a sense, knowing this can also hurt you. At all my recent jobs, I grow frustrated with how slow running a single unit test is locally on a codebase. We are talking 5+ seconds for even the most trivial of trivial unit tests (say, purely functional arithmetic unit test). And this is even with dynamic languages like Python (you see pytest reporting how your unit test completed in 0.00s, and wall time is 7s). And then…

How on earth are you getting 5 seconds for simple tests? Simple tests should be running in 8ms, and those are my 2015 numbers that I've been too lazy to update.

Last time I played with python adding one empty line to my source code was slowing execution my ~8ms.

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

#812

Post by paskozdilar »

kaba0 wrote: post #664
paskozdilar wrote: post #659

Earlier quoted context omitted.

> In my experience all 3 can be written in a really well maintainable way. That's true, but that is generally true of any (non-toy) language. But in the modern world of rapid development, it matters how hard is it to write code in a non-maintainable way - i.e. how well it tolerates modifications by different people. And to me, it seems easier to write readable code in Go than it is to write unreadable code. It seems…

Could you expand a bit on why do you think Java has too many features? It is a very small language, that is often berated because it picks up features way too slowly if anything. I would go as far to claim that Java is an easier language than Go, or at least in the same ballpark.

> Could you expand a bit on why do you think Java has too many features?

I think you're asking for technical details, but I'm afraid I don't know Java well enough to do an objective comparison. I'll try with a subjective explanation or why I think so.

I've learned Go in 20 minutes following the Go Tour. Few months later, I feel like there isn't a single thing I don't know about Go. It's dead simple. When I open a Go repository, it's easy for me to get into the codebase, as all code is more-or-less the same.

I've learned Java back in high school, and to this day I don't feel like I "know" the language. I've tried reading some Java repositories, and every time I feel like there's some kind of friction - some implicit knowledge about it that I just don't understand.

Maybe it's just me, and I haven't spent enough time learning Java. But then again, I've spent even less time learning Go, and yet I have a much easier time using it. That's what I mean by "a very small language".

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

#813

Post by jcelerier »

archi42 wrote: post #805
tester756 wrote: post #591

Earlier quoted context omitted.

It's crazy that they have multiplied files count by 7 meanwhile the code just by 2 is it some C++ header file overhead? or they do something specific?

I can only guess, I am neither a LLVM nor a MSVC dev. 1. Compile times: If you have one file with 7000 LOC that and change one function in that file, the rebuild is slower than if you had 7 files with 1000 LOC instead. 2. Maintainability: Instead of putting a lot of code into one file, you put the code in multiple files for better maintainability. IIRC LLVM was FOSS from the beginning, so making it easy for lots of p…

> My gut feeling says 700 would be a number I'd expect for a large project.

aha, I remember when I was in class, the absolute rule our teachers gave us was no more than 200 lines per file

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

#814

Post by Schiendelman »

MichaelZuo wrote: post #795
colejohnson66 wrote: post #786

Earlier quoted context omitted.

Theres actually a name for that phenomenon: Braess’ Paradox https://en.wikipedia.org/wiki/Braess%27s_paradox

Though it's only a paradox for a small number of additional lanes. If 100 lanes are added then traffic will speed up.

It’s unclear that’s the case, because there are other limitations at work! Merging is a huge time cost and slows down two lanes; the more lanes, the more merges are necessary to use the new lanes. There’s some work suggesting it makes more than three lanes in one direction essentially useless in urban areas - and that’s where the traffic is…

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

#815

Post by Agentlien »

necovek wrote: post #549
w0mbat wrote: post #392

Article says at one point, "We have reduced the time for the computation by ~119%!", which is impossible. If you reduce it by 100% it is taking zero time already.

People like to talk in percentages when it's obviously unclear what it means, and they frequently get it wrong. It gets even better when people start switching between percentages and "percentage points" referring to a measure that's in percentages originally. Unfortunately, most of those things are easier communicated and harder to get wrong if you try speaking in a more natural way. This is now "twice as fast" or "…

I work primarily with optimizations and depending on context I will express them in how much time it shaves off one iteration ("this saves 1 ms!"), the change in frame rate ("went from 20-22 fps to a stable 26 fps"), or the ratio between before and after ("it's twice as fast", "only takes one third of the time it used to!", ...)

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

#816

Post by MichaelZuo »

Schiendelman wrote: post #814
MichaelZuo wrote: post #795

Earlier quoted context omitted.

Though it's only a paradox for a small number of additional lanes. If 100 lanes are added then traffic will speed up.

It’s unclear that’s the case, because there are other limitations at work! Merging is a huge time cost and slows down two lanes; the more lanes, the more merges are necessary to use the new lanes. There’s some work suggesting it makes more than three lanes in one direction essentially useless in urban areas - and that’s where the traffic is…

I mean it in the literal sense, past a certain point the city no longer exists as the lanes replace all other land uses and by definition without any source of traffic, the traffic will cease to exist as well.

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

#817

Post by [deleted] »

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…

[deleted]

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

#818

Post by Schiendelman »

MichaelZuo wrote: post #816
Schiendelman wrote: post #814

Earlier quoted context omitted.

It’s unclear that’s the case, because there are other limitations at work! Merging is a huge time cost and slows down two lanes; the more lanes, the more merges are necessary to use the new lanes. There’s some work suggesting it makes more than three lanes in one direction essentially useless in urban areas - and that’s where the traffic is…

I mean it in the literal sense, past a certain point the city no longer exists as the lanes replace all other land uses and by definition without any source of traffic, the traffic will cease to exist as well.

Ha! That’s true too.
Post reply on HN