Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming Language Memory Models

research.swtch.com

Post reply on HN
Print view View original

31–40 of 101 posts

Re: Programming Language Memory Models

#31

Post by pphysch »

bullen wrote: post #24

In a 100 years the main languages used will still be C on the client (with a C++ compiler) and Java on the server. Go has no VM but it has a GC. WASM has a VM but no GC. Eveything has been tried and Java still kicks everythings ass to the moon on the server. Fragmentation is bad, lets stop using bad languages and focus on the products we build instead. "While I'm on the topic of concurrency I should mention my far to…

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

Re: Programming Language Memory Models

#32

Post by raphlinus »

dragontamer wrote: post #29
raphlinus wrote: post #26

Earlier quoted context omitted.

In general spinlocks are a bad idea, but you do see them in contexts like decoupled look-back. As you say, thread granularity is a problem (unless you're on CUDA on Volta+ hardware, which has independent thread scheduling), so you want threadgroup or workgroup granularity. In any case, I'm interested in pushing the boundaries of lock-free algorithms. It is of course easy to reason about kernel-{start/end} synchroniza…

This is the first time I've heard of the term "decoupled look-back". But I see that it refers to CUB's implementation of device-wide scan. I briefly looked at the code, and came across: https://github.com/NVIDIA/cub/blob/main/cub/agent/agent_scan... I'm seeing lots of calls to "CTA_SYNC()", which ends up being just a "__syncthreads" (a simple thread-barrier). See: https://github.com/NVIDIA/cub/blob/a8910accebe74ce043…

I don't think CUB is doing decoupled look-back, the reference you want is: https://research.nvidia.com/publication/single-pass-parallel...

It doesn't use the word "spin" but repeated polling (step 4 in the algorithm presented in section 4.1, particularly when the flag is X) is basically the same.

Re: Programming Language Memory Models

#33

Post by valbaca »

skohan wrote: post #27
bullen wrote: post #24

In a 100 years the main languages used will still be C on the client (with a C++ compiler) and Java on the server. Go has no VM but it has a GC. WASM has a VM but no GC. Eveything has been tried and Java still kicks everythings ass to the moon on the server. Fragmentation is bad, lets stop using bad languages and focus on the products we build instead. "While I'm on the topic of concurrency I should mention my far to…

I'm sorry is this comment from 1998? I've been working in software for over a decade, and I haven't seen server work being done in Java in ages. From my perspective, Go in the context of serverless programming seems to currently be the best choice for server-side programming. In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn &…

> In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn & write and performant enough) but with the addition of algebraic data types, named parameters, and a slightly higher level of abstraction.

I'd love for this to be Crystal: https://crystal-lang.org/

> I haven't seen server work being done in Java in ages.

In the meantime, I've been doing a large amount of Java backend server work for the past 10 years.

Re: Programming Language Memory Models

#34

Post by dragontamer »

raphlinus wrote: post #32
dragontamer wrote: post #29

Earlier quoted context omitted.

This is the first time I've heard of the term "decoupled look-back". But I see that it refers to CUB's implementation of device-wide scan. I briefly looked at the code, and came across: https://github.com/NVIDIA/cub/blob/main/cub/agent/agent_scan... I'm seeing lots of calls to "CTA_SYNC()", which ends up being just a "__syncthreads" (a simple thread-barrier). See: https://github.com/NVIDIA/cub/blob/a8910accebe74ce043…

I don't think CUB is doing decoupled look-back, the reference you want is: https://research.nvidia.com/publication/single-pass-parallel... It doesn't use the word "spin" but repeated polling (step 4 in the algorithm presented in section 4.1, particularly when the flag is X) is basically the same.

3rd paragraph:

> In this report, we describe the decoupled-lookback method of single-pass parallel prefix scan and its implementation within the open-source CUB library of GPU parallel primitives

The CUB-library also states:

https://nvlabs.github.io/cub/structcub_1_1_device_scan.html

>> As of CUB 1.0.1 (2013), CUB's device-wide scan APIs have implemented our "decoupled look-back" algorithm for performing global prefix scan with only a single pass through the input data, as described in our 2016 technical report [1]

Where [1] is a footnote pointing at the exact paper you just linked.

-----------

> It doesn't use the word "spin" but repeated polling (step 4 in the algorithm presented in section 4.1, particularly when the flag is X) is basically the same.

That certainly sounds spinlock-ish. At least that gives me what to look for in the code.

Re: Programming Language Memory Models

#35

Post by skohan »

valbaca wrote: post #33
skohan wrote: post #27

Earlier quoted context omitted.

I'm sorry is this comment from 1998? I've been working in software for over a decade, and I haven't seen server work being done in Java in ages. From my perspective, Go in the context of serverless programming seems to currently be the best choice for server-side programming. In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn &…

> In the next 20 years I expect Go will be supplanted by a language which is a lot like go (automatic memory management, simple, easy to learn & write and performant enough) but with the addition of algebraic data types, named parameters, and a slightly higher level of abstraction. I'd love for this to be Crystal: https://crystal-lang.org/ > I haven't seen server work being done in Java in ages. In the meantime, I've…

I have a feeling it's going to have C-like syntax and frankly I hope so because using an `end` keyword instead of braces makes no sense to me.

Re: Programming Language Memory Models

#36

Post by wcarss »

The prior article in this series from ~a week ago is 'Hardware Memory Models', at https://research.swtch.com/hwmm, with some hn-discussion here: https://news.ycombinator.com/item?id=27684703

Another somewhat recently posted (but years-old) page with different but related content is 'Memory Models that Underlie Programming Languages': http://canonical.org/~kragen/memory-models/

a few previous hn discussions of that one:

https://news.ycombinator.com/item?id=17099608

https://news.ycombinator.com/item?id=27455509

https://news.ycombinator.com/item?id=13293290

Re: Programming Language Memory Models

#37

Post by bullen »

pphysch wrote: post #31
bullen wrote: post #24

In a 100 years the main languages used will still be C on the client (with a C++ compiler) and Java on the server. Go has no VM but it has a GC. WASM has a VM but no GC. Eveything has been tried and Java still kicks everythings ass to the moon on the server. Fragmentation is bad, lets stop using bad languages and focus on the products we build instead. "While I'm on the topic of concurrency I should mention my far to…

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

COBOL is not around in anything interesting, and trust me go is not going to be used to build anything that we'll use in 20 years.

Re: Programming Language Memory Models

#38

Post by raphlinus »

dragontamer wrote: post #34
raphlinus wrote: post #32

Earlier quoted context omitted.

I don't think CUB is doing decoupled look-back, the reference you want is: https://research.nvidia.com/publication/single-pass-parallel... It doesn't use the word "spin" but repeated polling (step 4 in the algorithm presented in section 4.1, particularly when the flag is X) is basically the same.

3rd paragraph: > In this report, we describe the decoupled-lookback method of single-pass parallel prefix scan and its implementation within the open-source CUB library of GPU parallel primitives The CUB-library also states: https://nvlabs.github.io/cub/structcub_1_1_device_scan.html >> As of CUB 1.0.1 (2013), CUB's device-wide scan APIs have implemented our "decoupled look-back" algorithm for performing global prefi…

Ah, good then, I didn't know that, thanks for the cite. I haven't studied the CUB code on it carefully.

Re: Programming Language Memory Models

#39

Post by pphysch »

bullen wrote: post #37
pphysch wrote: post #31

Earlier quoted context omitted.

Pretty sure Java is/was popular (and has enormous momentum) because "it just works" at a time when the Internet is taking off, not because it is some linguistic or technological marvel. It will definitely stick around, just like COBOL and C and Go.

COBOL is not around in anything interesting, and trust me go is not going to be used to build anything that we'll use in 20 years.

Do I hear "containers are a temporary fad"?

Re: Programming Language Memory Models

#40

Post by Kranar »

voidnullnil wrote: post #19
dragontamer wrote: post #17

Earlier quoted context omitted.

But the practitioner doesn't need to know the memory model (aside from "memory models are complicated"). To solve that problem, the practitioner only needs to know that "mutex.lock()" and "mutex.unlock()" orders reads/writes in a clearly defined manner. If the practitioner is wondering about the difference between load-acquire and load-relaxed, they've probably gone too deep.

> To solve that problem, the practitioner only needs to know that "mutex.lock()" This is true, but they do not know that. If you do not give some kind of substantiation, they will shrug it off and go back to "nah this thing doesn't need a mutex", like with a polling variable (contrived example).

Can you explain what you mean by a "polling variable" needing a mutex? Usually polling is done using atomic instructions instead of a mutex. Are you referring to condition variables?
Post reply on HN