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

Computer Science from the Bottom Up

bottomupcs.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Computer Science from the Bottom Up

#81

Post by yongjik »

Joker_vD wrote: post #31

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…

I think fork was a nice solution back when threads weren't common: you just fork, run as many syscalls as you want to modify the running environment, and then do exec.

Unfortunately, with threads, you're now stuck with locks that are potentially held by threads that no longer exist. So you can't call any function that may potentially acquire a lock, like printf, or your program may randomly hang. This feels... inelegant.

Re: Computer Science from the Bottom Up

#82

Post by mhh__ »

> All modern architectures would be considered RISC architectures

no no no no no no no no

It is sort of like RISC on the inside (uOps), but x86 is __not__ RISC on the outside, which means it has to have a thumping great decoder and a bunch of microcode using power all the time.

Locally even if the microarchitecture could be considered a RISC, the architecture of an X86 computer cannot be considered RISC both on account of the irregularity of the instruction set and the limits to instruction-decode throughput because reasons already mentioned.

Re: Computer Science from the Bottom Up

#83

Post by asimpletune »

mhh__ wrote: post #82

> All modern architectures would be considered RISC architectures no no no no no no no no It is sort of like RISC on the inside (uOps), but x86 is __not__ RISC on the outside, which means it has to have a thumping great decoder and a bunch of microcode using power all the time. Locally even if the microarchitecture could be considered a RISC, the architecture of an X86 computer cannot be considered RISC both on accou…

I mean, they do provide a footnote explaining further:

> Even the most common architecture, the Intel Pentium, whilst having an instruction set that is categorised as CISC, internally breaks down instructions to RISC style sub-instructions inside the chip before executing.

Re: Computer Science from the Bottom Up

#84

Post by mhh__ »

asimpletune wrote: post #83
mhh__ wrote: post #82

> All modern architectures would be considered RISC architectures no no no no no no no no It is sort of like RISC on the inside (uOps), but x86 is __not__ RISC on the outside, which means it has to have a thumping great decoder and a bunch of microcode using power all the time. Locally even if the microarchitecture could be considered a RISC, the architecture of an X86 computer cannot be considered RISC both on accou…

I mean, they do provide a footnote explaining further: > Even the most common architecture, the Intel Pentium, whilst having an instruction set that is categorised as CISC, internally breaks down instructions to RISC style sub-instructions inside the chip before executing.

That's what I'm saying is wrong. Note that the instructions are RISC style i.e. some fairly large instructions decode into a pretty small number of micro-operations, which implies said "RISC" operations are actually quite bulky.

Issue-width isn't everything, but ARM chips are really showing the limitations of x86.

Re: Computer Science from the Bottom Up

#85

Post by mhh__ »

mhh__ wrote: post #84
asimpletune wrote: post #83

Earlier quoted context omitted.

I mean, they do provide a footnote explaining further: > Even the most common architecture, the Intel Pentium, whilst having an instruction set that is categorised as CISC, internally breaks down instructions to RISC style sub-instructions inside the chip before executing.

That's what I'm saying is wrong. Note that the instructions are RISC style i.e. some fairly large instructions decode into a pretty small number of micro-operations, which implies said "RISC" operations are actually quite bulky. Issue-width isn't everything, but ARM chips are really showing the limitations of x86.

Addendum: "Wrong" is also wrong. More nuanced would be to say that for an introduction to architecture (i.e. for an engineer to draw a trend line with a fat pen on a graph), this is the kind of detail that actually matters when it comes to intuition-building, so it's misleading.

Re: Computer Science from the Bottom Up

#86

Post by RcouF1uZ4gsC »

mhh__ wrote: post #82

> All modern architectures would be considered RISC architectures no no no no no no no no It is sort of like RISC on the inside (uOps), but x86 is __not__ RISC on the outside, which means it has to have a thumping great decoder and a bunch of microcode using power all the time. Locally even if the microarchitecture could be considered a RISC, the architecture of an X86 computer cannot be considered RISC both on accou…

I think modern architectures are neither RISC nor CISC.

Successful modern architectures have adopted features of both. Even the most RISC architecture these days likely has AES instructions. Even the most CISC architecture is using RISC like micro ops.

Re: Computer Science from the Bottom Up

#87

Post by mattwillmart »

akersten wrote: post #52
optimalsolver wrote: post #14

I think these CS books should start with a philosophical look at what kind of thing computation actually is, rather than diving straight into UNIX file system structures with barely any context. But I guess that would be computer science from the top down.

Yeah, the first page of this book being "Everything is a File in Unix" is already so high-level and far above what I would call the "bottom-up" of computer science that this book should be renamed "Unix from the bottom-up." The "bottom" of computer science would be mathematically explaining what it means to compute, and building up to the abstraction of a Turing machine, and eventually getting to a concrete implement…

Do you know a book like this? Sounds interesting to me as someone who is very interested in computing, but never went to university.

Specifically "mathematically explaining what it means to compute, and building up to the abstraction of a Turing machine"

Thanks

Re: Computer Science from the Bottom Up

#88

Post by Joker_vD »

yongjik wrote: post #81
Joker_vD wrote: post #31

Slightly off-topic, but... am I the only one who is troubled by the fact that the explanations of "fork and exec" are almost never, ever, discuss the rationale for picking this design instead of "CreateProcess()" a.k.a. "just_launch_this_exe_file()", or even acknowledge this alternative design? A student would probably expect that to launch an app, there is a system call that would do exactly that: you pass it the na…

I think fork was a nice solution back when threads weren't common: you just fork, run as many syscalls as you want to modify the running environment, and then do exec. Unfortunately, with threads, you're now stuck with locks that are potentially held by threads that no longer exist. So you can't call any function that may potentially acquire a lock, like printf, or your program may randomly hang. This feels... ineleg…

       After a fork(2) in a multithreaded process returns in the child,
       the child should call only async-signal-safe functions (see
       signal-safety(7)) until such time as it calls execve(2) to
       execute a new program.
And since any process can be multithreaded thanks to shared libraries being able to internally do whatever the hell they want to... yeah. Python, for example, in its implementation of subprocess module, had to shift a lot of work into pre-forked parent (such as disabling the GC and allocating all of the memory for exec()'s arguments), to add explicit "call_setsid" argument to reduce the usage of "preexec_fn", and even then, it still has lovely comments such as

            /* We'll be calling back into Python later so we need to do this.
             * This call may not be async-signal-safe but neither is calling
             * back into Python.  The user asked us to use hope as a strategy
             * to avoid deadlock... */
Well, hope is usually not a valid thread-safety strategy, but there is really not much else the Python implementation can do.
Post reply on HN