Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Aluminium is the fuel, not water (Score 5, Informative) 85

argh, again this kind of misleading headline that makes the people who only read the headline think a perpetual machine is finally invented.

The energy comes from aluminium, aluminium "burning" into aluminium-oxide.

Putting the "converting water into hydrogen" into headline is misleading reporting.

Comment The world needs a good and open mobile OS (Score 2) 63

WP has crappy multitasking, and all your data are belong to Microsoft.

With IOS all your data are belong to Apple. And everything is controller by Apple.

With Android all your data are belong to Google, and performance is bad.

With Symbian the user owns his data, but performance is bad, sw development is really pain, and UI is bad. RIP.

What is needed is operating system that allows the user to own his data, has good performance, and allows the user to use the device the way he wants.
Meego/Mer gives this.

Comment Jolla does not mean a rescue boat - too small (Score 3, Informative) 200

I'm a finn,so I know what "Jolla" means.

Jolla means a very small sailing boat - not meant for rescue, but meant for people who want to go sailing alone on a very small boat.
(who either cannot afford bigger boat or just likes very small boats)

Jollas cant be used as rescue boats, they are too small for that.

Comment Triathlon bike (Score 1) 356

Tires and most components like road racing bikes, but has aerobars and bullhorn bars instead of drop bars.

And has more agressive geometry, 78 degree sea post instead of 73 degree.

So it's faster than road racing bike, but illegal to use on road races.

Simply the fastest way to travel on own power, recumbrants may be faster on straight road, but they are too clumsy to for city traffic.

Comment Re:Take your time, let software catch up. (Score 3, Informative) 149

Software isn't the bottleneck. Caches are *tiny* compared to the size of even single functions in modern programs, which means they get flooded repeatedly, which in turn means that you're pulling from main memory a lot more than you'd like.

Wrong.

The code size of average function is much smaller than instruction cache for any modern processor.
And then there are L2 and L3 caches.

Instruction fetch needing to go to main memory is quite rare.

And then about data.. depends totally on what the program does.

Multi-core CPUs aren't (as a rule) fully independent - they share caches and share I/O lines, which in turn means that the effective capacity is slashed as a function of the number of active cores. Cheaper ones even share(d) the FPU, which was stupid.

None one of the CPU's sharing FPU with multiple HW threads are cheap.

Sun Niagara I had slow shared FPU, but the chip was not cheap

AMD Bulldozer, which usually has sucky performance, sucks less on code which uses the shared FPU.

FPU operations just have long latencies and there are always lots of data dependencies, so in practice you cannot
utilize FPU well from one threads, you need to feed instructions from multiple treads.

Intel uses HyperThreading for this, AMD Bulldozer it's CMT/shared FPU/module.
GPU's are barrel processors for the same reason.

The bottleneck problem is typically solved by increasing the size of the on-chip caches OR by adding an external cache between main memory and the CPU.

Much more often the bottleneck is between the levels of the chip's caches.
The big outer level caches are slow and processors spend quite often small time waiting for data coming from them. And if you increase the size of the last level caches, you make them even slower.

One of the reason's for bulldozer's sucky performance is because it has small L1 caches(so it needs to fetch data deom L2 cache often), but big and slow L2 cache. So there is this relatively long L2 latency happening quite often.

External cache.. has not been been used for about 10 years by Intel or AMD. It's either slow or expensive, and usually both. Now when even internal caches can easily be made with sizes over 10 megabytes, the external cache has to be very expensive in order to compete with internal caches, and still it only makes sense on some server workloads.

After that, it depends on whether the bottleneck is caused by bus contention or by slow RAM. Bus contention would require memory to be banked with each bank on an independent local bus. Slow RAM would require either faster RAM or smarter (PIM) RAM. (Smart RAM is RAM that is capable of performing very common operations internally without requiring the CPU. It's unpopular with manufacturers because they like cheap interchangeable parts and smart RAM is neither cheap nor interchangeable.)

Smart RAM is a dream, and a research topic in universities. It's uncommon because it does not (yet) exist.

And most of the problems/algorithms are not solveable by "simple" smart ram that can only operation on data near each others. And it you try to make it even smarter, then you end up making it costlier and slower, it will become just chip with multicore processor and memory on same chip.

There are some computational tasks where smart ram would improve the performance by great magnitude, but for the >90% of all the other problems, it has quite little use.

Comment End of a failed experiment, nobody loses (Score 1) 246

When nokia deciced to open source Symbian, they did not understand the ways how open source software/development model works.
You cannot take a closed-source code and think that when you open the source, suddently thousands of other people will come to help you and do your work for you.

The amount of people who actually downloaded the symbian os source code and succesfully compiled it themselves outside Nokia and some other big phone manufacturers can propably be calculated with fingers of one hand.

SymbianOS was piece of terribly written code that used very strange coding practices, and getting it to compile was quite hard. By just giving this kind of code to public does not create any kind of "open source momentum". No people are interested in contributing to it when they cannot get any benefit from their changes, and when making those changes is so hard.

So, in the end, nobody loses when the source is closed.

Comment There is no vulcain in ariane V second stage. (Score 1) 143

There are a few things that make this rocket BAD.

The Vulcain engine is not air startable. They will have to fix this; it is not clear how much this will cost

They are not planning to use Vulcain. Vulcain is used in Ariane V's FIRST stage, they are using the SECOND stage.
The engine they are using is both air-startable AND re-startable.

The Ariane center stage will have to be radically altered - right now it is build for bearing the load of boosters on its sides. Now it will be pushed up?

again, wrong.

The ariane V second stage sits in top of it's first stage.
The stacking is quite similar.

Ariane V has "2.5" stages:

0) Boosters.
1) first stage (vulcain engine)
2) second stage

This new rocket will differ from Ariane V by having one huge solid rocket engine(from ares 1) replacing the boosters an first stage.

Comment Ghost Recon (Score 1) 465

very good game from 2001-2002.

One bullet usually kills.

Aiming is as slow as reality, no matter how good mouse hand the player has.

Realistic fog whose purpose is not to look nice, but to hinder visibility.

I consider this to be the best first person 3d game ever made.

The sequels were not so good, they were too much action, losing some of the realism, and losing the big maps.

Operation flashpoint is another example. It was also very good, maybe even mode realistic, but the playability was not as good as with ghost recon, so I rank Ghost recon as #1.

I am waiting for someone to create real sequel to Ghost Recon, instead of those Ghost Recon:Advanced warfighter toy shooters which differ nothing from those cs and other toy games.

Comment How 64-bit operations on RV7x0 work (Score 1) 102

Some more information how RV7x0 calculates 64-bit floating point:

All shader processors in RV7x0 are natively 32-bit. There are 5 ALU's in each shader processer. When RV7x0 calculates an 64-bit MUL operation, it does it by using 4 of those 32-bit ALU's together. When RV7x0 calculates an 64-bit ADD operation, it combines 2 32-bit ALU's together.

That's why RV7x0 has floating point MUL throughput of 1/5 of it's 32-bit MUL thoughtput. There is no "group of 64-bit ALU's" like the article thinks.

Comment The article has nothing to do with reality (Score 1) 102

Some guy who does not know very much posts a long speculation article, all speculation done with his limited undertanding. And then this is posted as news.

RV790 is just higher-clocked RV770. There are no more shader units. There are no shader units converted to 64-bit. it's just ~10% clock speed increase, giving about 10% more performance.

RV800 will come at end of the year, that will have much power.

Slashdot Top Deals

"May your future be limited only by your dreams." -- Christa McAuliffe

Working...