5 ms·

I remember being shocked when I saw someone (on HN) use the phrase “running on the bare iron” to mean “in user space of a computer running a multitasking operat

by gumby 3y ago

I remember being shocked when I saw someone (on HN) use the phrase “running on the bare iron” to mean “in user space of a computer running a multitasking operating system”. They in turn were incredulous that it could mean anything else — apparently an OS is needed, right? Still, in some ways it’s a good thing. People can write good code without knowing what an ALU is, much less a flip flop. The bigger problem is that there is little incentive these days to write good code at all; those who do of necessity know more than just their tiny domain.

bowsamic 3y ago
In my experience it is now such that even just writing and running a C++ program on a modern computer is considered "extremely low level". It's almost an extreme thing to do to decide to write a native program.
- gumby 3y ago
  Having written crt0 and for that matter hardware bring up for a couple of chips, that made me laugh. But I haven’t tried to design a (extremely primitive) chip since I was in college, so there’s plenty for others to laugh at me for too.
corethree 3y ago
Its a domain thing. And one domain in the world is expanding. Everyone in the world is becoming a web developer. Actually it already happened. Throw a dart at a group of software developers most likely that dart will hit a web developer. Web developers can write shitty code because most of the time the bottleneck is in the database. You just need to write code thats faster then the database and you don't need to optimize beyond that. Now all the optimizations center around pointless refactorings to keep up with the newest technology trend.
- KaushikR2 3y ago
  Optimization has taken a back-seat now, I'd say. We focus more on developer productivity, and that extra mile optimization isn't deemed necessary if that effort and time can be put toward another project, squeezing out more value from the developer.
- ndriscoll 3y ago
  IME it's quite rare for the database to be the bottleneck. People just don't know how to use it right. It's a pretty simple optimization to gather web requests into batches, and that can easily 10x your database throughput. At my last job we had architects pushing to do the opposite and turn batch files into single requests! Argh! Also if people are using RDS with EBS, they'll think storage IO is ~500x slower than a modern NVMe disk really is, which will warp their perception of how well an RDBMS should scale. Their gp3 SSD storage comes with 3k IOPS baseline up to 16k[0]. lol. "SSD storage". The volume size "scales" up to 16TB. You can get a new condition P5410 for $420 retail: 8 TB/drive with 100x the performance of a maxed out EBS volume. Similar misconceptions must exist with application performance. Lambda advertises being able to scale up to "tens of thousands" of concurrent requests[1]. My 6th gen i5 can do that with a few GB of RAM allocated to a single JVM process... [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp3-performance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-... [1] https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...
  - corethree 3y ago
    Database is the primary bottleneck of almost all web apps. This is different from solving bottlenecks you may find in other places. Let me put it this way. If you did everything right, then the slowest part of your web application is usually the database. Now you may find problems in the web application and fix bottlenecks there but that's not what I'm talking about. I'm talking about the primary bottleneck. In web basically the database is doing all the work the web application is just letting data pass through. The database is so slow that the speed of the web application becomes largely irrelevant. That's why languages like ruby or python can be used for the application, that's why C++ is rarely needed. This ultimately makes sense logically. The memory hierarchy in terms of speed goes from CPU cache to random access to fs with fs being the slowest. Web applications primarily use fs as it's all just about manipulating and reading state from the db. while a triple A game primarily runs on random access. Games do use the fs but usually that's buffering done in the background or load screens. This is why your reply doesn't refute a single thing I said. It doesn't matter if dbs use nvme. FS is still slower than an in memory store by a huge magnitude. Not to mention the ipc or network connection is another bottleneck. Web apps need to only be trivially made magnitudes faster then then the ipc and database and it's fine. Your batch calls to the db are only optimizations to the db which is still magnitudes slower then ram. Try switching those batch requests to in memory storage on the same process and keep the storage from bleeding pages to the fs and that will be waaay faster. After you fix that the bottlenecks of most web apps lie in the http calls and parsing and deserializarion of the data. But usually nobody in web cares for that stuff because like I said the db is way slower. Do you think a game engine can afford to do this stupid extra parsing and serialization step in between the renderer and the world updater? Hell no. That's why web developers can put all kinds of crap in the http handlers, because it doesn't matter. Though I will say I have seen a bottleneck where parsing was actually slower than access to redis. But that's rare and redis is in-memory so it's mostly the ipc or network connection here.
- jandrewrogers 3y ago
  > Web developers can write shitty code because most of the time the bottleneck is in the database. That is because most of the time web developers are bad at database things, it isn't an intrinsic property of database engines. A modern database engine on a single AWS VM can readily support 10M writes/sec through disk storage, not even in memory. And run operational queries against that data at the same time. Most web apps don't have requirements anywhere close to that. In practice, you are much more likely to run out of network bandwidth to the database than database throughput if your systems are properly designed. Even the database engines themselves are usually bandwidth bound these days.
  - corethree 3y ago
    It is an intrinsic property of database engines. Database engines access the fs. That is the slowest part of memory in a computer. The web app is stateless, it's never suppose to touch the fs. Additionally database engines usually exist as separate processes or servers necessitating need for ipc which is another intrinsic bottleneck. If an AWS vm can support 10 million writes/sec to disk storage then a stateless web app on the same vm should be even faster doing the same reads and writes to in memory storage. I can agree with your latter statement that io can become the bigger bottleneck these days.
    - jandrewrogers 3y ago
      You do not understand how modern databases actually work. Databases don't need to access the filesystem, fast ones work with the block devices directly. The slowest part of modern hardware is the network, not the storage. IPC performance isn't a real issue. Databases do their own I/O and execution scheduling, that is how they achieve extremely high write throughput. Unless your web app is designed this way (it isn't), you cannot achieve anything close to the throughput of a modern database engine. Performance is a product of software architecture. Being stateless does not make your software fast in any absolute sense, many stateless in-memory systems have mediocre performance. A disk-backed design with superior architecture can out-perform an in-memory design, both in theory and practice.
Animats 3y ago
Web devs think "rendering" means generating HTML, not pixels.
- hipadev23 3y ago
  JS web devs. SSR as a term didn't exist until React devs decided to reinvent the wheel and give it a new name.
  - throwaway11460 3y ago
    Nobody reinvented the wheel. The old wheel didn't run interactively on the client. The React devs that came up with the term used to be PHP devs. Do you remember XHP? SSR simply refers to the "render" method of the react-dom package being called on server. It's similar to, but distinct from template engine/MVC-style server side generated HTML.
- hamandcheese 3y ago
  Consider looking up the definition of render. You will find that it has nothing to do with pixels specifically.
  - bayindirh 3y ago
    There are many terms about computers in English which have been borrowed from similar acts in real life. Compiling, interpreting, context switching, branching, etc. Similarly, rendering is reserved for the last step, converting whatever you have to something which can be shown. You render videos, text, etc. The thing is, they are not modified further, they are shown. When you "render" to HTML, you "render it again" for display. So it's not rendering in "Computer Science Sense", hence making the usage wrong. Otherwise, JIT and interpreted would mean the same thing, but they're not. Because JIT allows tons of other things from a techincal point of view.
    - hamandcheese 3y ago
      Your screen buffer certainly undergoes additional transformations and modifications on the way to your monitor.
snovymgodym 3y ago
Eh, that's just an issue of term reuse being rampant in this industry. In the context of servers, it's accepted usage to use "baremetal" to mean "running on the physical host's operating system" as opposed to in a VM or container. But I recall the other meaning from OS class.

by gumby 3y ago

bowsamic 3y ago

In my experience it is now such that even just writing and running a C++ program on a modern computer is considered "extremely low level". It's almost an extreme thing to do to decide to write a native program.

gumby 3y ago
Having written crt0 and for that matter hardware bring up for a couple of chips, that made me laugh. But I haven’t tried to design a (extremely primitive) chip since I was in college, so there’s plenty for others to laugh at me for too.

corethree 3y ago

Its a domain thing. And one domain in the world is expanding. Everyone in the world is becoming a web developer. Actually it already happened. Throw a dart at a group of software developers most likely that dart will hit a web developer. Web developers can write shitty code because most of the time the bottleneck is in the database. You just need to write code thats faster then the database and you don't need to optimize beyond that. Now all the optimizations center around pointless refactorings to keep up with the newest technology trend.

KaushikR2 3y ago
Optimization has taken a back-seat now, I'd say. We focus more on developer productivity, and that extra mile optimization isn't deemed necessary if that effort and time can be put toward another project, squeezing out more value from the developer.
ndriscoll 3y ago
IME it's quite rare for the database to be the bottleneck. People just don't know how to use it right. It's a pretty simple optimization to gather web requests into batches, and that can easily 10x your database throughput. At my last job we had architects pushing to do the opposite and turn batch files into single requests! Argh! Also if people are using RDS with EBS, they'll think storage IO is ~500x slower than a modern NVMe disk really is, which will warp their perception of how well an RDBMS should scale. Their gp3 SSD storage comes with 3k IOPS baseline up to 16k[0]. lol. "SSD storage". The volume size "scales" up to 16TB. You can get a new condition P5410 for $420 retail: 8 TB/drive with 100x the performance of a maxed out EBS volume. Similar misconceptions must exist with application performance. Lambda advertises being able to scale up to "tens of thousands" of concurrent requests[1]. My 6th gen i5 can do that with a few GB of RAM allocated to a single JVM process... [0] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp3-performance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-... [1] https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...
- corethree 3y ago
  Database is the primary bottleneck of almost all web apps. This is different from solving bottlenecks you may find in other places. Let me put it this way. If you did everything right, then the slowest part of your web application is usually the database. Now you may find problems in the web application and fix bottlenecks there but that's not what I'm talking about. I'm talking about the primary bottleneck. In web basically the database is doing all the work the web application is just letting data pass through. The database is so slow that the speed of the web application becomes largely irrelevant. That's why languages like ruby or python can be used for the application, that's why C++ is rarely needed. This ultimately makes sense logically. The memory hierarchy in terms of speed goes from CPU cache to random access to fs with fs being the slowest. Web applications primarily use fs as it's all just about manipulating and reading state from the db. while a triple A game primarily runs on random access. Games do use the fs but usually that's buffering done in the background or load screens. This is why your reply doesn't refute a single thing I said. It doesn't matter if dbs use nvme. FS is still slower than an in memory store by a huge magnitude. Not to mention the ipc or network connection is another bottleneck. Web apps need to only be trivially made magnitudes faster then then the ipc and database and it's fine. Your batch calls to the db are only optimizations to the db which is still magnitudes slower then ram. Try switching those batch requests to in memory storage on the same process and keep the storage from bleeding pages to the fs and that will be waaay faster. After you fix that the bottlenecks of most web apps lie in the http calls and parsing and deserializarion of the data. But usually nobody in web cares for that stuff because like I said the db is way slower. Do you think a game engine can afford to do this stupid extra parsing and serialization step in between the renderer and the world updater? Hell no. That's why web developers can put all kinds of crap in the http handlers, because it doesn't matter. Though I will say I have seen a bottleneck where parsing was actually slower than access to redis. But that's rare and redis is in-memory so it's mostly the ipc or network connection here.
jandrewrogers 3y ago
> Web developers can write shitty code because most of the time the bottleneck is in the database. That is because most of the time web developers are bad at database things, it isn't an intrinsic property of database engines. A modern database engine on a single AWS VM can readily support 10M writes/sec through disk storage, not even in memory. And run operational queries against that data at the same time. Most web apps don't have requirements anywhere close to that. In practice, you are much more likely to run out of network bandwidth to the database than database throughput if your systems are properly designed. Even the database engines themselves are usually bandwidth bound these days.
- corethree 3y ago
  It is an intrinsic property of database engines. Database engines access the fs. That is the slowest part of memory in a computer. The web app is stateless, it's never suppose to touch the fs. Additionally database engines usually exist as separate processes or servers necessitating need for ipc which is another intrinsic bottleneck. If an AWS vm can support 10 million writes/sec to disk storage then a stateless web app on the same vm should be even faster doing the same reads and writes to in memory storage. I can agree with your latter statement that io can become the bigger bottleneck these days.
  - jandrewrogers 3y ago
    You do not understand how modern databases actually work. Databases don't need to access the filesystem, fast ones work with the block devices directly. The slowest part of modern hardware is the network, not the storage. IPC performance isn't a real issue. Databases do their own I/O and execution scheduling, that is how they achieve extremely high write throughput. Unless your web app is designed this way (it isn't), you cannot achieve anything close to the throughput of a modern database engine. Performance is a product of software architecture. Being stateless does not make your software fast in any absolute sense, many stateless in-memory systems have mediocre performance. A disk-backed design with superior architecture can out-perform an in-memory design, both in theory and practice.

Animats 3y ago

Web devs think "rendering" means generating HTML, not pixels.

hipadev23 3y ago
JS web devs. SSR as a term didn't exist until React devs decided to reinvent the wheel and give it a new name.
- throwaway11460 3y ago
  Nobody reinvented the wheel. The old wheel didn't run interactively on the client. The React devs that came up with the term used to be PHP devs. Do you remember XHP? SSR simply refers to the "render" method of the react-dom package being called on server. It's similar to, but distinct from template engine/MVC-style server side generated HTML.
hamandcheese 3y ago
Consider looking up the definition of render. You will find that it has nothing to do with pixels specifically.
- bayindirh 3y ago
  There are many terms about computers in English which have been borrowed from similar acts in real life. Compiling, interpreting, context switching, branching, etc. Similarly, rendering is reserved for the last step, converting whatever you have to something which can be shown. You render videos, text, etc. The thing is, they are not modified further, they are shown. When you "render" to HTML, you "render it again" for display. So it's not rendering in "Computer Science Sense", hence making the usage wrong. Otherwise, JIT and interpreted would mean the same thing, but they're not. Because JIT allows tons of other things from a techincal point of view.
  - hamandcheese 3y ago
    Your screen buffer certainly undergoes additional transformations and modifications on the way to your monitor.

snovymgodym 3y ago

Eh, that's just an issue of term reuse being rampant in this industry. In the context of servers, it's accepted usage to use "baremetal" to mean "running on the physical host's operating system" as opposed to in a VM or container. But I recall the other meaning from OS class.