5 ms·

Rust will fare well. Ruby won't.

by cft 7y ago

fouc 7y ago
Ruby isn't in the critical path, so that's a bad example. In general, the real issue is the layers of abstractions between the hardware and the end user. The over complicated architectures. The constant re-invention of databases/operating systems/virtual machines at each layer.
- oblio 7y ago
  > The constant re-invention of databases/operating systems/virtual machines at each layer. Those are because of the human struggle, the political and economic fights. They're not because of purely technical problems. Each layer is usually backed by a party with a very clear interest, usually control, and each layer on top tries to escape that control. It's been that way since the times of p-code.
- clarry 7y ago
  > The constant re-invention of databases/operating systems/virtual machines I wish that were the case but operating systems and systems software in general seems to be the most stagnant field. Everyone just buys the same FLOSS stack for $0 and compatibility is king, so there's very little research going in this field and much less of it ends up in any product you're ever going to see in use. I would love to see a vibrant scene of competing operating systems and databases with fresh new ideas and research.
  - fouc 7y ago
    I meant that it is re-implemented at every layer.. Like a browser is practically an OS on its own.
ivalm 7y ago
I don't have a hat in the game but why won't Ruby do well or not well based on this? It's not like basic webapps need to be much more efficient, and no one was writing high performance compute in ruby anyways.
- DennisP 7y ago
  Looking over the techempower benchmarks, the fastest web frameworks are over fifty times faster than ruby/rails. If you can replace a hundred web servers with two, that matters.
  - ghettoimp 7y ago
    Sure. But an awful lot of folks don't have a hundred web servers. If you're running something simple, you can pretty much use whatever you want.
  - ativzzz 7y ago
    The vast majority of web apps are CRUD apps, which can achieve sub 100ms responses on any language with caching, background workers and minor optimizations. There will always be problems where you need faster responses, and the solutions to those problems are already not using Ruby. You don't use a hammer when a screwdriver is appropriate, but nails work pretty well in most places and screws are unnecessary.
    - DennisP 7y ago
      100ms with how many responses per second? Throughput matters too. And techempower does some pretty realistic-looking benchmarks. For example: > In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size). An additional fortune cookie message is inserted into the list at runtime and then the list is sorted by the message text. Finally, the list is delivered to the client using a server-side HTML template. The message text must be considered untrusted and properly escaped and the UTF-8 fortune messages must be rendered properly. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
      - ativzzz 7y ago
        > 100ms with how many responses per second As always, it depends. Benchmarks are cool, and yes we know that Rust and Go will always be faster than Ruby out of the box. Once the number of responses goes up, you throw caching at the problem. But the benchmark says > The requirements were clarified to specify caching or memoization of the output from JSON serialization is not permitted. > the table has 12 rows Which is low and should be quick regardless, but regardless of your tech stack if you are creating a "modern" UI, you handle this update asynchronously with JS anyway, and if you're not, do you really care about sub 100 ms responses? If you want performance out of the box, yes you will use Go, but like I said earlier, you use a hammer for nails and a screwdriver for screws. If you want performance and type safety, you choose one, if you want faster prototyping and a more mature web dev ecosystem, you choose another.
buzzkillington 7y ago
FPGAs will fare well, general processors won't. You know we've reach the end of Moore's law when balanced ternary computers become the norm.
csomar 7y ago
That has a lot to do with why I took on learning Rust. My last year Macbook Pro has a 6-core CPU. At this rate, we should have 32-64-core CPUs for consumers in a few years. Not using all the processors means your program only makes use of 3-1.5% of the available power. My prediction is that, in a few years, lots of programming languages and software developers will simply become obsolete because what the other guys can produce is heaps of performance, security and manageability atop. But I might be wrong, so make your career decisions carefully.
- oblio 7y ago
  I hope you're right. However Intel Core Duo was released in January 2006 and it had 2 cores. So in a bit more than 13 years we only have 3x as many cores. Core 2 Quad was released in January 2007, so if you count from that one, a bit more than 12 years for 1.5x as many cores. I wouldn't bet on widespread 64 core CPUs for consumers in the next 10 years or so. Most commercial software just doesn't use it efficiently and consumers don't need it for existing software. We need a software breakthrough, a killer app, something that people really want and that really needs a ton of cores. For now, I don't see it. But then again, that's how killer apps are, nobody sees them until they're there.
  - csomar 7y ago
    > However Intel Core Duo was released in January 2006 and it had 2 cores. So in a bit more than 13 years we only have 3x as many cores. Core 2 Quad was released in January 2007, so if you count from that one, a bit more than 12 years for 1.5x as many cores. https://xkcd.com/605/ https://xkcd.com/605/ If you are going to extrapolate, don't pick the date. Take all the numbers you have and trace the average value. If you are picking the numbers, you can extrapolate to any point you want. > I wouldn't bet on widespread 64 core CPUs for consumers in the next 10 years or so. We already have 32-core processors for servers. Imo, the biggest challenge will be the laptop and heat management rather than putting a bunch of processors together. > We need a software breakthrough, a killer app, something that people really want and that really needs a ton of cores. We need that now. Most software I'm using is slow. Part of why I picked the iPhone (and I bet many people did) was speed. It is fast. People care about speed and if you introduce them to something faster then they'll get hooked. Also, you are already using all of your cores because of multi-tasking. It makes your computer experience overall better. At 6 cores, multi-threading for an application doesn't give much noticeable experience, since you probably have 5-6 things running on your computer doing other stuff like network or an audio-player. > For now, I don't see it. But then again, that's how killer apps are, nobody sees them until they're there. > I hope you're right. Don't worry, just hang in there. The start of multi-cores was slow but then that's all there is right now. Seems intel/amd have mastered how to add more cores but the CPU frequency is pretty much capped going forward!

Rust will fare well. Ruby won't.

by cft 7y ago

Rust will fare well. Ruby won't.

fouc 7y ago

Ruby isn't in the critical path, so that's a bad example. In general, the real issue is the layers of abstractions between the hardware and the end user. The over complicated architectures. The constant re-invention of databases/operating systems/virtual machines at each layer.

oblio 7y ago
> The constant re-invention of databases/operating systems/virtual machines at each layer. Those are because of the human struggle, the political and economic fights. They're not because of purely technical problems. Each layer is usually backed by a party with a very clear interest, usually control, and each layer on top tries to escape that control. It's been that way since the times of p-code.
clarry 7y ago
> The constant re-invention of databases/operating systems/virtual machines I wish that were the case but operating systems and systems software in general seems to be the most stagnant field. Everyone just buys the same FLOSS stack for $0 and compatibility is king, so there's very little research going in this field and much less of it ends up in any product you're ever going to see in use. I would love to see a vibrant scene of competing operating systems and databases with fresh new ideas and research.
- fouc 7y ago
  I meant that it is re-implemented at every layer.. Like a browser is practically an OS on its own.

ivalm 7y ago

I don't have a hat in the game but why won't Ruby do well or not well based on this? It's not like basic webapps need to be much more efficient, and no one was writing high performance compute in ruby anyways.

DennisP 7y ago
Looking over the techempower benchmarks, the fastest web frameworks are over fifty times faster than ruby/rails. If you can replace a hundred web servers with two, that matters.
- ghettoimp 7y ago
  Sure. But an awful lot of folks don't have a hundred web servers. If you're running something simple, you can pretty much use whatever you want.
- ativzzz 7y ago
  The vast majority of web apps are CRUD apps, which can achieve sub 100ms responses on any language with caching, background workers and minor optimizations. There will always be problems where you need faster responses, and the solutions to those problems are already not using Ruby. You don't use a hammer when a screwdriver is appropriate, but nails work pretty well in most places and screws are unnecessary.
  - DennisP 7y ago
    100ms with how many responses per second? Throughput matters too. And techempower does some pretty realistic-looking benchmarks. For example: > In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size). An additional fortune cookie message is inserted into the list at runtime and then the list is sorted by the message text. Finally, the list is delivered to the client using a server-side HTML template. The message text must be considered untrusted and properly escaped and the UTF-8 fortune messages must be rendered properly. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
    - ativzzz 7y ago
      > 100ms with how many responses per second As always, it depends. Benchmarks are cool, and yes we know that Rust and Go will always be faster than Ruby out of the box. Once the number of responses goes up, you throw caching at the problem. But the benchmark says > The requirements were clarified to specify caching or memoization of the output from JSON serialization is not permitted. > the table has 12 rows Which is low and should be quick regardless, but regardless of your tech stack if you are creating a "modern" UI, you handle this update asynchronously with JS anyway, and if you're not, do you really care about sub 100 ms responses? If you want performance out of the box, yes you will use Go, but like I said earlier, you use a hammer for nails and a screwdriver for screws. If you want performance and type safety, you choose one, if you want faster prototyping and a more mature web dev ecosystem, you choose another.

buzzkillington 7y ago

FPGAs will fare well, general processors won't. You know we've reach the end of Moore's law when balanced ternary computers become the norm.

csomar 7y ago

That has a lot to do with why I took on learning Rust. My last year Macbook Pro has a 6-core CPU. At this rate, we should have 32-64-core CPUs for consumers in a few years. Not using all the processors means your program only makes use of 3-1.5% of the available power. My prediction is that, in a few years, lots of programming languages and software developers will simply become obsolete because what the other guys can produce is heaps of performance, security and manageability atop. But I might be wrong, so make your career decisions carefully.

oblio 7y ago
I hope you're right. However Intel Core Duo was released in January 2006 and it had 2 cores. So in a bit more than 13 years we only have 3x as many cores. Core 2 Quad was released in January 2007, so if you count from that one, a bit more than 12 years for 1.5x as many cores. I wouldn't bet on widespread 64 core CPUs for consumers in the next 10 years or so. Most commercial software just doesn't use it efficiently and consumers don't need it for existing software. We need a software breakthrough, a killer app, something that people really want and that really needs a ton of cores. For now, I don't see it. But then again, that's how killer apps are, nobody sees them until they're there.
- csomar 7y ago
  > However Intel Core Duo was released in January 2006 and it had 2 cores. So in a bit more than 13 years we only have 3x as many cores. Core 2 Quad was released in January 2007, so if you count from that one, a bit more than 12 years for 1.5x as many cores. https://xkcd.com/605/ https://xkcd.com/605/ If you are going to extrapolate, don't pick the date. Take all the numbers you have and trace the average value. If you are picking the numbers, you can extrapolate to any point you want. > I wouldn't bet on widespread 64 core CPUs for consumers in the next 10 years or so. We already have 32-core processors for servers. Imo, the biggest challenge will be the laptop and heat management rather than putting a bunch of processors together. > We need a software breakthrough, a killer app, something that people really want and that really needs a ton of cores. We need that now. Most software I'm using is slow. Part of why I picked the iPhone (and I bet many people did) was speed. It is fast. People care about speed and if you introduce them to something faster then they'll get hooked. Also, you are already using all of your cores because of multi-tasking. It makes your computer experience overall better. At 6 cores, multi-threading for an application doesn't give much noticeable experience, since you probably have 5-6 things running on your computer doing other stuff like network or an audio-player. > For now, I don't see it. But then again, that's how killer apps are, nobody sees them until they're there. > I hope you're right. Don't worry, just hang in there. The start of multi-cores was slow but then that's all there is right now. Seems intel/amd have mastered how to add more cores but the CPU frequency is pretty much capped going forward!