freenode/lisp - IRC Chatlog
Search
20:35:16
jasom
please confirm that I'm not going insane: *random-state* is thread-local in SBCL, right? The disassembly certainly makes me think so ...
20:36:38
jasom
ACTION is trying to parallelize work that heavily uses cl:random and is finding that the run time is identical no matter how many threads are used
20:38:56
jackdaniel
jasom: what makes you think, that *random-state* is bound to different objects on different threads?
20:38:58
Bike
even if it is thread local, if they all share the same random-state object they might only update it through lokcs?
20:39:59
verisimilitude
It's rather satisfying to have a program that entirely lacks undefined behavior.
20:40:38
verisimilitude
Common Lisp does make it easy to introspect on the environment, of course, so it's also easy to simply check if the implementation can support the program, beforehand, which still makes it a valid program.
20:40:59
Bike
the random state has to be updated in an organized way, yeah? probably have to do some loopy cas biznis at best
20:41:31
jackdaniel
phoe: what is undefined behavior in a standard may be well defined in an implementation
20:43:12
verisimilitude
Common Lisp is, in the vast majority of cases, a very well defined language.
20:43:38
verisimilitude
There's a difference between a nonstandard extension and undefined behavior.
20:44:28
verisimilitude
There's a league of difference between adding threads to Common Lisp and signed integer overflow in C.
20:45:45
verisimilitude
Ada gets along just fine, because it actually recognizes that overflow can happen, unlike C, which simply ignores it.
20:46:28
verisimilitude
So, you get an exception in Ada, and you get program misbehavior or chunks of code removed by the compiler, in C.
20:46:52
jasom
ACTION remembers some comment on ISAs (RISC-V I think?) where people were requesting efficient traps of signed integer overflow, and the answer was "compilers don't use that" the response was "compiler's don't use that because it's not efficient on most architectures" ... chicken and egg problem.
20:47:52
verisimilitude
RISC architectures are generally braindead, jasom, and they're also usually not reduced, either.
20:48:06
jasom
well I was testing out Nim, in which the random state is neither thread-safe nor thread-local.
20:48:45
jasom
ACTION loves Power. When it was first introduced everyone not named IBM argued it wasn't RISC though.
20:49:24
jasom
IBM had some retort along the lines of "When we say RISC, the C is for cycle and all integer operations require a single cycle per pipeline stage"
20:51:19
verisimilitude
Yes, let me use three instructions, twelve bytes, to increment and store a value; how minimal, reduced, and general purpose.
20:52:27
no-defun-allowed
sure, now how many opcodes and how much microcode do you need to implement everything that looks similar to that pattern, verisimilitude?
20:53:08
White_Flame
verisimilitude: the hardware is reduced, offloading more work to the software & compiler, which is kind of its stated purpose
20:53:22
verisimilitude
The Lisp machines needed less than one million transistors, which is far less than any of these ``reduced'' machines.
20:55:32
no-defun-allowed
But basically, if CAR, CDR, CONS, EQ and FUNCALL/APPLY aren't opcodes, then you have a boring instruction set.
20:57:47
p_l
Like multiple ALUs, huge caches, register files bigger than internal memory of old cpus
20:58:03
verisimilitude
Yes; you could have a faster machine with less, but that makes the hardware more capable, which means the stupid compilers get blamed, then.
20:59:20
verisimilitude
A call instruction in various forms is in basically anything that isn't a hardcore RISC.
21:01:43
p_l
And a bunch of PLT papers essentially argued for RISC for higher order languages, because it essentially provided custom microcode for every application
21:03:51
p_l
C doesn't really fit modern CPUs at all, which is why the spec is composed heavily of "X is undefined behaviour"
21:05:52
p_l
It has certain assumptions btw which made it really bad for RISC, though, with RISC designs being usually word instead of byte oriented
21:10:29
p_l
Well, what C's founding fathers knew and did and what mainstream C evolved into are two different things ;-)
21:12:07
pjb
Very early, all unix systems were sold with both a C and a Fortran compiler. POSIX standardizes both.
21:13:24
pjb
Now, perhaps the question to ask is about the syscalls and the data types (or lack thereof) used by the syscalls. But I note that basically, all the original syscalls only used simple int parameters and pointers to byte buffers. So rather language agnostic really. Later it degraded…
21:13:35
jasom
jackdaniel: yeah, my talk about *random-state* devolved into undefined behavior which devolved into C...
21:16:29
p_l
Out of various "modern" languages I think I've got it worst for python from system engineering and internals side
21:27:54
p_l
Younder: well, python the language is less offensive than CPython the de-facto standard
21:40:10
Younder
pjb I mostly write in Mathematica these days. Anyhow the type-system in Haskell gives me a headache so I couldn't use it for pseudo-code.
0:24:03
tsandstr
Hey guys, anybody working with CL under Gentoo? I'm considering hopping over to Gentoo, and I'm kind of curious about the CL packages in the repos. Would it be best practice to use those official packages? Or use quicklisp? And how do they interact?
0:26:54
tsandstr
i'm a bit of a noob with lisp, but is there any particular reason why youy avoid the portage version?
0:27:17
Josh_2
Somethings like Stumpwm are in portage so you can emerge that and it will pull in libraries to compile it
0:27:46
tsandstr
i'm planning on installing stumpwm too. So for stump, go ahead and use portage, but for libraries, use quicklisp?
0:28:02
tsandstr
will it be an issue to have the same libraries installed through both portage and quicklisp?
0:31:32
pjb
tsandstr: I used to use gentoo, but I still compiled my own software, which I use everyday (lisp implementations, emacs, rm, etc).
0:35:53
tsandstr
so, in general, do you think it would make sense to install Lisp applications (eg StumpWM) through portage, while installing libraries that I plan to use through quicklisp?
3:26:32
rdap
"The Sieve of Eratosthenes stops when the square of the number we are testing is greater than the last number on the grid."
3:27:15
pjb
ebrasca: I don't like lisp-critic too much. I find some advises ill-advisen, some outdated, very few useful. Read it, and use your own ruleset!
3:29:57
rdap
So I only need to generate a list of primes up to the square root of the number that was input
3:32:53
rdap
then copy to a new list every 2nd from the 2nd, every third from the third, every 5th from the 5th, and so on
3:34:08
rdap
then divide the input number by everythin in the list and eliminate everything that doesn't divide by x into an integer
3:39:37
pjb
rdap: yes. But you can avoid generating list of numbers. Using a bit-vector takes less space.
4:17:56
aeth
(I guess you could use a byte vector and manually work with bits yourself if you don't trust bit vectors.)
4:25:32
gilberth
beach: It even is more correct than _any_ C library for POSIX regular expression that I could find.
4:26:50
gilberth
And they don't even compile the regular expression. As in: compiling it to native code eventually. And flex^Wbison cannot do submatch addressing.