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

Malloc Challenge

vicsydev.blogspot.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Malloc Challenge

#81

Post by JoeAltmaier »

mauvehaus wrote: post #80
conjectures wrote: post #76

Earlier quoted context omitted.

I've noticed this, and also that the typical salaries for embedded systems developers seems to be lower than for hotness.js developers :( Am I wrong? Hope so.

My experience, coming as somebody who has experience on the large end of embedded (100's of MHz, 100's of MB RAM, MMU, running Linux), albeit a while ago, is that it's hard to break back into it if you've been out of the community for a while. The last time I was looking for a job, I had been doing non-embedded, including kernel and low-level for 8 years or so, and I had the darnedest time finding embedded positions…

I'm doing embedded contracting between startups. Its been pretty easy to find work, but I've been doing this sort of thing for decades. In fact, 4 days after quitting the last startup (new investor changed direction) I got a panicky call from an old contract begging me to pick up a project. It had been 10 years; they found my number in an old rolodex.

Embedded now has plenty of that 'large end' work now, since SOC/SOM prices have come way down.

As for iRobot, I actually called them. They split in half; their whoishiring entry is the Roomba people not the military people. But they're strangely still putting 5 tiny controllers in each vacuum instead of one hefty processor. And they're an east-coast Boston company, quite a bit different from a west-coast startup.

Re: Eagle. My college roommate wrote a board-layout package with some friends called Eagle years ago. He's from Austria. I wonder if its any relation to the modern product?

Re: Malloc Challenge

#82

Post by lmm »

codr4life wrote: post #25
xenadu02 wrote: post #23

Earlier quoted context omitted.

I'm sure it inflates one's ego but the chances that they've avoided writing any exploitable security vulnerabilities is almost zero.

Show me a software stack without those kinds of bugs; they're all written in C somewhere down the line; enormous amounts of complicated C, written by coders of varying competence. At least in my stack I can keep it simple and fix anything that needs fixing.

Not everything has to come down to C. OCaml is self-hosting I believe.

And even if it did, rates matter.

Re: Malloc Challenge

#83

Post by jheriko »

its an interesting exercise for learning but the code style is awful.

freel instead of freelist? ffs.

abbreviating memory to mem is enough of a mistake in the standard library without going further to m like malloc does and some of the examples here.

still, much respect, to the coder4life for making such a good effort and having such an awesome name...

Re: Malloc Challenge

#84

Post by mprovost »

nujabes wrote: post #63

I'm trying to build it in MacOS but I'm inundated with errors. For example malloc_perf.c:39:3: error: implicit declaration of function 'clock_gettime' is invalid in C99 [-Werror,-Wimplicit-function-declaration] BENCHMARK("basic", &c4malloc); ^

MacOS doesn't provide clock_gettime in its libc. You have to use a Mach specific timer. There are some libraries that abstract this but obviously the author never built it on a Mac, which is their choice.

Re: Malloc Challenge

#85

Post by zzzcpan »

jheriko wrote: post #83

its an interesting exercise for learning but the code style is awful. freel instead of freelist? ffs. abbreviating memory to mem is enough of a mistake in the standard library without going further to m like malloc does and some of the examples here. still, much respect, to the coder4life for making such a good effort and having such an awesome name...

Coding style never saved anyone's C code from being insecure. So it's not something to be concerned about, C code is generally awful on its own.

Re: Malloc Challenge

#86

Post by codr4life »

hvidgaard wrote: post #67
greenshackle2 wrote: post #21

>[libc4life] is aiming for simplicity and leverage; and it makes a real effort to get there by playing on C's strengths, rather than just inventing yet another buggy Lisp. Ouch, right in the feels, I've been working on https://buildyourownlisp.com in my spare time. (EDIT: I was looking for a name for the repo, YABLisp it is.) > coding in C is a welcome therapy after seemingly wasting years exploring various ways of p…

Long term maintanance is easier with safer languages.

Everything is easier in safer languages, far from everything is possible.

Re: Malloc Challenge

#87

Post by codr4life »

mathgenius wrote: post #73
codr4life wrote: post #43

Earlier quoted context omitted.

Thank you, but that's not the problem I'm solving. Any one of those could be used to feed any implementation from the challenge. The idea I'm pushing is using local knowledge to customize memory management, instead of trying to find the perfect one-size-fits-all solution.

Aha, I see.. Very nice. Like the following implementation of free() as commonly used in HFT: void free(void *mem) {}

That's a totally valid solution to some problems :) Having access to a decent allocator protocol lets you do that and more.

Re: Malloc Challenge

#88

Post by codr4life »

jheriko wrote: post #83

its an interesting exercise for learning but the code style is awful. freel instead of freelist? ffs. abbreviating memory to mem is enough of a mistake in the standard library without going further to m like malloc does and some of the examples here. still, much respect, to the coder4life for making such a good effort and having such an awesome name...

The naming discussion stops here; if you have nothing more constructive to add, I suggest silence. They are not mistakes, they are born out of 30 years of experience with naming things. We will never come to an agreement on this, and it's ok. Why not skip ahead to the more interesting discussions that actually lead anywhere?

Re: Malloc Challenge

#89

Post by codr4life »

huhtenberg wrote: post #69
codr4life wrote: post #40

Earlier quoted context omitted.

Only if you insist on clinging to a general purpose, system level perspective on memory allocation. No amount of thinking and reasoning about these issues is useless.

While OP might've phrased it more politely, he's got a point - allocators that aren't designed for multithreaded use are ultimately oversimplified toy projects. It's really not that much of a challenge to knock together a (slab + heap + free list) allocator that will perform really well single-threadedly. However it will be nearly impossible to adapt it to the multithreaded context. It is a considerably more complex…

Not if they're meant for specific uses in limited parts of your application; one allocator per thread, for instance. Why are you clinging so hard to the system level, general purpose perspective? Given that the problems it comes with don't really have any good answers. How is that supposed to lead us forward?

Re: Malloc Challenge

#90

Post by codr4life »

chrisseaton wrote: post #62
codr4life wrote: post #40

Earlier quoted context omitted.

Only if you insist on clinging to a general purpose, system level perspective on memory allocation. No amount of thinking and reasoning about these issues is useless.

Doesn't the benchmark also just allocate and then immediately free? I think I could specialise for that particular use pattern and make it very fast just for the benchmarks. Will that not work for some reason? A good benchmark might be a replayed set of allocate and free operations from a large real application.

It does, but with random sizes. If think you have a way to make that run faster than the provided implementations, then please show us.
Post reply on HN