Earlier quoted context omitted.
No, amdahl's law is (roughly speaking) a limit to how parallel an algorithm can be. Applications (in the sense of web apps) generally have the potential to scale via Gustafson's law, but we are (IMO) largely held back by framework and old ways of programming. https://en.wikipedia.org/wiki/Gustafson's_law
So long as an application needs to share state between worker processes, (database, redis cluster, etc) then Amdahl’s law still applies. There’s very few modern applications that can truly scale linearly.
We’re approaching the limits of computer power – we need new programmers
221–230 of 265 posts
Re: We’re approaching the limits of computer power – we need new programmers
#222Earlier quoted context omitted.
Virtual reality and augmented reality
I'm doing VR on a 6 year old i7 and it runs perfectly fine. Improvements come almost entirely from updating the gpu
Re: We’re approaching the limits of computer power – we need new programmers
#223Earlier quoted context omitted.
Some times, there's one feature that's so useful it justifies the lack of many others. Google Docs is a terrible word processor compared to Word or even Pages, but being able to edit a document at the same time as someone else (with full features and little friction—IIRC Pages doesn't support Track Changes while collaborating) is so useful that I end up using Google Docs anyway.
How is google docs a terrible word editor? Do you mean that it lacking the advanced but rarely used features of word?
- Always-visible word count (added recently, but missing for nearly a decade)
- Custom text styles—you can modify the existing ones, but not create new ones with new names
Re: We’re approaching the limits of computer power – we need new programmers
#224Earlier quoted context omitted.
Functional program helps immensely, but I don't think you are describing it quite right. You cannot to distributed systems without concurrency. Even if you don't have low level synchronization failures, you still need to watch out for determinism. Fortunately we have the math for that (usually order theory). I make this point as someone whose job is Haskell. Too many people expect awesome magic sauce and basically wr…
Meant that it enables concurrency and parallelism without having to worry so much about the mechanics of it, which helps take advantage of multiple cores as described in the article. Immutable data structures and pure functions avoid data corruption when two or more threads are working on the same data. OOP requires a lot of code to get the same result, true? I'm new to FP myself and it seems like if done wisely it s…
Haskell helps loads here but the mechanisms are a lot more complex and nuanced than the circa 2000 ideology you were saying.
Re: We’re approaching the limits of computer power – we need new programmers
#225Earlier quoted context omitted.
What about battery life? If you prefer, call it carbon footprint. Python has a huge carbon footprint. We should get rid of slow languages for environmental reasons.
But then we'd have to pour in more manpower, which involves more commute, more upkeeping (AC, lunch), etc.
Plus we have a lot of pretty awesome languages that are mature enough and are serving very different niches (so their union can cover everything in IT) like Rust, Erlang/Elixir, Zig, OCaml (which can be transpiled to two JS variants, BuckleScript and ReasonML), TypeScript, and probably 20+ others.
Not to derail the thread but the dependency on very slow and hard-to-debug dynamic languages like Ruby and Python is getting out of hand.
Statements like "But it's easier to find devs for Python and Ruby than it is for Rust and Elixir" might be statistically correct now but that means nothing. People change technologies as market demands change so I am absolutely not worried about displaced programmers. There's almost no such thing as displaced programmers either, 99% of all my acquaintances just learned the new tech their employer wanted from them and moved on to the next stable paycheck.
Re: We’re approaching the limits of computer power – we need new programmers
#226Earlier quoted context omitted.
Well it is better than making even trivial architectures with actual hardware (I have some pictures of me hauling servers over xmas a long time ago; that was cheap (in monthlies and hardware, not in hours!) but I would and do pay a premium for that). Otherwise I do agree somewhat; most overbearing systems can be done much simpler but we are all preparing (and thus paying) for eventualities that most likely will never…
There are some significant high volume cases. We work with companies doing billions of Lambda invocations per month and realising large cost saving benefits. Lambda itself is usually the smallest part of the bill as one of the advantages of building serverless applications is you shift the responsibility of certain execution to specially designed managed services as opposed to code consuming CPU cycles; for example A…
But to be fair, for most projects the complexity that Amazon's services carry with them is absolutely not justified. Sure I can learn to work with 10-20 Amazon services but even me as a senior guy who knows his way around pretty much anything you throw at him, that's precious time spent not helping the direct business needs but basically making sure the house won't collapse.
And a lot of smaller companies like to merge the "programmer" and "DevOps" titles into one person because of course, that means one paycheck and not two. And as you said, they get angry that you can't become a pro sysadmin in an afternoon.
I suppose I am just trying to say yet again that many companies reach for BigCorp tools when they really ought to be fine with 2-3 DigitalOcean droplets and 1 dedicated DB droplet, plus 1 extra for backups.
Re: We’re approaching the limits of computer power – we need new programmers
#227Earlier quoted context omitted.
So long as an application needs to share state between worker processes, (database, redis cluster, etc) then Amdahl’s law still applies. There’s very few modern applications that can truly scale linearly.
You're confusing something. Fully consistent databases are primarily limited by the speed of communication because they need to replicate writes and queries to all nodes and wait for a response even if a node is on the other side of the planet. Unless your CPU is extremely slow (clock frequencies of a few kilo Herz) the speed of light is a significantly more important limit. This is actually a usecase where modern CP…
I've noticed my compilation speeds got dramatically better (compared to a MacBook Pro and an old-ish i7-3770 desktop PC). And it can handle even the sluggishness of Slack just fine without you noticing a lag, which I view as a huge achievement.
However, one thing my very detailed system monitors are telling me every day is -- 99% of all software we use every day is not parallel enough. So I have this amazingly powerful CPU that only (1) Git garbage collection, (2) PostgreSQL restoring a big backup, (3) Rust compiler and (4) [partially] Elixir compiler can saturate to its full potential.
I'd say that if everybody buys the new AMD Threadrippers and PCIe 4.0 motherboards, RAMs, SSDs and GPUs, we'd all be collectively fine for like 10 years.
The software however, it badly needs more parallel processing baked in it.
Re: We’re approaching the limits of computer power – we need new programmers
#228Earlier quoted context omitted.
But that is the case now too and in my experience it swung to paying through the nose for hardware in general; as more or less a sidetrack I take on projects where I optimise (mostly online) systems. Example; a few weeks ago a startup asked me to check out their setup as they were spending almost 30k$/mo on AWS. I spent a few days optimising and now they are down to less than 10k$. With some more work it will be a fe…
> paying through the nose for hardware in general You also have to consider that there are limits to how parallel an application can be - Amdahl's Law - at some point even throwing hardware at a scaling issues has its limits. Of course, there's also a truism that the team who implemented the first pass won't have to support (financially or as a developer) the software when it no longer scales.
In practice most software is light years away from this theoretical limit of "can't be anymore parallelised". And I fully agree that throwing hardware at a problem indeed has limits, although they are financial and not technical IMO.
As mentioned in another comment down this tree of comments, my 10-core Xeon workstation almost never has its cores saturated yet I have to sit through 5 seconds to 2 minutes of scripted tasks that can relatively easy be parallelised -- yet they aren't.
And let's not even mention how my NVMe SSD's lifetime saturation was 50% of its read/write limit...
There's a lot that can be improved still before we have to concern ourselves with how much more we can parallelise stuff. That's like worrying when will the Star Trek reality come to happen.
Re: We’re approaching the limits of computer power – we need new programmers
#229Earlier quoted context omitted.
seems like you deserve more of a cut than that.
Well, the premise going in after a quick (very quick) review of the system was: 'I will check what I can do in 5 days at $10k; I believe I can help, but if I cannot, you lose $10k. If I can help you in less time, you only pay that time.'. I do not think I can move that to some other deal with that premise. Maybe if I say; 'I will do this for 50% of the money you save in 12 months after I am done' that would work, but…
I am definitely a spiritual brother with you because I love optimising things. But I am very unsure how do I even start a side career with that premise.
Any advice?
Re: We’re approaching the limits of computer power – we need new programmers
#230Usually poorly performant code needs optimisation through a change of approach or mindset. It is the way we are thinking about the problem that is lowering performance. Not necessarily the hardware itself. I've seen locking brought forward as a critical limit. Long discussions about new hardware and adding nodes and all sorts of expenditure required. We need a larger kubernetes. More GPUs! I've also been in the situa…