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

801–810 of 819 posts

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

#801

Post by mikewarot »

ano88888 wrote: post #462
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…

Why can't we have a language easy to read and maintain but also have the speed of C?

>Why can't we have a language easy to read and maintain but also have the speed of C?

Swap out { } for Begin End, and make a few other changes, and you've got Pascal. Single pass pascal compilers have been faster (at compiling) that almost anything out there since Turbo Pascal 3.0 for MS-DOS.

Modern versions, such as Free Pascal, Delphi and Lazarus also deal with strings in a manner that totally avoids needing to manually manage memory. The GUI builders are awesome as well.

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

#802

Post by megous »

throwaway894345 wrote: post #651
megous wrote: post #612

Earlier quoted context omitted.

Many PHP and JS programmers can't write secure code either.

First of all, you’re comparing “most PHP and JS programmers” with veteran C programmers, and secondly most PHP and JS programmers can write code which is secure against memory-based exploits.

Which has not stopped them from allowing compromise of millions of servers.

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

#803

Post by Akronymus »

carlmr wrote: post #532
moffkalast wrote: post #529

Earlier quoted context omitted.

> that results in more education time for programers, which no company is willing to pay for That's why you finally stop teaching Java in high schools.

I was going to say OOP aside from the basic animals and calls example, takes years of indoctrination for people to find it the simple default way to do things. Functional programming is much simpler, but we don't spend years hammering the concept into people's brains.

With helping acquaintances learning programming from 0, I have a sample size of n = 2 that starting with FP got them to grok basic programming within a very short amount of time.

And IME moving from FP to OOP is MUCH easier than the other way around.

Don't really have the knowledge to compare iterative vs functional for a complete beginner, though I suspect that even there moving from FP to iterative is easier.

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

#804

Post by account42 »

LtdJorge wrote: post #718
von_lohengramm wrote: post #603

Earlier quoted context omitted.

I'd argue that SSDs have done more harm than good. Since the worst-case is now far superior that it used to be (HDDs), most developers see no need to optimize any further. For example, plenty of video game engines will stream copious amounts of data from disk instead of optimizing memory usage, asset size, and in general more creative solutions (i.e. shader effects instead of GBs of redundant assets). If hitting the…

Games are a bad choice as an example. (Some) Games are always trying to squeeze the most out the latest hardware. You can't have a massive world with 4K textures and no loading screens using an HDD and 8GB of RAM without performance degradation.

Games are a good choice as an example. *Some* games are trying to squeeze ot the most of the latest hardware but most just target a minimum acceptable framerate for common hardware and then move on. Good enough to ship is pretty much the game industry's entire mode of operation.

Also, games generally don't make good use of extra resources you have. Have 128 GiB ram and plenty of VRAM? In almost all games you're not going to see any less loading screens in most games than someone with 8 GiB ram even in really simple scenarious like going back to the area you just came from.

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

#805

Post by archi42 »

tester756 wrote: post #591
archi42 wrote: post #545

Earlier quoted context omitted.

Compiling a large number of files on Windows is slow, no matter what language/compiler you use. It seems to be a problem with the program invocation, which takes "forever" on Windows. It's still fast for a human, but it's slow for a computer. Quite apt this comes up here ;-) Source for claim: That's a problem we actually faced in the Windows CI at my old job. Our test suite invoked about 100k to 150k programs (our pr…

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 people to make many small contributions is important. I guess .NET was conceived as being internal to MS, so less people overall, but newcomers probably were assigned to a team for onboarding and then contributing to the project as part of that team. With other words: At MS you can call up the person or team responsible for that 10000 LOC monstrosity; but if all you got is a bunch of names with e-mail addresses pulled from the commit log, you might be in for a bad time.

3. Generated code: I don't know if either commit generated code into the repository. That can skew these numbers as well.

4. Header files can be a wild card, as it depends on how their written. Some people/projects just put the signatures in there and not too much details, others put the whole essays as docs for each {class, method, function, global} in there, making them huge.

For the record, by your stats .NET has 1180 LOC per file and LLVM 391 on average. That doesn't say a lot, the median would probably be better, or even a percentile graph. Broken down by type (header/definition vs. implementation). You might find that the distribution is similar and a few large outliers skew it (especially generated code). Or when looking at more, big projects you might find that these two are outliers. I can't say anything definite, and from an engineering perspective I think neither is "suspicious" or even bad.

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

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

#806

Post by kllrnohj »

BeFlatXIII wrote: post #673
kllrnohj wrote: post #315

Earlier quoted context omitted.

Shit performance is what happens when every response to optimizations or overhead is immediately answered with "premature optimization is the root of all evil." Or the always fun "profile it!" or "the runtime will optimize it" when discussing new language features and systems. So often performance isn't just ignored, it's actively preached against. Don't question how that new runtime feature performs today or even da…

Wouldn't "profile it!" be the exact opposite if ignoring performance wins? It tells you which optimizations will noticeably improve your performance and which are theoretical gains that made no difference to realistic workloads.

It's a dismissive answer. It'd be like if someone asked "why does 0.2f + 0.1f print 0.30000000001?" and getting back an answer of "use a debugger!" It's not strictly wrong, the debugger would provide you with the data on what's happening. But it doesn't actually answer the question or provide commentary on why.

Similarly, the "profile it!" answer is often used when the person answering doesn't actually know themselves, and is just shutting down the discussion without meaningfully contributing. And it doesn't provide any commentary on why something performs like it does or if the cost is reasonable.

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

#807

Post by orestarod »

dorgo wrote: post #701
d110af5ccf wrote: post #434

Earlier quoted context omitted.

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?

The universe expanding is a property of space itself. And "faster than light" is only because miniscule space expansion in any quantum of space adds up with distance, e.g. 1 picometer per kilometer per second, add enough trillions of kilometers and you get that faster than light expansion. There is no mass, particle or information moving THROUGH space faster than the speed of light, which is what the said limit concerns.

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

#808

Post by orestarod »

wruza wrote: post #585
diroussel wrote: post #62

Earlier quoted context omitted.

That is quite an amazing way to put it. So the processor in my hand can compute a multiplication fast than light can cross the room?

Not so extraordinary if you take into account that CPU is essentially a thumb-sized labyrinth for light.

Not light. It's electric potential that moves around. No visible photons involved.

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

#809

Post by orestarod »

grishka wrote: post #90
forinti wrote: post #22

On a 3GHz CPU, one clock cycle is enough time for light to travel only 10cm. 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.

Huh, but then I'm pretty sure that there are some paths inside the CPU die that are long enough that speed of light is a consideration at these frequencies. Must require a lot of smart people to design these things, yet it only takes a bunch of junior developers to bog them down.

There is indeed the speed of propagation of electric potential taken into account, that is, how long it takes for the input of a logical gate or a logical subsystem to produce the output (that involves the propagation of electric potential through the chip's conductors). If your clock is too fast for the size of your subsystem, the result will not be correct at the output before the next cycle begins, so your system will just be bogus.

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

#810

Post by illys »

I am amazed by the discussions below on computer performance vs. software inefficiency: I remember the same discussions and arguments about software running on 8088 vs 80286 vs 80386 vs i486 vs Pentium... and so on.

You could have had those discussion at anytime since the upgraded computers and microprocessors have become compatible with the previous generation (i.e. the x86 and PC lines).

The point is that software efficiency measurement has never changed: it is human patience. The developers and their bosses decide the user can wait a reasonable time for the provided service. It is one-to-five seconds for non-real-time applications, it is often about a target framerate or refresh in 3D or real-time applications... The optimization stops when the target is met with current hardware, no matter how powerful it is.

This measure drives the use of programming languages, libraries, data load... all getting heavier and heavier when more processing power gets available. And that will probably never change.

Not sure about it? Just open your browser debugger on the Network tab and load the Google homepage (a field, a logo and 2 buttons). I just did: 2.2 MB, loaded in 2 seconds. It is sized for current hardware and 100 Mbps fiber, not for the actually provided service!

Post reply on HN