[deleted]
The computers are fast, but you don't know it
641–650 of 819 posts
Re: The computers are fast, but you don't know it
#642Earlier quoted context omitted.
Yeah, I've written static site generators in Go and Rust among other languages (it's my goto project for learning a new language). Neither needed incremental builds because they build instantly. The bottlenecks are I/O. I've also worked in Python shops for the entirety of my career. There are a lot of Python programmers who don't have experience with and thus can't quite believe how much faster many other languages a…
Python is slow in many things like pure looping and arithmetic, even though there are workarounds to make that 1-10x slower rather than 100-1000X (eg. C-based implementations, including all the itertools stuff). I am sometimes frustrated that I can't just loop over a string character by character and not get crappy performance, but the "problem" you (and me) are seeing in existing codebases is that Python is very inv…
> even though there are workarounds to make that 1-10x slower rather than 100-1000X (eg. C-based implementations, including all the itertools stuff).
These only apply for specific problems, and very few applications are purely CSV parsing or purely matrix math operations. In the real world, you often spend more time marshaling your Python data to C than you save by doing your computation in C.
> But as you note, bottleneck is the I/O, and a program waiting for I/O in Python and I/O in C will wait the same time after the computation is done.
The bottleneck in a static site generator is I/O. The fact that Python, Ruby, etc based implementations take tens of seconds or more while Go and Rust finish instantly for an I/O bound problem is pretty damning.
> If you are writing software that can parallelize well independently (eg. web apps) and your memory pressure is not the most important thing, you simply run multiple Python processes to max out the CPU (this avoids the GIL unlike async Python).
The goal isn’t to saturate the CPU as much as it is to complete requests in a timely fashion. If it’s just some light translation between HTTP and database layers, Python is fine, but if you have to do anything computationally significant at all, it can range from “a huge pain” to “virtually impossible”. I gave the example earlier of a web service that was struggling to complete requests in even 60s (despite using Numpy under the hood where possible) while a naive Go implementation completed in hundreds of ms.
Re: The computers are fast, but you don't know it
#643Earlier quoted context omitted.
Go is in my experience significantly faster than Java, and uses an order of magnitude less memory for equivalent functionality. If you have any data (or better yet, benchmarks I can run on my own machine), I'd very much like to see some hard numbers.
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/...
Re: The computers are fast, but you don't know it
#644Earlier quoted context omitted.
That’s a ram issue not a processor issue. At least, that’s according to Apple https://appleinsider.com/articles/22/06/11/stage-manager-for...
The funny thing is that actual Macs with 4GB RAM are also supported and they can run the entire desktop environment.
WindowServer runs like a pig though, consistently the most expensive process (in terms of memory) on my mac systems.
Re: The computers are fast, but you don't know it
#645Earlier 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…
Why have an engineer spend a day optimizing the program when you can have it spend a month implementing features nobody asked for?
Why not both?
Re: The computers are fast, but you don't know it
#646Earlier quoted context omitted.
I would say to the local farm, then you have to wait for the cow to be milked (like an external api call...). At the end you just reduced you journey time by 0.1%, and incread you code complexity by 100%.
On the other hand, to non-webdevs, webdevs are like an obese american woman trundling down the road on her mobility scooter, giving the evil eye to people overtaking her on foot as she takes a bite out of a hunk of RAMcheese.
As an overweight-midwestern-american, RAMcheese sounds great!
Re: The computers are fast, but you don't know it
#647Earlier quoted context omitted.
I wonder if you'd have any more luck with that hardware putting Ubuntu Mate on it. For basic web browsing, it probably wouldn't matter much to your family whether it's running Windows or Linux.
Problem with Ubuntu is it doesn’t auto update and it’s very hard to get it to do that. Not sure it’s even possible to auto update major releases as well. Every time I have installed Ubuntu for someone, I have come back years later and it’s still on the same version.
That is strange. Did you try any of these?
https://help.ubuntu.com/community/AutomaticSecurityUpdates
I am not sure about major release upgrades. But if you are on an LTS release, this should cover it for five years. And as much as I dislike snaps, they do auto updates too, so in 22.04 Firefox at least keeps up-to-date too.
Re: The computers are fast, but you don't know it
#648Earlier quoted context omitted.
It's not "the C part" that makes code run fast, but memory access patterns. C just happens to not get in the way between the coder and the machine when it comes to explicit control over memory layout. In the late 60's and early 70's this was probably an "accidential feature", but with the widening CPU/memory performance gap it turned out that later languages (from the late 90's and early 00's) had bet on the wrong ho…
So a good language, should not abstract that memory pyramid away, but instead make you painfully aware of it, while developing. Rewarding DOD, punishing OO, but that results in more education time for programers, which no company is willing to pay for. What instead is needed is a intermediate language, that takes the constructs of object orientation and the instruction flow and allows to rearrange them for maximum me…
I believe that the direction of a managed language with value types is a good goal.
I especially like Java’s plan of introducing them: according to the latest design iteration, there will be 3 buckets of objects: current identity-having ones, value classes and primitive classes.
The second category would drop identity, but will keep nullability (for example two DateTime instance of the same value will be considered equal on a VM-level, allowing for optimizations like allocating DateTime’s inside an array serially, or stack-allocation. Nullability is important because there is no sane default value choice for for example a DateTime. But this value can be encoded cleverly similarly to what Rust does with optional)
The third category will loose nullability as well and current primitives will be migrated to it. So a ComplexInt “class” will be possible to implement with “zero” overhead.
My point being that there are two ways of improving performance, either showing more knobs to manipulate, or to raise the abstraction level, allowing cleverer optimizations. C# does the former, while Java never went that route, and I think that the latter approach better fits a managed language and can easily push it for like 90% better performance at a fraction of developer complexity.
Re: The computers are fast, but you don't know it
#649Earlier quoted context omitted.
Isn't a lot of server code these days small programs that just pull data out of a database and feed it to an HHTPS response? It seems like it's a pretty good option to have your infrastructure code implemented in a systems programming language like C or Rust (probably AWS or GCP is doing this for you), and just implement your business logic in Go as the type of small, well-defined programs you're talking about.
But then why go? You can also implement that logic in a likely much more readable way in Python (as at that point performance doesn’t matter), or just write the whole thing in Java/C#/Scala/Kotlin whatever, which in my opinion are more expressive for business logic.
In my experience, Python is far less readable than languages like go. The information density and semantic whitespace of Python really hurts readability.
Re: The computers are fast, but you don't know it
#650Earlier quoted context omitted.
That includes C versus modern CPUs.
The CPU is the CPU regardless of what language you are running on it. C will still give you the best performance on a modern CPU. If anything, C has an even bigger advantage on modern CPUs because it has easier access to things like vectorize/SIMD intrinsics. It is also easier to tweak your data dependencies to help the branch predictor.
> If anything, C has an even bigger advantage on modern CPUs because it has easier access to things like vectorize/SIMD intrinsics. It is also easier to tweak your data dependencies to help the branch predictor.
Have you seen the ridiculously complex optimizations that C compilers do to maybe turn some shitty for loop into vector instructions? C is terribly bad fit for this use case and hardware tries to get closer to C than the reverse.
C++, Rust but even C# and Java has much better SIMD support than C has.
EDIT: It really doesn’t help C (and some of the listed languages as well) that they are very imperative. SIMD is exactly the place where pureness and some form of FP is much better at allowing these kind of optimizations (a map of a pure function can be “trivially” optimized into vector instructions, while it is really hard to decide whether this for loop is safe to convert, and it is really up to the heuristics of the compiler. A bit of rearrangement can cause a failure to optimize, resulting in a huge drop in performance)