301–310 of 819 posts
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 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.
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.
Earlier quoted context omitted.
Not that it invalidates anything you said, but it was 750ms vs 200 microseconds. But yeah. I agree. Why does Lightroom take forever to load, when I can query its backing SQLite in no time at all? And that's not even mentioning the RAM elephant in the room: chrome. Younglings today don't understand what a mindbogglingly large amount of data a GB is. But here's the thing: it's cheaper to waste thousands of CPU cores on…
Regarding chrome, browsers are basically operating systems nowadays. A standards compliant HTML5 parser is at the bare minimum millions of lines of code. Same for the renderer and Javascript engine.
Earlier quoted context omitted.
Yes but what kind of comparison is that: 1. How often do you need to execute 1000 GUI instances? 2. How often do you need to print "hello world"? The right tool for the right job.
This is a discussion about computers being slow. As in a person asks a computer to do something and the human waits while the computer does it. So python isn't the right tool for any job that involves human interaction.
One just has to not do anything dumb in the render loop and it's plenty responsive.
Of course, if you're going to interactively process a 50mb csv or something... But even then pandas is faster.
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…
I think it's even stronger than a habit. When you're exposed to the typical "performance" of the web and apps for a decade or so, you may have forgotten about raw performance entirely. Young people may have never experienced it at all. I once owned a small business server with a Xeon processor, Linux installed. Just for kicks I wrote a C program that would loop over many thousands of files, read their content, sort i…
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. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…
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.
Earlier quoted context omitted.
Please don't write programs in go. Sure it looks awesome on the surface but it's a nightmare when you get a null pointer panic in a 3rd party library. Instead use Rust. See here for more info: https://getstream.io/blog/fixing-the-billion-dollar-mistake-...
You've obviously been burned by null pointers (probably not just once). And you think they are a problem, and you're right. And you think they are a mistake, and you could be right about that, too. But they're not the only problem. Writing async network servers can be a problem, too. Go helps a lot with that problem. If for your situation it helps more with that than it hurts with nulls, then it can be a rational cho…
Earlier quoted context omitted.
> That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought. > Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good lib…
> secure C code. There is unsecure code hidden in every project that uses any programming language ;) I get what you're saying here, you're specifically talking about security vulnerabilities from memory related errors. I honestly wonder how many of these security vulnerabilities are truly issues that never would have come up in a more "secure" language like Java, or if the vulnerabilities would have just surfaced in…
As long as the vulnerability types that cause trouble in language B are a superset of those that cause trouble in language C, it makes sense to recommend moving from B to C for safety reasons.
This is true even if there is a language A that is even worse and in the absence of language C, we recommended moving from A to B. Code written in A will be worse in expectation than code written in B than code written in C.
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…
Implementations of languages like javascript, ruby - and I would presume python and php - are a lot faster than they used to be.
I think most slowness is architectural.
It's hard to evaluate this article without seeing the detail of the "algorithm_wizardry", there's no detail here just where it would be interesting.