Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

161–170 of 265 posts

Re: Major standard library changes in Go 1.20

#161

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

Caches are much more limited than RAM though. If every program under the sun starts targetting them directly, is the 100-1000x speedup hold true?

Legit question, I have no idea about how this would behave.

Re: Major standard library changes in Go 1.20

#162
post #76

How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…

It’s extensive, web server focused, ergonomic and has well documented and sensible security defaults.

In Go you can write a production ready, well tested, _concurrent_ web application with routing, auth, sql storage, html templating, image optimization, and so on without fetching third party libraries. And you’re not leaving official docs for it.

Re: Major standard library changes in Go 1.20

#163

[flagged]

All languages borrow ideas from one another, and that’s good for all of us. I was once a Z80 developer, then a C developer, then Java and now Go. I don’t look at C and say “autoincrement! Those scallywags just copied the idea from LDIR!”

(Admittedly this is partly because it’s not true)

Re: Major standard library changes in Go 1.20

#164

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

The 100x plus speedup is no exaggeration either, I've noticed some incredulity from others at the numbers. For a very simple comparison, I recently was testing a (poorly) custom built data-oriented Entity-Component-System for usage in games with a more typical "componentized" object approach. No multithreading or anything complicated. On my system, the typical approach could generate about 1000 new objects and attach…

I don't get this - you're talking about generating objects - I'm assuming you're talking allocating new objects. What's your bottleneck ? Allocator or do you have some poor data structure to update it ? Where is the speedup coming from ? The kind of speedup you're talking about sounds like moving from allocating each object separately to some arena and avoiding allocator overhead.

I could be wrong in the assumptions - but OP is talking about fitting stuff in CPU cache don't really see how that translates to your scenario.

Re: Major standard library changes in Go 1.20

#165
post #138

Earlier quoted context omitted.

except for the date api... it took me a couple days to understand the silly idiosyncratic magic string to format dates.

This is what the documentation has to say about it: > These are predefined layouts for use in Time.Format and time.Parse. The reference time used in these layouts is the specific time stamp: 01/02 03:04:05PM '06 -0700 (January 2, 15:04:05, 2006, in time zone seven hours west of GMT). That value is recorded as the constant named Layout, listed below. As a Unix time, this is 1136239445. Since MST is GMT-0700, the refer…

It’s similar to the default date(1) output, except that puts the year at the very end, after even the timezone.

Re: Major standard library changes in Go 1.20

#166

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

The 100x plus speedup is no exaggeration either, I've noticed some incredulity from others at the numbers. For a very simple comparison, I recently was testing a (poorly) custom built data-oriented Entity-Component-System for usage in games with a more typical "componentized" object approach. No multithreading or anything complicated. On my system, the typical approach could generate about 1000 new objects and attach…

    -----s.-ms.-us.-ns|----------------------------------------------------------
                     0.1 ns - NOP
                     0.3 ns - XOR, ADD, SUB
                     0.5 ns - CPU L1 dCACHE reference           (1st introduced in late 80-ies )
                     0.9 ns - JMP SHORT
                     1   ns - speed-of-light
        ?~~~~~~~~~~~ 1   ns - MUL ( i**2 = MUL i, i )
                   3~4   ns - CPU L2  CACHE reference           (2020/Q1)
                     5   ns - CPU L1 iCACHE Branch mispredict
                     7   ns - CPU L2  CACHE reference
                    10   ns - DIV
                    19   ns - CPU L3  CACHE reference           (2020/Q1 considered slow on 28c Skylake)
                    71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
                   100   ns - MUTEX lock/unlock
                   100   ns - own DDR MEMORY reference
                   135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
                   202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
                   325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
        |Q>~~~~~ 5,000   ns - QPU on-chip QUBO ( quantum annealer minimiser 1 Qop )
                10,000   ns - Compress 1K bytes with a Zippy PROCESS
                20,000   ns - Send     2K bytes over 1 Gbps  NETWORK
               250,000   ns - Read   1 MB sequentially from  MEMORY
               500,000   ns - Round trip within a same DataCenter
        ?~~~ 2,500,000   ns - Read  10 MB sequentially from  MEMORY~~
            10,000,000   ns - DISK seek
            10,000,000   ns - Read   1 MB sequentially from  NETWORK
        ?~~ 25,000,000   ns - Read 100 MB sequentially from  MEMORY~~
            30,000,000   ns - Read 1 MB sequentially from a  DISK
           150,000,000   ns - Send a NETWORK packet CA -> Netherlands
        1s:   |   |   |
          .   |   | ns|
          .   | us|
          . ms|

(https://stackoverflow.com/a/33065382)

However,

    0.001 ns light transfer in Gemmatimonas phototrophica bacteriae
biology has much more performant/optimized machines, therefore, yes, plenty of room for improvement in silico.

Re: Major standard library changes in Go 1.20

#167
post #141

[flagged]

This is the worst kind of comments on HN. Snarkiness without argumentation, condescension and depreciation of some good and interesting work. Just don't post anything instead. If you're salty or don't like Go, do yourself (and the community) a favor and don't click on submissions related to Go.

GP could also just cite related work and make a comment on the similarities and differences.

Re: Major standard library changes in Go 1.20

#168
post #119

[flagged]

> even talking about interfaces like "magic methods"

No, this was referring to a mechanism used in the stdlib to see if an object passed in as one interface type, could be coerced to another interface type in order to perform some operation more efficiently.

I’m a Go developer, and I didn’t know this happened, it’s basically not visible from the API function signatures, you have to look at the implementation.

I love working in Go but this did raise my eyebrows and the functionality definitely deserves being called “magic”, and not in the good way.

Re: Major standard library changes in Go 1.20

#169

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

What if we just put all the RAM on the CPU die? Imagine the speedups for everyone!

I know, sounds crazy. Who’s gonna make such a drastic change to the industry?

Re: Major standard library changes in Go 1.20

#170

The next phase of language design is making it possible to write "data-oriented" programs which largely live within the cache of the CPU. Ie., the next frontier is moving from RAM to cache, since CPUs are not going to get faster than programs are "already slow". If you rewrite some OOP/Pointer-Machine-Model/RAM-Thrashing programs for modern CPUs, you can get 100-1000x speed-up. The evolution in language design seems,…

Caches are much more limited than RAM though. If every program under the sun starts targetting them directly, is the 100-1000x speedup hold true? Legit question, I have no idea about how this would behave.

[deleted]
Post reply on HN