5 ms·

>I started to realize that assembly language was real programming. BASIC was just an imitation of programming. That's exactly why I couldn't be happy if I onl

>I started to realize that assembly language was real programming. BASIC was just an imitation of programming. That's exactly why I couldn't be happy if I only knew some high level languages like Java / Python / C#. After learning an assembly language and C I feel much more comfortable using any other language. You know the real thing.

ajross 13y ago
There is no "real thing". Now you'll never be happy until you know you're filling as many execution units as possible, or that your loop targets align on cache boundaries, or that you stuff as many ops as possible across the likely-to-be-in-DRAM loads. Then you'll learn Verilog and start worrying about starvation issues in your own pipelines. Then you'll get distracted by a coffeescript REST app and worry about getting your MongoDB replication set up robustly. It's all good. Some people are happy in a single niche, some never are.
- bm1362 13y ago
  Ah, yes. In a parallel programming class at the moment and now I can't stop thinkin about cache boundaries, volatility, weird efficient instructions to use.. Is this false sharing and throwing out the cache line? Where can I use rsqrtf? Am I utilizing the SM fully? Is this busy-wait killing the memory controller? It goes on forever.
  - stelonix 13y ago
    Both of you talk as if generally, people never worry about such things. It seems unusual to me. Is it because the first language I learned was 65816 assembler?
    - chc 13y ago
      In domains where fine-grained performance is not paramount (i.e. most programs), no, people don't worry about that sort of thing very much. How do you even go about reasoning on cache lines in a Ruby on Rails app?
    - ajross 13y ago
      People never worry about machine-level micro-optimizations in exactly the same that people never worry about MVC web app frameworks, which is to say "most people almost never" for some appropriate metric for "most" and "almost". It's a niche. My point was just that some people are happy in just one, while others (the poster I was replying to, and myself among them) aren't.

ajross 13y ago

There is no "real thing". Now you'll never be happy until you know you're filling as many execution units as possible, or that your loop targets align on cache boundaries, or that you stuff as many ops as possible across the likely-to-be-in-DRAM loads. Then you'll learn Verilog and start worrying about starvation issues in your own pipelines. Then you'll get distracted by a coffeescript REST app and worry about getting your MongoDB replication set up robustly. It's all good. Some people are happy in a single niche, some never are.

bm1362 13y ago
Ah, yes. In a parallel programming class at the moment and now I can't stop thinkin about cache boundaries, volatility, weird efficient instructions to use.. Is this false sharing and throwing out the cache line? Where can I use rsqrtf? Am I utilizing the SM fully? Is this busy-wait killing the memory controller? It goes on forever.
- stelonix 13y ago
  Both of you talk as if generally, people never worry about such things. It seems unusual to me. Is it because the first language I learned was 65816 assembler?
  - chc 13y ago
    In domains where fine-grained performance is not paramount (i.e. most programs), no, people don't worry about that sort of thing very much. How do you even go about reasoning on cache lines in a Ruby on Rails app?
  - ajross 13y ago
    People never worry about machine-level micro-optimizations in exactly the same that people never worry about MVC web app frameworks, which is to say "most people almost never" for some appropriate metric for "most" and "almost". It's a niche. My point was just that some people are happy in just one, while others (the poster I was replying to, and myself among them) aren't.