Please create an account to participate in the Slashdot moderation system


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:It depends (Score 1) 472

by Trailer Trash (#49343623) Attached to: No, It's Not Always Quicker To Do Things In Memory

Even if you wrote this in C in the style in which they did it the program would be slow. Since there's no way to "extend" a C string, it would require determining the length of the current string (which involves scanning the string for a null byte), malloc'ing a new buffer with one more byte,

There is. It is called realloc. If you are unlucky, it will just divide the number of times the system actually performs by 16 or whatever the malloc implementation uses as an alignment, but once the allocation gets big enough you get a pages directly from the system, and it just maps in more pages on the end.

malloc isn't the problem, though. My point was that if you write it in the style of the code in the paper (don't keep track of the string length between character appends) then it'll still have to scan the string a million times. If you know ahead of time that you're going to append exactly one million characters to the string then you need but one malloc, right? I can make this program extremely fast in that manner but that's not what they're doing.

Comment: Re:It depends (Score 2) 472

by Trailer Trash (#49337747) Attached to: No, It's Not Always Quicker To Do Things In Memory

Well, yeah, but that's not going to work consistently. Worst case is if the string is on the stack you'll smash the stack and likely have a memory access error. If it's on the heap you'll likely get the error quicker.

I wouldn't even think of writing a program in the manner in which their sample was written, but if I was trying to solve their basic "problem" there are better ways to go about it.

Comment: Re:It depends (Score 3, Insightful) 472

by Trailer Trash (#49337449) Attached to: No, It's Not Always Quicker To Do Things In Memory

The real story here, is that if you don't know how to write code properly, then string concatenation can be really slow.

Was their paper peer reviewed?

I just reviewed it, but frankly, they're not my peers.

They actually understand the problem and state it near the end of the paper. The issue is pretty simple and when I read the /. summary I knew what the problem was. They're appending single bytes to a string. In both chosen languages - Java and Python - strings are immutable so the "concatenation" is way the hell more complex than simply sticking a byte in a memory location. What it involves is creating a new string object to hold both strings together. So, there's the overhead of object creation, memory copying, etc. Yes, by the time you're done it's a lot of extra work for the CPU.

I'm going to state this as nicely as I can: what they proved is that a complete moron can write code so stupidly that a modern CPU and RAM access can be slowed down to the extent that even disk access is faster. That's it.

Even if you wrote this in C in the style in which they did it the program would be slow. Since there's no way to "extend" a C string, it would require determining the length of the current string (which involves scanning the string for a null byte), malloc'ing a new buffer with one more byte, copying the old string and then adding the new character and new null byte. Scanning and copying are both going to require an operation for each byte (yeah, it could be optimized to take advantage of the computer's word length) on each iteration, with that byte count growing by "1" each time.

The sum of all integers up to N is N(N+1)/2. If N is 1,000,000 the sum is 500,000,500,000. So, counting bytes (looking for null) requires half a trillion operations and copying bytes requires another half trillion operations. Note that "operations" is multiple machine instructions for purposes of this discussion.

Yeah, modern computers are fast, but when you start throwing around a trillion operations it's going to take some time.

Writing to disk will be faster for a number of reasons, mainly because the OS is going to buffer the writes (and know the length of the buffer) and handle it much much better. It's not doing a disk operation every time they do a write. If they were to flush to disk every time they would still be waiting for it to finish.

There are a few notes, here. First, in Java and Python the string object likely holds a "length" value along with the actual character buffer. That would make it faster and not require all the operations the badly written C code that I describe above would require. But the overhead of objects, JVM, interpreter, etc. gets thrown into the mix. Second, if I were doing something like this in C I could keep the string length as part of a struct and at least make it that much faster. The point is that a good programmer wouldn't write code in this manner.

Anyway, this "paper" proves nothing except that really bad code will always suck. One would have to be an idiot to write anything close to what they've done here in a real-life scenario. I know because I've cleaned up other people's code that's on the level of this junk...

Comment: Re:"Bookish" vs Indoors (Score 1) 143

by Trailer Trash (#49308289) Attached to: Excess Time Indoors May Explain Rising Myopia Rates


They are challenging old ideas that myopia is the domain of the bookish child and are instead coalescing around a new notion: that spending too long indoors is placing children at risk.

Doesn't that amount to the same thing? Not spending much time on distance focussing?

Yeah, I laughed when I saw that. Someone's pretty clueless.

Comment: In my experience (Score 5, Informative) 319

by Trailer Trash (#49294693) Attached to: Why I Choose PostgreSQL Over MySQL/MariaDB

And I'm probably going to step on a lot of toes here, but people like me strongly prefer Postgres to MySQL. And by "people like me" I mean folks for whom their first real rdbms experience was theoretical or "commercial". I did both.

I used ingres in college to a small extent and then the Ingres commercial product for years after that. I have also used Sybase and Oracle professionally. PostgreSQL easily walks among the giants of that industry.

Every time this discussion comes up the MySQL side has to say "yeah, but..." about a thousand times. MySQL doesn't do ______ properly? "Yeah, but if you just install this other piece of software and change a couple of config files it *can* do it.' Well, con-fucking-gratulations!

The point is that PostgreSQL does exactly what it should do out of the box. I don't have to change a configuration file to make it ACID compliant, fast, correct, whatever. It just works and works correctly out of the box.

Every time someone tells me how easy MySQL is to set up they've betrayed their experience level in this realm.

I know a lot of you are going to mod me down - I don't care. But why not reply instead?

Comment: Re:Just 4? (Score 4, Insightful) 85

by Trailer Trash (#49287365) Attached to: New Jersey Removes Legal Impediment To Direct Tesla Sales

I lived 35 years in Jersey and my family is still mostly there. I had a few years when all I did was drive from one dealership to another doing auto insurance claims. The place is full of car dealerships. They tend to be in clusters along old highways, though sometimes embedded in urban neighborhoods too. The last thing Jersey needs is more car dealerships and lots. So I can see the numerical limits as having some merit. It's a crowded place, and more lots competing for the same number of buyers is not really an improvement, however much Elon Musk doesn't want to use existing dealer networks. Or how much people want Tesla electric vehicles out on the road.

Yeah, if only there were a way for everybody together to decide how many auto dealerships are needed. We could call it a "market".

But, yeah, silly stuff. We should centrally plan how many dealerships there should be. It'll work out much better.

Comment: Re:Yet another Ted Cruz bashing article ! (Score 1) 415

by Trailer Trash (#49274421) Attached to: Politics Is Poisoning NASA's Ability To Do Science

Explain anti vaxxers

Anti-vaxxers are spread pretty evenly across the political spectrum. In fact a study published in December 2014 found that conservative Republicans are very slightly more likely to hold anti-vax views than liberal Democrats.

Uh, yeah, but only one side is yelling "anti-science" at the other. There should be *no* liberal Democrats on the anti-vax side if I were to believe the bullshit coming from that side.

Both sides are anti-science, just in different ways. But it's only the Democrats who try to use this as a political point.

Comment: Re:wait what? (Score 1) 415

by Trailer Trash (#49274379) Attached to: Politics Is Poisoning NASA's Ability To Do Science

the EPA can worry about the environment, leave NASA to what NASA is supposed to do.

The EPA is a regulatory agency, not a science agency. It's not the EPA's job to conduct the research on earth.

Tell you what, I'll pass their phone number along to you so you can set them straight.

Comment: Re:Ignoring the stupidity of the FAA for a minute. (Score 2) 239

We had toy helicopters for years before we had drones. There's a huge difference as "drones" fly autonomously or semi-autonomously. If you've ever watched liveleak videos of drone use you'll note the thing flies itself, the operator works on targeting and killing people. The interface is extremely high level. The operator marks an area as the target and the software alters the flight path and camera angle to make that area available for attack.

A toy helicopter, on the other hand, is directly flown by the operator and generally has a rolling camera that simply aims straight ahead or is simply movable by the operator.

You can turn a toy helicopter into a drone with the right software, but they are otherwise *very* different things. Calling it a drone is done simply to invoke images of people flying actual drones over the middle east and therefore make it scary.

Hobbyists have been flying toy helicopters far longer than that without incident. Don't let the FAA shit in this punchbowl any more than they already have.

Comment: Re:This ex-Swatch guy doesn't have a clue (Score 2) 389

Yeah and back in 1991 you were probably telling us Apple could never fail at anything ever. Keep riding the hype wave, everyone knows they always last forever...

I agree with that, but keep in mind that Apple has a couple hundred billion dollars in the bank right now. They have more money than the federal government and they don't even have the machines to print it. Think about that.

That's not saying there can never be a decline - even Rome fell. But Apple nearly died in the 1990s and ran out of cash. At this point they could quit selling products and they'd still have enough cash to coast along for decades (the cash is invested). It's a whole nother ball game.

Microsoft is essentially in the same boat, by the way.

Don't be irreplaceable, if you can't be replaced, you can't be promoted.